Exchange 2010: Using certificates from Let's Encrypt (Part 1)

Certificates from Let's Encrypt are becoming increasingly popular, which is hardly surprising as the certificates are free and there are simple clients to obtain the certificates. Let's Encrypt certificates are only valid for 3 months, but the available clients take care of renewing the certificates.

Exchange 2016 can even be used with a small PowerShell Script completely automatically. In principle, this can also be done with Exchange 2010, which some have already requested and even modified the script themselves. However, a little preparatory work is required so that no certificate warnings appear later.

I have therefore set up a small demo environment consisting of a domain controller and an Exchange 2010 server to illustrate one of the possible configurations.

The Active Directory has the name frankysweb.local. The users use the e-mail addresses @frankysweb.org. An environment of this type is likely to be found quite frequently, which is why I am also using this environment for this HowTo.

The domain controller is also named dc.frankysweb.local and the Exchange 2010 server is named ex2010.frankysweb.local.

For Exchange 2010, it is best practice to separate internal and external access points. This small environment will therefore use the following access points:

• outlook.int.frankysweb.org (internal access point)
• outlook.frankysweb.org (External access point)
• autodiscover.frankysweb.org (Autodiscover internal and external)

The Exchange Server is connected directly to the Internet via a router:

Corresponding port forward rules are set up on the router. Ports 80, 443 and 25 are forwarded directly to the Exchange server. Port 25 is not relevant for this article. Port 80 and 443 are mandatory.

Note: The HowTo consists of two articles, please wait for both articles first. See "Next steps" at the end of the article. The section "Exchange CAS Array" is also important!

DNS

After the test installation, the DNS on my domain controller only recognizes the zone "frankysweb.local", in this zone there is also the Host-A entry of the Exchange server with the name EX2010:

I have not yet made any configuration in this test environment, which means that Outlook now establishes a connection to the Exchange Server with the name "EX2010.frankysweb.local". This can also be seen in the Outlook connection overview:

As long as the DNS name "EX2010.frankysweb.local" is present on the certificate for Exchange, this is not a problem. Let's Encrypt, as well as all other CAs, do not issue certificates for private TLDs (.local, .intern, etc). You can issue such certificates with your own CA, but this does not work with public CAs, also because in the case of Let's Encrypt the internal name cannot be verified.

The connection must therefore be established via a publicly valid DNS name. To achieve this and at the same time implement the Exchange 2010 best practice "Separate internal and external access points", two new zones are first created on the internal DNS. DNS Split Brain is therefore used here in the classic way.

The "int.frankysweb.org" zone only receives a HOST-A entry with the internal IP of the Exchange server. The DNS name outlook.int.frankysweb.org is then used later for internal access:

The "frankysweb.org" zone receives two HOST-A entries with the names "outlook" and "autodiscover". These two entries are later also created at the hoster of the public DNS zone and are used for Outlook Anywhere and Autodiscover:

This results in 3 DNS names for the Let's Encrypt certificate:

• outlook.int.frankysweb.org (internal access point)
• outlook.frankysweb.org (External access point)
• autodiscover.frankysweb.org (Autodiscover internal and external)

More on this later.

Exchange CAS array

The Exchange 2010 CAS array is a bit tricky. In the default configuration, no CAS array is configured, which means that all Outlook connections are established to the local FQDN of the Exchange server. This becomes clear in Outlook connection status:

With the CAS array it is possible to change the FQDN of the Exchange Server, this is a prerequisite when configuring a highly available Exchange environment, but also to get rid of the local server name of a single Exchange Server.

The common thing about the CAS array is the followingIf there are already Outlook profiles that use the local FQDN and the CAS array is subsequently set up, the Outlook profile does not change. In concrete terms, this means that Outlooks that have already been set up are not referred to the new FQDN of the CAS array, but retain the old FQDN. The only thing that helps here is to recreate the Outlook profile after setting up the CAS array, or to create it with the "RichProfile" to be changed subsequently.

To create a CAS array and change the FQDN for access, the following command is executed on the Exchange Shell:

New-ClientAccessArray -Name CASArray -Fqdn outlook.int.frankysweb.org -Site Default-First-Site-Name

The CAS array has now been created and must then be assigned to the mailbox databases:

Set-MailboxDatabase MBDB1 -RpcClientAccessServer outlook.int.frankysweb.org

After the existing Outlook profile has been recreated, or the profile has been customized with the tool mentioned above, the connection now runs against "outlook.int.frankysweb.org"

The remaining Exchange URLs can now also be customized.

Exchange URLs

The remaining URLs for the respective Exchange services can now also be adapted so that no certificate warnings occur later and Autodiscover works properly.

First, the Autodiscover URL is changed to "autodiscover.frankysweb.org":

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.frankysweb.org/Autodiscover/Autodiscover.xml

Outlook Anywhere can then be switched on or, if Outlook Anywhere is already switched on, the host name can be changed to "outlook.frankysweb.org". Only the external host name needs to be specified for Outlook Anywhere, the internal name is the FQDN of the CAS array that has already been configured:

The virtual directories are now configured with the corresponding URLs. internal FQDN is outlook.int.frankysweb.org and external FQDN is outlook.frankysweb.org, which then results in the URLs. Here in the example for OWA:

The same applies to ECP:

And here for ActiveSync:

And also for the OAB:

There is another directory which cannot be configured directly via the Exchange Console, but only with the Exchange Shell. To change the EWS URL, the following command can be used:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl https://outlook.int.frankysweb.org/EWS/Exchange.asmx -ExternalUrl https://outlook.frankysweb.org/EWS/Exchange.asmx

After all URLs have been adjusted, the IIS is restarted once:

iisreset

The Outlook Autodiscover test should now only distribute the appropriately configured URLs for internal and external access points. The internal FQDN "EX2010.frankysweb.local" must no longer appear:

Next steps

Without a valid certificate, certificate warnings will now appear. In the second part, the external DNS is adjusted and the Let's Encrypt certificate is configured.