Administration of Active Directory does not have to be hard. Too often what should be a simple task is made more difficult than it needs to be.The solution? Hyena from SystemTools Software. With ease-of-use as well as powerful importing and bulk updating capabilities.
OWA not working internally
Hi,
I hope someone can help me. I have a situation where OWA does not work internally. OWA is not used internally very often so I can't be sure when/what caused this but it seems to have happened since I updated our soon to expire Exchange certificate.
When browsing to the internal URL (https://exchangeservername/owa) I get the message that the certificate has been revoked. We have two on-premise HT/CA servers and this happens with either of them. OWA works fine externally as does Outlook Anywhere / ActiveSync.
If I run get-exchangecertificate in Powershell it shows all the correct SANs and is enabled for all services but the status shows as "Invalid". To test things, I created a self signed certificate and enabled it for all services. This fixed the problem of internal OWA access but of course broke external access / ActiveSync etc. The intermediate certificate has been installed correctly (I believe).
Does anyone have any ideas? There may be some info I have missed out so just ask if you need to know anything else.
Thanks in advance...
I hope someone can help me. I have a situation where OWA does not work internally. OWA is not used internally very often so I can't be sure when/what caused this but it seems to have happened since I updated our soon to expire Exchange certificate.
When browsing to the internal URL (https://exchangeservername/owa) I get the message that the certificate has been revoked. We have two on-premise HT/CA servers and this happens with either of them. OWA works fine externally as does Outlook Anywhere / ActiveSync.
If I run get-exchangecertificate in Powershell it shows all the correct SANs and is enabled for all services but the status shows as "Invalid". To test things, I created a self signed certificate and enabled it for all services. This fixed the problem of internal OWA access but of course broke external access / ActiveSync etc. The intermediate certificate has been installed correctly (I believe).
Does anyone have any ideas? There may be some info I have missed out so just ask if you need to know anything else.
Thanks in advance...
Who is Participating?
The ultimate cause of this was our ISA servers. Apologies I don't have a more detailed solution but it was resolved by a colleague. Ultimately I believe the new certificate had been applied to the Exchange boxes, but not the ISA. Thanks everyone for the suggestions.
Also, in event viewer I get EventID - 12014:
However, the certificate in the personal store does have that name!
Microsoft Exchange could not find a certificate that contains the domain name localserver.domain.net in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector External Mail Relay with a FQDN parameter of localserver.domain.net. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate-Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
However, the certificate in the personal store does have that name!
What is the name on the cert. Is it something like mail.domain.com? Do you have an internal DNS record pointing to it so it would be something along the lines of https://mail.domain.com/owa?
You can verify your internal URL here: http://www.windows-noob.com/forums/index.php?/topic/3611-how-to-configure-outlook-web-access-for-exchange-2007/
You can verify your internal URL here: http://www.windows-noob.com/forums/index.php?/topic/3611-how-to-configure-outlook-web-access-for-exchange-2007/
Hi Spartan_1337, NLB isn't setup, no.
NRhode - The name on the cert is indeed mail.domain.com (the URL used for external OWA access is mail.domain.com/owa). There is no DNS record internally for mail.domain.com. I tried setting one up and can hit mail.domain.com internally after that, but I still get the same certificate error. The internal URL is https://servername/owa.
Does this help? As far as I can tell, the problem is with the certificate and the fact that the status says "invalid". And I guess the error in eventviewer backs this up. Just not sure where to go next with it...
NRhode - The name on the cert is indeed mail.domain.com (the URL used for external OWA access is mail.domain.com/owa). There is no DNS record internally for mail.domain.com. I tried setting one up and can hit mail.domain.com internally after that, but I still get the same certificate error. The internal URL is https://servername/owa.
Does this help? As far as I can tell, the problem is with the certificate and the fact that the status says "invalid". And I guess the error in eventviewer backs this up. Just not sure where to go next with it...
Your SSL certificate needs to include all names used for accessing your site. Create an SSL certificate that has your outside and inside domain names. A great tool for doing this is SelfSSL7. Google it and you will find a dozen locations to download it.
there is a very good article about the process here: http://geekswithblogs.net/renewieldraaijer/archive/2011/05/11/self-signed-san-certificates.aspx
there is a very good article about the process here: http://geekswithblogs.net/renewieldraaijer/archive/2011/05/11/self-signed-san-certificates.aspx
Hi,
The certificate already has all the names needed. External OWA address, internal server names, internal FQDN's etc.
As well as the common name it includes:
autodiscover.domain.com
autodiscover.domain.net
CASHT1
CASHT1.domain.net
CASHT2
CASHT2.domain.net
The certificate already has all the names needed. External OWA address, internal server names, internal FQDN's etc.
As well as the common name it includes:
autodiscover.domain.com
autodiscover.domain.net
CASHT1
CASHT1.domain.net
CASHT2
CASHT2.domain.net
Honestly the Internal URL should reflect the external URL and you would create an internal DNS record for this. This way the certificate matches. Typically I do not include the server name on my cert. The problem is the certificate does not match the one installed. The cert it is trying to connect to is most likely revoked or non-existent because you do have a legitimate certificate installed and assigned to the roles (SMTP, POP, IIS, etc).
Check this over to see if it helps.
http://support.microsoft.com/kb/555855
Check this over to see if it helps.
http://support.microsoft.com/kb/555855
Hi NRhode,
Thanks for your post. What I now tried was adding a new zone for mail.domain.com into DNS and add a blank A record pointing to the HT/CA server. I pinged the name just to make sure. Then in EMC, I changed the internal URL to match the external URL. Now, when I browse to it, I still get the same error. Do you think the fact that get-exchangecertificate shows the status as "Invalid" has anything to do with it?
Thanks for your post. What I now tried was adding a new zone for mail.domain.com into DNS and add a blank A record pointing to the HT/CA server. I pinged the name just to make sure. Then in EMC, I changed the internal URL to match the external URL. Now, when I browse to it, I still get the same error. Do you think the fact that get-exchangecertificate shows the status as "Invalid" has anything to do with it?
After re-reading your problem this happened right after you updated the certificate because it was soon to expire. Are you positive you assigned the new certificate to all the services required for your environment? If anything try re-installing the certificate
The TLS error is normal when you have been changing certificates around. Exchange requires a certificate with the server's real name on it for internal use.
The fix for that is to run
new-exchangecertificate
No switches or anything. You will get a prompt about replacing the default SMTP certificate. Accept the message and continue.
For everything else, reconfigure Exchange to use the external name internally.
http://semb.ee/hostnames
It is no longer best practise to include internal names on trusted SSL certificates, mainly because the SSL providers are going to stop issuing them from next year. Therefore switching to public FQDN is the best option.
Simon.
The fix for that is to run
new-exchangecertificate
No switches or anything. You will get a prompt about replacing the default SMTP certificate. Accept the message and continue.
For everything else, reconfigure Exchange to use the external name internally.
http://semb.ee/hostnames
It is no longer best practise to include internal names on trusted SSL certificates, mainly because the SSL providers are going to stop issuing them from next year. Therefore switching to public FQDN is the best option.
Simon.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
-
Course of the Month6 days, 7 hours left to enrollMonitoring and Operating a Private Cloud with System Center 2012 R2 273 lessons
