How to obtain SAN certificates, and how to deploy split-brain DNS in Exchange 2013/2016

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

Certificate planning

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:

• smtp.example.com

If users in your organization utilize POP3 and IMAP protocols, the following names should also be included in the certificate request:

• imap.example.com
• pop3.example.com

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.

Verification

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:

Ping mail.example.com

Ping autodiscover.example.com

Etc.

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.

Suggested reading:

• Bulk creation of mailboxes on Microsoft Exchange Server 2007/2010/2013/2016
• User mailbox and shared mailbox auditing in Exchange 2013/2016
• CodeTwo Exchange Migration: Easy mailbox migrations to Exchange 2013/2016