No announcement yet.

Unable to put internal FQDN on Exchange 2010 SSL certificate

  • Filter
  • Time
  • Show
Clear All
new posts

  • Unable to put internal FQDN on Exchange 2010 SSL certificate

    Following a succesful Exchange 2010 upgrade, we are finalising the Exchange 2010 SSL certificate install. We stumbled upon an issue whereas the internal AD name is a domain name registered by another Company. This means that we can't include the internal FQDNs on the SSL certificate. They will not be purchasing Forefront TMG or similar Firewalls and their Firewall does not allow an SSL endpoint to be made, so therefore, we don't have the option to use an internal CA or port 80 for internal traffic and their SSL certificate that contains their External domain.

    We have resolved some of the issues through using NETBIOS names of each CAS server and the CAS array on the SSL certificate. The CAS array NETBIOS name has been set on all internal URLs of Exchange's OWA, EWS, ECP etc, which means that there are no SSL errors.

    The only issue we have is with autodiscover. Outlook clients internally are set automatically to use the CAS array FQDN, which is the internal AD FQDN. An error then occurs as the FQDN of one of the CAS servers is given to the Client, the FQDN we are unable to put on the Certificate.

    Does anyone have any thoughts on the best approach with this scenario?

    We have considered using split DNS and setting the internal URLs and CAS array name to the external domain name, which are on the SSL certificate. That way, external and internal URLS will be the same. We can then set up split DNS to ensure that they access services via the local IP address.

    However, I know you are usually not supposed to set the CAS array to a resolvable internet name as can effect Outlook Anywhere clients as they attempt to resolve it.

    Any advice would be appreciated. Is it possible to change the SCP object in AD to send the NETBIOS name to the Outlook client instead of the FQDN, for example?

    Any suggestions are very much welcome.

  • #2
    Re: Unable to put internal FQDN on Exchange 2010 SSL certificate

    I don't know if this is a viable option when Exchange is in the mix, but anytime I've run into issues with AD internal domain names I've simply created a new primary zone in DNS using another namespace but resolving to the same IPs.

    We had an issue a while back with Symantec Enterprise Vault, where users couldn't create baskets of items for restoration. After much troubleshooting with Symantec support we eventually found that Firefox worked but IE didn't, and the reason was that the AD domain name contained an underscore. Adding a new DNS zone and changing the URLs in the EV policies that clients used to access the website resolved the issue.
    BSc, MCSA: Server 2008, MCSE, MCSA: Messaging, MCTS
    Cruachan's Blog


    • #3
      Re: Unable to put internal FQDN on Exchange 2010 SSL certificate

      Thanks for the reply Cruachan. Yes, that's one of the options but I was wondering then whether it is ok to then set the CAS array to their external domain name.

      For example.

      Instead of:, set it to

      Setup split DNS. I was proposing to setup a Primary DNS zone (not AD integrated) called and insert a Host record with the name left blank and the IP address set to the internal IP of the WNLB. This allows the redirection to the local IP address. However, it is not Best Practice to use a CAS array name that uses a domain that is resolvable on the internet if Outlook anywhere is in use.

      However, I suspect the names given out by SCP are still the internal FQDN names of the CAS servers, which aren't on the Certificate.


      • #4
        Re: Unable to put internal FQDN on Exchange 2010 SSL certificate

        This isn't a problem at all.
        Very common scenario unfortunately.

        The CAS array host name must not resolve externally. Therefore the first thing you have to do is ensure there isn't a wildcard on the domain on the external DNS.

        A split DNS system will be required.
        Then you will have to through and change all of the URLs to use a host name that uses your public domain name, and ensure that it resolves internally.

        That will be autodiscoverServiceinternalURI, OWA, EWS, ActiveSync, Outlook Anywhere. Effectively what I have written for Exchange 2007 but without the SRV record.

        Simon Butler
        Exchange MVP

        More Exchange Content:
        Exchange Resources List:
        In the UK? Hire me:

        Sembee is a registered trademark, used here with permission.


        • #5
          Re: Unable to put internal FQDN on Exchange 2010 SSL certificate

          Thanks for the responses. Have reconfigured internal URLs to the External URLs and setup an internal DNS zone. All is workign well. Just a case of doing the autodiscover side now and testing.


          • #6
            Re: Unable to put internal FQDN on Exchange 2010 SSL certificate

            The final steps were the following.

            Opened up Exchange 2010 PowerShell.

            Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

            Then ran the below;

            Set-WebServicesVirtualDirectory -Identity “NetbiosNameofCASServer1\EWS (Default Web Site)” -InternalUrl https://External URL/EWS/Exchange.asmx -BasicAuthentication:$true

            Set-WebServicesVirtualDirectory -Identity “NetbiosNameOfCASServer2\EWS (Default Web Site)” -InternalUrl https://External URL/EWS/Exchange.asmx -BasicAuthentication:$true

            Then typed this;


            Then this;

            Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri

            Set-ClientAccessServer -Identity NETBIOSNameofCAS1 -AutoDiscoverServiceInternalUri https://TheirExternalURL/Autodiscover/Autodiscover.xml

            Set-ClientAccessServer -Identity NETBIOSNameofCA2 -AutoDiscoverServiceInternalUri https://TheirExternalURL/Autodiscover/Autodiscover.xml

            IIS reset after the above.

            There is no longer a certificate error.

            Many thanks Sembee.