Forum Discussion

Lussy150's avatar
Lussy150
Copper Contributor
Jan 19, 2023

"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...
Exchange Server
outlook
Dan_Snape's avatar
Dan_Snape
Bronze Contributor
Jan 19, 2023
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
Lussy150's avatar
Lussy150
Copper Contributor
Jan 19, 2023
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...
  • Dan_Snape's avatar
    Dan_Snape
    Bronze Contributor
    Jan 22, 2023
    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.
    • Lussy150's avatar
      Lussy150
      Copper Contributor
      Feb 08, 2023

      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

       

      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).

      • Dan_Snape's avatar
        Dan_Snape
        Bronze Contributor
        Feb 09, 2023

        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?

Resources