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

Resources