local server names on Exchange 2013 SSL certificate

Courtesy of oddytee In the past, internal names were added to SSL certificates for Exchange because that is what Microsoft’s guidance was to eliminate certificate warnings in Outlook–and public certificate authorities (CA) permitted them. Those names covered the bases with every possible connection scenario that might come up but exposed internal server names that could potentially cause security issues. The requirements have changed more recently and this subject has become an increasing concern (for me) over the past 6 or 9 months as the 1 Nov 2015 deadline approaches. Exchange and SSL customers will need to make sure their certificates are modified to use external and internal FQDNs (i.e. contoso.com). Therefore, NetBIOS names will need to be removed from certificates as well as names with contoso.local (all non-routable names) will need to be updated to contoso.com. The certificate, unfortunately, will not be the only item for Exchange that will need to be changed to ensure continued functionality as the deadline approaches. The internal URLs (virtual directories) on the client access server (CAS) settings will need to be changed using the following cmdlets…

• Set-ClientAccessServer
• Set-OABVirtualDirectory
• Set-WebServicesVirtualDirectory
• Set-ActiveSyncVirtualDirectory
• Set-OWAVirtualDirectory
• Set-ECPVirtualDirectory
• Set-OutlookAnywhere

  If certificate and client access settings are not changed, Outlook users will receive pop ups warning of untrusted certificates, invalid names in the certificates, etc. Fortunately for us, DigiCert has helped to lessen the stress of such an effort through providing a tool called the DigiCert Internal Name Tool for Microsoft Exchange. I was able to test this tool against my lab environment that consists of two (2) Exchange 2013 servers with internal URLs and an SSL certificate containing FQDNs with internal server names. NOTE: For Exchange 2010 servers, the DigiCert tool will issue a warning if invalid certificates exist and if Exchange 2010 SP3 (at a minimum) is not installed on all of the client access servers. After registering for (and receiving) the tool from DigiCert, it is fairly straight-forward to run. Log into one of the Exchange Client Access servers (CAS) and run it to perform an analysis of the environment. It will check existing settings as well as read the names from the installed certificate. The tool also provides the ability to update the settings immediately or create scripts to be run at a later time. I chose to have the scripts created to run at later time. NOTE: If a client access array has been deployed, the DigiCert tool will display a warning if the CAS array name is configured with a publicly, non-routable FQDN (i.e. outlook.domainname.local). In my estimation, the ClientAccessArray and RpcClientAccessServer settings shouldn’t need to be changed but will update if testing proves otherwise. Before running the script, I had to see what it was going to do. In a nutshell, the script will modify the internal URLs to something that resembles a publically routable URL. In other words, it will set the internal URLs and AutodiscoverServiceInternalUri to something similar to the external OWA URL (i.e. webmail.domainname.com). Once I knew what commands were going to be run in the script, I could then either run the commands myself or edit the settings manually via EAC or run the script. Again, I chose to have the script make the changes for me. The process of the changes (in my lab) using the script took several minutes. After the script completed and recycled the IIS application pools on each server, I confirmed the changes took affect and tested OWA and Outlook access. Once I was happy with the results, I created a new certificate request using webmail.domainame.com and autodiscover.domainname.com as the only names in the certificate, submitted to my public CA, and finally applied to my Exchange servers. Once again, I tested OWA and Outlook access. OWA worked as expected, however, Outlook did not. After changing the certificate on both servers, for good measure, I restarted both servers. Then using a workstation, opened Outlook (Office 2010) using an existing profile and received the following message but was still able to connect to the mailbox.

There is a problem with the proxy server's security certificate.
The name on the security certificate is invalid or does not match the name of the target site ex2.domainname.local.

Outlook is unable to connect to the proxy server. (Error Code 10)

  The information in the error message lead me to look at the Exchange proxy settings in the Outlook profile. Sure enough the proxy server URL and the principal name were incorrect because those names did not exist in the certificate anymore. At this point, I was a bit confused because I expected the script from DigiCert to modify all of the settings needed for a seamless change. I then looked at the Outlook Anywhere (OA) settings on each Exchange server (via EAC and Get-OutlookAnywhere) to confirm the internal host name was not changed and still needed to be set properly. Looking for clarification, I contacted DigiCert support to confirm the script does not update the OA internal host name; and won’t in the immediate future. For me, this is good information to know because I honestly thought I overlooked something or missed an instruction in using the DigiCert processes. I then proceeded to update the OA settings for “InternalHostname” on both servers using a command similar to this…

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname webmail.domainname.com -InternalClientsRequireSsl $true

  Now, all internal URLs and host names are set to the same values as the external URLs and host names. Again, I restarted both Exchange servers (I probably could have just run iisreset) but I wanted to ensure the servers were refreshed completely. Finally, I tested with Outlook again and was presented with the same error initially. However, after about five minutes, I closed and reopened Outlook with no further problems. I also confirmed that the proxy server URL and the principal name were automatically reset to the correct values within the Exchange proxy settings of the Outlook profile. Let me know what your experiences have been like or if you have a simpler/easier process to address this growing concern as the SSL deadline approaches.