"The name on the security certificate is invalid..." After changing to trusted CA and updating VDs

Copper Contributor

Hello,

 

This is with Exchange 2019.

after changing the virtual directories to mail.domain.com (from mail.domain.local) and applying the appropriate certificate, when starting Outlook, the following message pops up (the blacked out part is still showing the old mail.domain.local instead of the mail.domain.com):

outlook error 2.png

Exactly what is described here: https://www.youtube.com/watch?v=arhOzkEAog4

However, the solution displayed in the Youtube video did not help in this situation.

 

Clicking 'Yes' will open Outlook and email works as usual. 

 

This error has also briefly made an appearence, though it has only happened the first 5-10 minutes after making the changes, so probably something had to update in the background first:

outlook error 1.png

 

Not sure anymore what else to do to resolve the issue in the first screenshot. Any help much welcome! (thinking somewhere is still a wrong URL set...RPC maybe...Outlook anywhere...but I checked all those),

 

The new cert common name: mail.domain .com.

SANs: autodiscover.mail.com, domain.com, mail.domain.com

Cheers,

 

12 Replies
Have you checked the value for your SCP record (get-clientaccessservice | select *uri*)? Make sure the value is configured with one of the domains in the certificate
Yes, I did update the SCP record to try to fix it. However after updating it, Autodiscovery still worked but Outlook started prompting for credentials over and over and over...
I'd look to go through each virtual directory on all servers and make sure the internal and external URI are using the name in the certificate. Make sure that internal and external DNS and your network configuration are pointing that namespace at the correct Exchange server. Also check that the authentication settings are correct for each virtual directory. Once that's completed, do a reboot of the Exchange servers.

Ok so after updating all the virtual directories to the new fqdn mail.domain.com, I found that a reference to the old fqdn domain.local entry still exists in the following places (mostly the MetabasePath). The one's I'm assuming can stay, are in green and the ones I'm assuming need to be updated to the new mail.domain.com manually, are in red:


Get-ClientAccessService:
Fqdn: old.domain.local < manually change this to mail.domain.com?
AutodiscoverServiceInternalUri: https://domain.local/autodiscover/autodiscover.xml < this can stay?

 

Get-OutlookAnywhere:
InternalHostname: domain.local < manually change this to mail.domain.com?

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Rpc  < this can stay?

 

Get-OwaVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/owa < this can stay?

 

Get-ActiveSyncVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Microsoft-Server-ActiveSync < this can stay?

 

Get-AutodiscoverVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Autodiscover < this can stay?

 

Get-EcpVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/Ecp  < this can stay?

 

Get-OabVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/OAB < this can stay?

 

Get-PowerhShellVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/PowerShell < this can stay?

 

Get-WebServicesVirtualDirectory:

MetabasePath: IIS://domain.local/W3SVC/1/ROOT/EWS < this can stay?

 

In addition to the above, all of the receive connectors still have the domain.local configured as the FQDN (HELO or EHLO response).

The metabasepath values can stay as is. The OutlookAnywhere internal hostname can be changed....but this value is not the one that would be causing the issue. It's the URL's (both internal and external) that the clients use to connect to, so they are the values that need to be correct and present on the certificate. Have you got any load balancers in place? Could they be causing the issues?

@Dan Snape 

 

So I have found some traces of the domain.local. It is still set as the FQDN for POP, IMAP and Autodiscover:

Lussy150_0-1677363025575.png

 

I'm not sure if I can just change the POP and IMAP FQDN to mail.domain.com without breaking it. As long as split DNS is working (which it is) this should be fine, correct?

 

Also, after changing the Autodiscover FQDN from domain.local to the new domain.com, Outlook went into a credential prompt loop. Any ideas why? I ended up changing it back to domain.local, because it is impacting all Outlook clients. 

 

I'm hopeful that one of the above, or all for that matter, are the cause for this.

Thanks!

Additional findings:
- The MessageTracking logs and the Hub Connectivity logs, are still full of the old domain.local entries. The new domain.com is not present at all.
Sometimes there will be connections made using the server's hostname. Review your internal DNS MX records if you have any.
I'm not sure why the Autodiscover FQDN did that. I only know there is generally no need to change those settings. When the Outlook client is connected to the domain it will get the autodiscover URI via the SCP record (use Get-ClientService to view the URI details), not anything in the autodiscover virtual directory
We do have split DNS setup. The reason I changed the Autodiscover URI is because I had the idea that maybe Autodiscover is causing the name mismatch since the SCP record is domain.local, which is not on the new cert anymore.

I have opened a case with Microsoft now and hopefully they can help out.
Ok I.m quite certain now that the internal Autodiscover is causing the certificate mismatch. Of course it will lookup the SCP enty first, which is domain.local. So I guess somehow I need to change the SCP entry without breaking anything or create an internal autodiscover DNS record pointing to mail.domain.com.
Yes...it's usually the Autodiscover record (SCP). I think that was my first response to your issue. Use the "Get-ClientAccessService | select *URI" and that will show you the current values for all your Exchange servers. Each Exchange server will have it's own record. The value should be a name that is on the certificate (ie https://autodiscover.domain.local/Autodiscover/Autodiscover.xml"). You can use the Set-ClientAccessService cmdlet to set the new value
We ended up recreating the Autodiscover virtual directory. Which had partial success.