First think was to check out what exactly happens when trying to open up OWA. Opening a browser, I entered http://mail.domain.com to see how the redirect worked on their server. The browser was redirected by Exchange 2007 to https://mail.domain.com/owa. However, all that was displayed was:
Hmmm… so what to try next? Https://127.0.0.1/owa just to see if that works as well. Same result. OK. So our SSL is broken. I checked “netstat -a” and saw that it was indeed listening on port 443:
Well, the next test was to see if it would at least allow HTTP connections. To do this, open up IIS Mgr and disable the SSL enabled setting on the OWA virtual directory:
Right click on the OWA virtual directory, then click on the ‘Directory Security’ tab:
The click on Edit under the Secure Communications part of the tab:
Clear these two check boxes to remove the SSL requirement:
After doing this, I saved my changes and reset IIS. I then connected to OWA via the HTTP protocol and this worked:
So we’ve now confirmed that we have an SSL issue of some sort. The IIS logs were showing 403 errors:
Checking the event logs I was seeing ‘Schannel’ errors, which I would expect when there is some sort of certificate issue:
Checked the certificate and the certificate appears correct – Private Key is present and the dates are valid.
The I verified the certificate was assigned to IIS correctly:
So now what? Well, after a bit of digging I found an old tool called SSLDiag which can be downloaded here. Simply download the correct version for your server (most if not all Exchange servers should be 64-bit). Install it on your server. Once it is installed we can run this to determine if there are any issue with your certificates. In my customers case, we ran the tool and saw this issue:
OK. So we do have an issue, if we reference this article on the SSLDiag tool, we see that we actually meet two criteria for Scenario 2. To fix this, the first suggestion is to fix the permissions on the MachineKeys directory. To fix the permissions, I use this article.
(correct permissions for Everyone)
However, after following the article and performing an IISReset, the WWW service failed to start. This in turn killed a few other services. When I manually started the services I received an “invalid Handle” error. I backtracked and re-verified the permissions. Both Administrator and Everyone had permission to “This Folder Only” and the permissions listed in the article were correct. Did some research and found this article. The key was this part of the solution:
Notice that the permissions for Everyone are This folder, Subfolder and Files. I made this change:
I then was able to start-up all of the services.
After that was resolved I then checked to see if the certificate was reading correctly:
Same issue. The second part of the article on the SSL issue was to assume the certificate was either incorrectly installed or corrupt. I decided to remove the certificate from Exchange and from the server. To remove it from Exchange you should run a command similar to this:
Get-ExchangeCertificate -Thumbprint <thumbprint of certificate> | remove-exhangeCertificate
Prior to removing the certificate from Exchange, I exported a copy of all certificates to disk using the export wizard in the Certificates Manager. I notice that the old certificate allowed me to export the private key, while the new certificate did not. After exporting, I removed the certificates from Exchange and made sure the Certificates Manager did not show the old and new certificate.
I then imported the new certificate (making the private key exportable), enabled the certificate with Exchange PowerShell, assigned it the IIS and SMTP services, and finally performed an IISReset.
A test of OWA revealed that OWA over HTTPS was now working. In the end the problem turned out to be the certificate was installed incorrectly.
Side Note
I did get a chance to assign the IIS services to a self signed certificate on the server. Once I restarted IIS, I was able to connect to OWA over HTTPS using the Exchange Server name. This confirmed my virtual directories were valid and that the new certificate was the issue.
