Outlook “The name on the security certificate is invalid”: Exchange URLs vs SAN names

Outlook keeps showing a Security Alert that says "The name on the security certificate is invalid or does not match the name of the site". Users who click Yes carry on; users who click No lose Out of Office, free/busy and address book downloads. The cause is nearly always a host name that Exchange or DNS hands to Outlook but that isn't on your certificate. Here's how to find that name and fix what's behind it.

Symptoms#

The dialog shows the host name Outlook tried to reach at the top, and that's your most useful clue:

ex01.contoso.local
Information you exchange with this site cannot be viewed or changed by others.
However, there is a problem with the site's security certificate.
  The security certificate is from a trusted certifying authority.
  The security certificate date is valid.
  The name on the security certificate is invalid or does not match the name of the site
Do you want to proceed?

• The alert appears when Outlook starts or at random points during the day, because Outlook repeats Autodiscover in the background.
• Clicking No makes the Autodiscover lookup fail, which breaks profile setup, Out of Office and free/busy.
• Opening OWA or the EAC with the same host name in Edge or Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID.
• It often starts after a new server install, a certificate change or a namespace change.

Why it happens#

Outlook trusts a TLS connection only if the host name it connected to appears in the certificate's subject or Subject Alternative Name (SAN) list. Outlook learns host names from three places:

1. The Autodiscover SCP in Active Directory. Domain-joined Outlook clients look this up first. Each Exchange server publishes one, with a URL taken from AutoDiscoverServiceInternalUri. On a new server it uses the server's own name, for example https://ex01.contoso.local/Autodiscover/Autodiscover.xml.
2. DNS-based Autodiscover. Outlook tries https://contoso.com/autodiscover/autodiscover.xml, then https://autodiscover.contoso.com/autodiscover/autodiscover.xml, then an HTTP redirect and an SRV record.
3. The URLs Autodiscover returns. These are the internal and external URLs of the EWS, OAB, MAPI and ECP virtual directories, plus the Outlook Anywhere host names. Setup sets the internal URLs to the server's FQDN.

How to fix it#

1. Read the alert#

Note the host name at the top, then select View Certificate › Details › Subject Alternative Name to see the names on the certificate that was actually presented. If it's the self-signed "Microsoft Exchange" certificate, the IIS binding is wrong (step 5).

2. Run Test E-mail AutoConfiguration#

On an affected PC, hold Ctrl, right-click the Outlook icon in the notification area and select Test E-mail AutoConfiguration. Enter the address and password, clear Use Guessmart and Secure Guessmart Authentication, and select Test. The Log tab shows which Autodiscover URLs Outlook tried, and the Results tab lists every URL Exchange returned. Any host name that isn't in the SAN list is a suspect.

3. Compare Exchange's URLs with the certificate#

$srv = 'EX01'
Get-ExchangeCertificate -Server $srv | Where-Object { $_.Services -match 'IIS' } |
  Format-List FriendlyName, CertificateDomains, Services, NotAfter, Thumbprint
Get-ClientAccessService -Identity $srv | Format-List Name, AutoDiscoverServiceInternalUri
Get-WebServicesVirtualDirectory -Server $srv | Format-List InternalUrl, ExternalUrl
Get-OabVirtualDirectory -Server $srv | Format-List InternalUrl, ExternalUrl
Get-MapiVirtualDirectory -Server $srv | Format-List InternalUrl, ExternalUrl
Get-EcpVirtualDirectory -Server $srv | Format-List InternalUrl, ExternalUrl
Get-OwaVirtualDirectory -Server $srv | Format-List InternalUrl, ExternalUrl
Get-ActiveSyncVirtualDirectory -Server $srv | Format-List InternalUrl, ExternalUrl
Get-OutlookAnywhere -Server $srv | Format-List InternalHostname, ExternalHostname

4. Point the SCP and every URL at names on the certificate#

$srv = 'EX01'; $ns = 'mail.contoso.com'
Set-ClientAccessService -Identity $srv -AutoDiscoverServiceInternalUri 'https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml'
Get-WebServicesVirtualDirectory -Server $srv | Set-WebServicesVirtualDirectory -InternalUrl "https://$ns/EWS/Exchange.asmx"
Get-OabVirtualDirectory -Server $srv | Set-OabVirtualDirectory -InternalUrl "https://$ns/OAB"
Get-MapiVirtualDirectory -Server $srv | Set-MapiVirtualDirectory -InternalUrl "https://$ns/mapi"
Get-EcpVirtualDirectory -Server $srv | Set-EcpVirtualDirectory -InternalUrl "https://$ns/ecp"
Get-OwaVirtualDirectory -Server $srv | Set-OwaVirtualDirectory -InternalUrl "https://$ns/owa"
Get-ActiveSyncVirtualDirectory -Server $srv | Set-ActiveSyncVirtualDirectory -InternalUrl "https://$ns/Microsoft-Server-ActiveSync"
Get-OutlookAnywhere -Server $srv | Set-OutlookAnywhere -InternalHostname $ns -InternalClientsRequireSsl $true

Repeat this on every server behind the namespace, and fix the external URLs the same way if they're wrong too. The SCP can point to autodiscover.contoso.com or mail.contoso.com, as long as the name is on the certificate and resolves internally.

5. Fix internal DNS and the certificate itself#

• Inside the network, mail.contoso.com and autodiscover.contoso.com must resolve to your internal load balancer or Exchange servers. Use split DNS (an internal zone for contoso.com) or a separate zone for each name, then check with Resolve-DnsName from a client.
• If you need a name that isn't on the certificate, get a certificate that includes it. Public CAs no longer issue certificates for internal names such as ex01.contoso.local, so in that case it's the URLs that have to change.
• Bind the right certificate to IIS on every server with Enable-ExchangeCertificate -Server EX01 -Thumbprint <thumbprint> -Services IIS. The renewal steps are in renewing the SAN and Auth certificates.

6. When the alert names your bare domain#

Outlook's first DNS attempt, https://contoso.com/autodiscover/autodiscover.xml, reached a web server whose certificate doesn't cover contoso.com. The clean fix is on the website: have it present a valid certificate for that name. If you can't change the website, set the Outlook registry value ExcludeHttpsRootDomain (DWORD, 1) under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover so Outlook skips that lookup.

Verify the fix#

Wait for Active Directory replication, restart Outlook on an affected PC and run Test E-mail AutoConfiguration again. Good looks like this:

• Every URL on the Results tab uses a name from the certificate's SAN list, and the Log tab shows the SCP lookup going to your namespace.
• Resolve-DnsName autodiscover.contoso.com returns an internal address, and https://mail.contoso.com/owa opens without a browser warning.
• From outside the network, the Outlook Autodiscover test in the Microsoft Remote Connectivity Analyzer passes.
• No Security Alert appears for a full working day.

Prevent it next time#

• Set the SCP and internal URLs on every new Exchange server straight after setup, before users run into its default name.
• Use the same names inside and outside with split DNS, and keep the SAN list short: typically mail and autodiscover.
• Re-check IIS bindings after every certificate renewal. A different certificate, the Auth certificate, causes its own failures when it expires: see expired Exchange Auth certificate.
• For hybrid users whose mailboxes are already in Exchange Online, see Autodiscover troubleshooting for Exchange Online.

References#

• Autodiscover service in Exchange Server (Microsoft Learn)