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.
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.
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:
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.