5

We've recently made a change to the Internal URLs of many of our Exchange Virtual Directories. Following that change, we're seeing end-users report errors from Outlook stating that the certificate cannot be verified because it is expired.

The kicker is that the certificate showing up in these errors no-longer exists on the server. It was removed using the Remove-ExchangeCertificate Cmdlet in the Exchange Management Shell. I've also verified that it no-longer exists in the certificate store at cert:\LocalMachine\My, nor is it visible in any IIS configuration. Additionally, browsing to OWA returns the correct certificate. I don't understand how the server could possibly be serving this certificate any longer.

Is there anywhere else that this certificate could be hiding? Perhaps there is some kind of cache involved with Outlook? Any insight would be appreciated.

2

My first thought is this certificate is coming from somewhere else. I have seen it coming from a proxy in the past. However the first thing I would do is an Autodiscover test.

Hold down CTRL while right clicking on the Outlook icon in the system tray. Choose test email auto configuration.

Deselect the second and third options and run the test.

Look at the log for the URLs it tried. Ensure they resolve to the internal IP Address of the server. Then check the results and confirm the other URLs resolve there too.

If they are wrong then correct them. http://semb.ee/hostnames2007

Simon.

2

I seem to have solved the issue by removing an old, stopped, website from the IIS configuration.

To elaborate, I'll expand on the configuration a bit:

  • The server in question has two IP addresses. Let's call them 192.168.100.200 and 192.168.100.201 for now.
  • The main web site on the server is named "Default Web Site", as is often the case.
  • There was also a second web site named "OWA" in the configuration.
  • The SSL binding for the "Default Web Site" site is: type=https, Host Name=$null, IP Address=*, Binding Information=$null.
  • The previously mentioned binding is configured to use the current SSL certificate.

A second site, named "OWA", was unused and stopped, but it was bound to 192.168.100.201 (this is more specific than the SSL binding for the "Default Web Site" site). It was configured with an old certificate that was not visible when using the Get-ExchangeCertificate command. When users reached web resources via 192.168.100.201, IIS was, somehow, still serving the old certificate that was configured in the stopped "OWA" web site rather than the certificate that was configured in the "Default Web Site" site . Removing the "OWA" web site from the IIS configuration appears to have resolved this.

I've still got some concerns, as everything I've read says that it should not be possible for IIS to serve a certificate that does not exist in the cert store. This appears not to be the case, and will require some further research. Additionally, I plan to do some testing around this type of (mis)configuration in IIS. It seems to me that a stopped web site shouldn't have any effect on the certificate that is served by another web site.

  • It's been some time and we still haven't seen any errors after this change. I feel confident that this was the correct fix in this case, so I'm going to mark it as the answer. – bshacklett Dec 17 '15 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.