[Update]: This post was updated on May 25, 2017.
After a successful Exchange Server upgrade or completely new deployment, many administrators decide to purchase a SAN (Subject Alternative Names) certificate for their organization. These certificates are perfect for securing Exchange services such as OWA, ActiveSync, POP3 and IMAP because they allow for multiple domain names in a single SSL certificate.
Creating a self-signed certificate within your own domain is also an option, but, without a certificate issued by a certificate authority, users accessing your services from outside of the domain will receive a security warning like the one below:
In this article I discuss how to obtain and install a CA-signed SAN certificate, and how to deploy split-brain DNS, letting your internal and external users access certified services without issues.
Before you purchase a certificate, it’s worth taking a moment to find out which type best fits your needs.
A SAN certificate is a good choice if you want to use multiple names or domains, e.g.: www.example.com, www.different-domain.com, mail.example.com, etc. It’s also relatively low priced – including 4 domains in it costs circa $250 per year.
Wildcard certificates are the way to go if you want to cover an unlimited number of subdomains within one domain (*.example.com). However, their cost is significantly higher. For an annual subscription, your may end up paying around $500.
In this article, I will use example.com as the external domain’s name and example.local as the internal domain’s name.
In a small Exchange 2013 deployment these two namespaces should be included in the certificate request first and foremost:
- autodiscover.example.com – for the Autodiscover service, which is necessary to find users’ settings;
- mail.example.com – for OWA, Active Sync and Outlook Anywhere.
To have your mail encrypted using TLS, you will also have to include the FQDN of your send connector in the certificate:
If users in your organization utilize POP3 and IMAP protocols, the following names should also be included in the certificate request:
Apart from Exchange services, you may also want to use the certificate for multiple web applications. In this case, you should consider purchasing a wildcard certificate.
Creating a certificate request in Exchange 2013/2016
The first step to obtaining a digital certificate is creating a new certificate request in the Exchange admin center on your Exchange 2013/2016 server. To do this you have to log into EAC and go to servers, certificates.
Click the plus button to open a new Exchange certificate request creation wizard. Select the first option: Create a request for a certificate from a certification authority.
Type in a „Friendly name” for the certificate (this will be the certificate’s display name):
After clicking next you will get an option to request a wildcard certificate. In this example we’re only interested in SAN certificates, so proceed to the next step by clicking next. In the subsequent window select the server on which the certificate request will be stored and click next:
The next window contains a list of suggestions of service related domains you may want to certify. You can skip this step because the final list of domains which will be included in the request can be edited and confirmed in the next window:
The subsequent window is very important – this is where you provide your organization’s details. Certificate providers often check these details against information in WHOIS databases – irregularities may impede the certification process. Another thing to remember is that certification centers often send verification emails to typical domain administrator email addresses such as [email protected] or [email protected]
The last window of the wizard requires you to specify the path of a file where the certificate will be saved. The path has to be provided in the UNC format and the Exchange Trusted Subsystem group must have permissions to write in this location.
After clicking finish a new entry with the status “Pending request” should appear in the list of certificates in your Exchange admin center and a new file with a .reg extension should be created on your C: drive.
Sending the certificate request to an external CA
Once you have the certificate request ready, you can send it to an external Certificate Authority (CA) of your choosing. When comparing options, remember that important criteria (other than the cost) include: compatibility with Exchange 2013/2016, availability of support, and the right to repair potential errors in a certificate.
In many cases, order forms on CA’s websites allow for pasting/uploading CSR files. A CSR file is nothing more than a text file formatted like this:
—–BEGIN CERTIFICATE REQUEST—-
(string of characters)
—–END CERTIFICATE REQUEST—-.
The string of characters in the CSR file is the same string of characters that you will see when you open your .reg certificate request file (the one saved to the UNC path) in Notepad. Copying its contents into the certificate order form will result in displaying the domain names you entered earlier.
The process of verification of the domain owner depends on the CA. Typically, the CA will contact you by sending emails to standard addresses I mentioned before. To complete the verification, they may e.g. request that you include certain text records in your public DNS.
Completing a pending request
Once you have met all the certification requirements and paid for the requested certificate, you should receive an email from the CA with an attached zip file. The zip file will contain installation instructions and a .cer certificate file. After saving the .cer file to your disk, follow these steps:
In Exchange admin center go to servers, certificates and click the pending certificate request. In the bar on the right click Complete.
A new window will pop up where you will be prompted to provide the UNC path to the .cer certificate file you have received from the CA.
After the certificate is uploaded, its status should change from Pending request to Valid.
Assigning services to a certificate
Now that you have a valid SSL certificate installed on your Exchange server, you can proceed to assign specific services to it. To do this, in Exchange admin center go to servers, certificates, select the newly installed certificate and click the pen button above the certificate list. In the resulting window select the services tab and assign the certificate to services of your choosing (in my example it’s SMTP, IMAP, POP and IIS).
All that’s left now is configuring external access domains for all necessary virtual directories. This has to be done separately for each directory* but is very simple – in the Exchange admin center go to servers, virtual directories, select a server, highlight the entry you want to configure and click the wrench button. In the resulting window select a client access server and type in your external domain.
* To configure access to the Autodiscover service you have to use PowerShell. More on the subject in the ‘Split-brain DNS method’ section below.
Time to finish up. Set the CNAME or A record on your DNS server so that the external domain points to your organization’s external IP address. Next, remember to redirect port 443 in your firewall/router to your Exchange 2013/2016 server’s internal IP address.
The easiest way of verifying that the certificate has been installed correctly is by accessing your external OWA address (e.g. https://mail.example.com/owa) from outside of your domain. With everything set correctly, the OWA login page will load without warnings.
The address bar will include a lock icon indicating that the connection is secure:
The color of the icon depends on your browser. The important thing is that upon clicking the icon a window will expand with information about the installed certificate and connection status.
Split-brain DNS method
This method lets you set up your internal DNS server so that your internal users can access virtual directory resources using external domain names, without receiving security warnings or their queries being routed via external servers. In this example, I will use split-brain DNS in my Exchange 2013 infrastructure (same steps for Exchange 2016), so that the mail.example.com domain becomes available for internal users and they don’t receive a certificate error warning when accessing it.
The first thing we have to do is provide an internal URL for every Exchange 2013/2016 virtual directory. The process is similar to setting external access domains, which I explained in the previous section.
In the Exchange admin center go to servers, virtual directories and select the server in the select server dropdown menu. Next, highlight a directory and click the edit button (pen icon) above the directory list. In the resulting window change the Internal URL to https://Your External Domain/Directory (e.g. https://mail.example.com/ecp).
Important! The internal URL of the Autodiscover virtual directory can only be changed via Exchange Management Shell using the below command:
set-clientaccessserver –autodiscoverserviceinternaluri “https://Your External Domain/autodiscover/autodiscover.xml”
For Exchange 2016 run:
Set-ClientAccessService -Identity Server_Name -AutoDiscoverServiceInternalUri https:// Your_External_Domain/Autodiscover/Autodiscover.xml
After changing the virtual directories’ internal URLs, you have to change the DNS setting so that it points to your Exchange 2013/2016 server’s local network IP address. To do this, open DNS Manager, in the console tree right-click Forward Lookup Zones and select New Zone…
Select Primary zone and click Next:
Select the option to replicate the zone To all DNS servers running on domain controllers in this domain:
Important! If the server that hosts your company www or ftp site is located outside your local network (e.g. at an external webhost) it’s best to create separate zones for each domain (autodiscover.example.com, mail. example.com) used by your Exchange 2013/2016. Otherwise, you run the risk of blocking access to the company website for internal users, in which case you would have to modify the newly created zone by adding A or CNAME records for external services.
In the next step, type in the name of the zone (e.g. the domain for which it is created):
Next, select the Do not allow dynamic updates option:
The last window will contain a summary of the new zone.
In the newly created DNS zone, create an A record pointing at your Exchange 2013/2016 server’s local IP address.
Repeat the above steps for all necessary virtual directories.
To verify that the settings are correct check if your DNS server resolves external domains, such as mail.example.com, to your local Exchange 2013/2016 server’s address. To do this, in cmd console run the ping command for all domains which now have newly created lookup zones:
If in all instances you receive a reply from the same IP address, this will mean that the DNS setting is correct.
For further verification, delete your mail profile in Windows and run Outlook to confirm that Autodiscover correctly finds your mailbox’s configuration data.
6 thoughts on “How to obtain SAN certificates, and how to deploy split-brain DNS in Exchange 2013/2016”
For Exchange 2016. I am concerned that we did a mistake because we purchased two separate standard ssl certificates. So each one is a separate certificates one common name mail.domain.com and an additional one autodiscover.domain.com
And it looks like for IIS service you cannot assign multiple certificates, just one single certificate.
Can anyone clarify and elaborate how autodiscover should be implemented correctly? Do we need to have one single SAN certificate ?! mail.domain.com with an addition alternative subject name for autodiscover.domain.com?!
Is there anything we can do since we purchased two individual/separate SSL?! At this point mail.domain.com certificate is assigned for smtp and IIS. When we do the auto discover with Outlook we get the error is not matching the name autodicover for certificate because obviously mail.domain.com is assigned for IIS and SMPT as certificate. Hopefully someone can advice! Thank you.
You saved me!
This is the best explanation about how to solve the .local problem I’ve seen….OK the only one that works that doesn’t require renaming the domain. I’ve spent hours on this…
THANK YOU! I owe you lunch!!!!
Thanks, always happy to help!
Actually, this did work, but be aware that you will not see the URL you set via the Get-AutodiscoverVirtualDirectory cmdlet. You WILL see verification using the Get-ClientAccessService cmdlet.
Please see: https://technet.microsoft.com/en-us/library/mt441779(v=exchg.150).aspx
You can not set the autodiscover internal URL in Exchange 2016, despite the presence of the parameter
Swing and a miss.
That is strange because the
Get-ClientAccessService | FL *cmdlet shows the AutoDiscoverServiceInternalURI is set. Have you tried setting it up on your own?
CodeTwo sp. z o.o. sp. k. is a controller of your personal data.