Forum Discussion
"The name on the security certificate is invalid..." After changing to trusted CA and updating VDs
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 followi...
So I have found some traces of the domain.local. It is still set as the FQDN for POP, IMAP and Autodiscover:
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.
- 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.
- We ended up recreating the Autodiscover virtual directory. Which had partial success.
- 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
- 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.
- 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. - 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