Local Domain Name, netBios Name and IP address support SSL certificates will die soon.
You may have Exchange Servers in your organization which are using public SSL certificates issued just to their local server name or “servername.local” (if you have a private domain ending in .local) rather than “servername.yourcompanypublicsite.com.”
For instance, perhaps your exchange server “exch01” at your company “contoso.com” has a certificate identifying it by its local name of exch01 or exch01.local rather than exch01.contoso.com (which is known as the FQDN or “fully qualified domain name”). Or perhaps your certificate is for exch01.contoso.com but has a subject alternative name (SAN, or alias) entry for simply “exch01” or “exch01.local.”
If these scenarios apply to your company, you should know that SSL certificates will be useless after October, 2016 so you should plan their replacement now – in fact, you won’t be able to have these certificates reissued after November 1, 2015, so it’s best to do away with these in entirely this year.
You see, a certificate issued to a local server name to a system in a non-public domain like “.local”) poses a significant security risk because the name isn’t unique. Other individuals might obtain similar certificates which could then be used to impersonate your server and lure visitors into logging in, thereby putting their credentials at risk and exposing your organization’s confidential data. No internal presence of your organization is required for this tactic to work; any public-connected server set up to snare users this way could suffice.Because of this risk, all certificates must be issued using unique FQDN server names as of this November. Internal-only systems can still be issued local name certificates, but this must be done by a private certificate authority, not a public one that creates and reissued certificates for public server names.
How it will impact in Exchange Server Configuration?
Unless you plan out your certificate upgrade and follow the steps presented in this article, after October of 2016 users may receive certificate errors in Outlook or their browsers and Exchange services themselves may be at risk of, not functioning properly. Certain Client Access Server Exchange settings such as Autodiscover use the server’s local name, not its FQDN name, so these will need to be updated. It seems like this due date is a long time down the road, but deadlines come fast in the technology arena.
While best practices recommend not using private domains such as .local, if your company is doing so you don’t necessarily have to rebuild your Active Directory environment. You can use split DNS to link a public server FQDN (“exch01.contoso.com”) to its private name (“exch01.local”) so long as it has a certificate matching the public address. Users would need to connect to it via the public server name, and this is where split DNS (whereby the outside world sees your server as having a public IP address, but the internal company links it to a private IP address) comes in handy.
Change URLs and Names for an Exchange Server 2007/2010/2013
In the first place, you’ll need to get your certificates reissued without using local names in the name or as a SAN.
Secondly, gather some information about your environment. On an Exchange server, access the Management Shell and run these commands:
get-AutodiscoverVirtualDirectory | flidentity,internalurl, externalurl get-ClientAccessServer | flidentity,AutodiscoverServiceInternalUri get-webservicesvirtualdirectory | flidentity,internalurl,externalurl get-oabvirtualdirectory | flidentity,internalurl,externalurl get-owavirtualdirectory | flidentity,internalurl,externalurl get-ecpvirtualdirectory | flidentity,internalurl,externalurl get-ActiveSyncVirtualDirectory | flidentity,internalurl,externalurl (whereby “identity” represents the server name)
Examine the resulting log files and take note of the details: which certificates are in use? At minimum, you will need to update settings for the top three elements.
Third, once you get the new certificates issued you should test these so you’ll know what to expect and how best to proceed. Build a new server (or clone an existing server) matching your company’s current Exchange server, set it up on a restricted network, and connect to it via the same methods your users do (Outlook, a web browser, Activesync, etc.) You may not be able to utilize DNS services for your live server will have the same name but you can use host records on the client systems to simulate the same function.
Fourth, in your test environment make the following changes as an administrator via the Exchange Management Shell (for purposes of example, this article will pretend your server name is exch01 and organization name is contoso.com; customize these commands as appropriate for your environment).
Note: these steps assume that an internal host record exists in DNS to map the FQDN that you specify to the IP address of the CAS server.
Change the Autodiscover URL using the following command:
Set-ClientAccessServer -Identity exch01 -AutodiscoverServiceInternalUrlhttps://exch01.contoso.com/autodiscover/autodiscover.xml
Change Exchange Web Services InternalUrl attribute of the EWS:
Set-WebServicesVirtualDirectory -Identity "exch01\EWS (Default Web Site)" -InternalUrlhttps://exch01.contoso.com/ews/exchange.asmx
Change the Offline Address Book distribution InternalUrl attribute:
Set-OABVirtualDirectory -Identity "exch01\oab (Default Web Site)" -InternalUrlhttps://exch01.contoso.com/oab
If you are using Exchange 2007, change the UM Web service InternalUrl attribute (otherwise skip this step):
Set-UMVirtualDirectory -Identity "CAS_Server_Name\unifiedmessaging (Default Web Site)" -InternalUrlhttps://exch01.contoso.com/unifiedmessaging/service.asmx
If you need to change settings for the OWACirtualdirectory, ECPvirtualdirectory and ActivesyncVirtualDirectory do so using the command format shown previously, substituting the directory name you wish to change from one of the examples above. You should not have to change any external URLs since it is assumed this already point to a public FQDN.
Open IIS Manager.
Expand the local computer, and then expand “Application Pools”.
Right-click “MSExchangeAutodiscoverAppPool” then click Recycle.
Run these commands to double-check the results:
get-AutodiscoverVirtualDirectory | flidentity,internalurl, externalurl get-ClientAccessServer | flidentity,AutodiscoverServiceInternalUri get-webservicesvirtualdirectory | flidentity,internalurl,externalurl get-oabvirtualdirectory | flidentity,internalurl,externalurl get-owavirtualdirectory | flidentity,internalurl,externalurl get-ecpvirtualdirectory | flidentity,internalurl,externalurl get-ActiveSyncVirtualDirectory | flidentity,internalurl,externalurl
Fifth, connect to your server via your test client applications/devices. Examine and document the results – whether errors occur, Exchange services aren’t working properly, or something else prevents things from functioning as normal. You’ll need this information to confirm the steps have worked successfully.
Once you’ve made sure access work as expected, there are no errors and Exchange services are humming along like clockwork, you can enact the same change in your live environment. Don’t forget to alert your users in advance, take backups or snapshots of the systems involved, and test all functions before and after you follow the steps in this article.
