Security Alert with certificate error presented when users launch Outlook 2013 o ...

Problem

You have recently migrated from an earlier version of Exchange 2010 or 2013 to Exchange Server 2016 and noticed that users are now receiving a Security Alert with a certificate error when they launch Outlook:

Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site’s security certificate.

Clicking on the View Certificate button will show the certificate you’ve assigned to the Exchange server and the reason why it is showing an error is because the certificate does not have a SAN entry for the internal server FQDN as shown in the screenshot.

Solution

While some administrators would choose to proceed by adding the internal server FQDN onto the certificate to get around this issue, it is actually not required. The first and most important reason is that public Certificate Authorities no longer issue certificates with internal domain names such as .local which means if your internal domain used a non-routable suffix then there would be no way to get the FQDN into the certificate as a SAN entry.

One of the reasons why this error would be thrown when users launch their Outlook is that the Service Connection Point (SCP) for Autodiscover has not been updated yet. Begin by executing the following cmdlet to review the AutoDiscoverServiceInternalUr i configuration:

Get-ClientAccessService -identity <serverName> | FL

Note how the AutoDiscoverServiceInternalUr i references FQDN of the internal server name which would cause this error to be thrown if your internal certificate did not have the internal server’s FQDN as a SAN entry. To correct this issue, simply use the following cmdlet to configure it to use the autodiscover URL that you would have added as a SAN entry in the certificate and usually resolves to a record that load balances traffic to the Exchange servers in the organization or directly to an Exchange server is there is only one in the organization:

Set-ClientAccessService -identity <serverName> -AutoDiscoverServiceInternalUri https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

With the above configuration corrected, users will now be directed to the autodiscover URL that has an entry on the certificate assigned to the Exchange servers.

As stated earlier, note that this error can be thrown by various reasons and the solution stated here may not apply to every instance of this message.