This is a very common error that Exchange admins tend to see but can actually be resolved quite easily. The error is below:
“The name on the security certificate is invalid or does not match the name of the site”
The logic behind this error is actually quite simple, once you understand it. Exchange uses autodiscover to push out settings to Outlook clients (and other clients) and each of the services that Exchange are configured with a URL for connections from the internal network and a URL for connections from the external network.
This error is simply warning us that one of the URLs that Exchange has specified in the autodiscover response is not included on the SSL certificate that is in use for IIS. It gets a bit more complicated when there is a load balanced array of client access servers as you need to check all the virtual directories on each server and also check that IIS is using the correct certificate.
Since I get asked about this error a lot and it’s pretty basic logic, I decided to write a PowerShell script that will cycle through all the CAS servers, get all the names specified for each virtual directory, Outlook Anywhere and the SCP (AutodiscoverServiceInternalUri) then compare these to the names on the certificate and output the results including a list of missing names on the certificate.
Instructions are below:
1) Download the PowerShell function (Test-ExchangeCertificate.ps1) from here: https://gallery.technet.microsoft.com/Exchange-2010-2013-2016-a6156d87
2) Open up the Exchange Management Shell
3) Change directory to the location where you downloaded the script to and then run the command below. Note that there are two full stops separated by a space before the backslash:
. .Test-ExchangeCertificate.ps1
4) The function is now imported and you can run it as below:
Test-ExchangeCertificate
Here you can see the output. Each virtual directory is checked on each CAS server and an output of the missing names on the certificate can be seen as the CertificateNamesMissing property. If you’re not interested in a lot of the raw data, you can run the script to just get this property:
Test-ExchangeCertificate | FT Server,CertificateNamesMissing
If you have quite a lot of CAS servers in a number of remote sites and don’t want to run the test on all of them then you can specify a list of servers as below:
Test-ExchangeCertificate -Servers litex01,litex02
You can also use the PowerShell function to output the results to a CSV to record information about all your virtual directories:
Test-ExchangeCertificate -CSVPath C:tempCertificateChecks.csv
You should get a CSV includes the same information.
Hopefully this should make troubleshooting this issue much easier. If you’re wondering what was wrong in my test lab, well you should be able to see that I haven’t yet configured my new litex02 Exchange server (actually running Exchange 2016) with the correct certificate which includes mail.litwarweinc.com.
Note that this PowerShell function only checks Exchange certificates. It won’t check any certificates that you have configured on your load balancers or reverse proxies.