Exchange 2016: Configuring certificates (part 1)

I now receive emails every day with questions about certificates and/or Outlook Anywhere. The questions about Outlook Anywhere are usually also related to the certificates. In most cases, the emails end with a sentence similar to this one:

Certificates are a red rag for me!

The sentence comes from an e-mail I received today. Since, as already mentioned, these emails are slowly getting out of hand, I'll try to shed some light on the situation. This article is intended to do just that. This article is deliberately kept as detailed and simple as possible and is aimed at beginners in this topic. I hope it helps some people.

One more request in advance: If anything is unclear, please leave a comment so that I can update the article accordingly.

Background: How do certificates work?

Don't worry, I don't want to go into great detail, but only explain very superficially how a certificate works. Let's take an ID card as an example. An ID card contains personal data to identify me, such as my name, a photo and a signature. An ID card is also issued by a country (or an authority).

Example ID card

If I want to establish the identity of someone I'm talking to, I can ask to see their ID card and compare the data on the card (photo and signature) with the person I'm talking to. If the features match, it is probably the person in question. However, I have to trust someone to do this. Firstly, I have to trust the person I am talking to that they have not forged the ID and I have to trust the state or authority that the identity of the person I am talking to has actually been checked and that the ID itself is therefore trustworthy. After all, my interlocutor could also show me a piece of paper with a photo and signature that he has drawn himself. Of course, I don't accept that as ID.

Example certificates

Suppose I am no longer a person, but a PC that wants to talk to a server. As a PC, I am shown the ID card (certificate) by the server. I can now check the data on the certificate:

• What name is on the certificate?
• Who issued it?
• Do I consider the certificate to be valid?

To be more precise: A certification body (authority/country) issues a certificate, I have to trust this certification body that it has done its job conscientiously and has checked the identity accordingly. A self-issued certificate is similar to a self-painted ID card. If I as a PC am not sure about one of the points, I issue a corresponding warning. We will discuss the consequences later.

That's all the background I need to say. Of course, the topic of certificates is somewhat more complex, but for the time being it will suffice for this article. Encryption, revocation lists, algorithms and what else there is, are of no further interest here for the time being.

Background: Exchange 2016 and certificates

An Exchange server offers several services that can/must be configured with certificates. To stay with the example, a service represents a conversation partner. Essentially, the following services require a certificate (keyword: ID card):

• IIS
• SMTP
• IMAP
• POP

We will leave UC out of the equation at this point. Each of these services (interlocutors) CAN receive its own certificate (ID card), but does not HAVE to. A certificate can be assigned to several services, similar to an interlocutor who speaks several languages but only has one ID card.

One special feature, however, is that an Exchange server has several names that must be present on the certificate. This is comparable to a second first name on an ID card.

Example environment

To make things a little clearer with the ID cards, er... certificates, I have installed a sample environment.

General description

The area essentially consists of three sections:

• A user in the home office (blue)
• The Internet with a hoster for the company (red)
• The company that provides the Exchange Server (green)

The user in the home office only has a normal Internet connection, no VPN or anything else, just a PC with Outlook.

The company provides the Exchange infrastructure, i.e. it has a domain controller and an Exchange server. Whether the company operates the domain controller and Exchange server on a VM or physically, or whether they are a server/VM or separate servers, is irrelevant in this example. The company also has users who access Exchange within its own LAN.

The company has commissioned a hoster on the Internet to host a domain for the company.

The details about the company

The name of this fictitious company is "FrankysWeb". FrankysWeb has an Internet connection with a fixed IP address and an Active Directory which is named "frankysweb.local". The company's e-mail addresses end with frankysweb.de. Internally, the network looks something like this:

• Name of the Active Directory: frankysweb.local
• Name of the domain controller: dc1.frankysweb.local
• Name of the Exchange server: EX1.frankysweb.local
• E-mail address of the internal user: frank@frankysweb.de
• Username: frank@frankysweb.local
• Fixed external IP address: 81.169.145.159

The user Frank uses a notebook and works both internally in the company and in the home office.

The details of the hoster on the Internet

The fictitious company FrankysWeb has commissioned the host Strato to host the domain frankysweb.de.

Strato also hosts the company's website and operates the DNS servers for frankysweb.de

The details of the home office

The home office is often used by the user Frank, here is only a normal Internet connection, without a fixed IP or other configuration. No VPN is used, but mails should be able to be processed in the home office.

Frank wants to use Outlook Anywhere from his PC and ActiveSync from his smartphone. If it has to be quick, he also uses Outlook Web Access. Frank does not want to see any of these errors:

And Frank doesn't want to see the following mistakes either:

Preconfiguration of the sample environment

So far, only the domain controller for the domain frankysweb.local and the Exchange 2016 server have been installed. There is only one accepted domain on the Exchange server, as well as the mailbox for Frank and an address policy that assigns the email address frank@frankysweb.de to the mailbox for Frank. Nothing else has been configured so far. For the sake of completeness, here are the screenshots:

The example environment is therefore more or less a green field. However, most environments in which there are recurring problems with certificates are described in this or a similar way in the emails:

• Active Directory domain name ends with .local or similar
• There is a Domain Controller and an Exchange Server or Exchange and Domain Controller run on one server (unfavorable, but not relevant for this article)
• An Internet connection with a fixed IP is available
• A hoster (Strato, 1und1 HostEurope, etc) hosts the mail domain

The requirements are then quickly defined:

• Outlook Anywhere should/must work
• No more certificate warnings

This article is intended to help you implement these requirements and applies to Exchange 2013 and Exchange 2016 and correspondingly supported Outlook versions.

Exchange in the standard configuration

During the Exchange installation, a certificate is already installed and assigned to the Exchange services. This is a self-signed certificate, like the one in the example environment:

The standard certificate of the sample environment, which is generated during installation, then looks like this in the browser:

The Exchange Server has the name EX1 and has therefore issued itself a certificate with the name EX1, as can be seen in the screenshot above (Issued for EX1, Issued by EX1). To stay with the ID card example: This is the hand-painted ID card, not an official document from an authority, but more comparable to a business card. Any nonsense can be written on business cards, nobody can check whether it is correct.

A small special feature is visible in this screenshot:

The standard certificate already contains two names (DNS name), one is the short name (UNC name) and the other is the FQDN. The standard certificate is therefore already a SAN certificate (Subject Alternate Name). In this case, SAN has nothing to do with storage networks, but refers to a certificate type. Several names are stored on one certificate. In the screenshot above, these are the names EX1 and EX1.frankysweb.local. Back to the ID cards: First name and middle name were entered here, or first name and surname, but that's splitting hairs.

A client connecting to this Exchange server will receive the following error message in the browser:

Whether Internet Explorer, Edge, Chrome or Firefox doesn't matter at first, the error message looks similar everywhere:

Why the error occurs is quickly explained: The self-painted ID is to blame, although there is a name on the ID, no one has checked and verified that this name is actually correct. Simplified explanation: During our ID check, someone is trying to identify themselves with a business card.

Now, of course, the question arises as to who is authorized to issue valid certificates (ID cards) in the first place?

The certification body (example: authority/country)

For a certificate to be considered valid, not only must the name on the certificate be correct, but it must also have been issued by a trustworthy authority. A business card is therefore not enough; an identity card issued by a country or corresponding authority is much more trustworthy. The certification authorities are responsible for issuing the certificates and in this example are comparable to a country or authority. In the following example, the certification authority (CA) Wosign (red box) has issued a certificate for mail.frankysweb.de (blue box):

The screenshot above also shows that certification authorities often have a multi-level structure. The root certification authority (root CA, in the example the country) has signed an intermediate certification authority (sub-CA, in the example the authority) so that the intermediate certification authority can issue a certificate for the server mail.frankysweb.de (in the example the person). As the certificate of the root certification authority is located in the Windows certificate store, the corresponding certificate is recognized as trustworthy, provided the name is correct and the certificate has not expired.

As already mentioned, the root certification authority certificates are located in the Windows certificate store. This store contains a whole series of official certification authorities, all of which have undergone a verification process to ensure that only authorized holders are issued a certificate. The following example shows the certificate for WoSign:

Most Windows programs use the Windows certificate store to check certificates. A well-known exception here is the Firefox browser. Firefox comes with its own certificate management.

Exchange configuration considerations

As already described above, the certificate of the standard Exchange configuration is not sufficient and must be replaced. However, since DNS names (like names on an ID card) must be specified on a certificate, it is first necessary to consider which DNS names and protocols the various programs and devices will use to access the Exchange server. In small environments, this planning is done quite quickly, as almost everything can be realized via a single DNS name, but Autodiscover is an exception: The following table shows the standard configuration:

Service / Protocol	DNS name
OWA (Internal URL)	https://ex1.frankysweb.local/owa
OWA (external URL)	https://ex1.frankysweb.local/owa
OAB (internal URL)	https://ex1.frankysweb.local/OAB
OAB (external URL)	(empty)
ActiveSync (internal URL)	https://ex1.frankysweb.local/Microsoft-Server-ActiveSync
ActiveSync (external URL)	(empty)
MAPI (internal URL)	https://ex1.frankysweb.local/mapi
MAPI (external URL)	(empty)
EWS (internal URL)	https://ex1.frankysweb.local/EWS/Exchange.asmx
EWS (external URL)	(empty)
ECP (internal URL)	https://ex1.frankysweb.local/ecp
ECP (external URL)	(empty)
Outlook Anywhere (Internal)	ex1.frankysweb.local
Outlook Anywhere (external)	(empty)
Autodiscover (Internal)	https://ex1.frankysweb.local/Autodiscover/Autodiscover.xml

In the standard configuration, all access points therefore contain the internal server name and the external ones are empty. Of course, users in the home office cannot do anything with internal server names if they do not have a VPN connection. Furthermore, the best practice for Exchange Server 2013 and Exchange Server 2016 is to keep internal and external access names the same.

So if there is only one Exchange server in the company, this server will be accessed by both internal and external users.

Since in this case we are the lucky owners of a public domain with a hoster, we can define a public name using a subdomain. For the domain frankysweb.de, Exchange access could therefore take place via the following subdomain: mail.frankysweb.de (alternatively any other name that users can easily remember).

A small exception is Autodiscover, the Autodiscover entry should always be published under autodiscover.domain.tld, the publication of autodiscover under the corresponding name prevents a warning that is displayed once by Outlook. For the domain frankysweb.de the autodiscover entry would therefore be autodiscover.frankysweb.de.

Taking best practice into account (internal and external names the same, no internal names on public certificates, autodiscover with separate names), this would result in the following configuration:

Service / Protocol	DNS name
OWA (Internal URL)	https://mail.frankysweb.de/owa
OWA (external URL)	https://mail.frankysweb.de/owa
OAB (internal URL)	https://mail.frankysweb.de/OAB
OAB (external URL)	https://mail.frankysweb.de/OAB
ActiveSync (internal URL)	https://mail.frankysweb.de/Microsoft-Server-ActiveSync
ActiveSync (external URL)	https://mail.frankysweb.de/Microsoft-Server-ActiveSync
MAPI (internal URL)	https://mail.frankysweb.de/mapi
MAPI (external URL)	https://mail.frankysweb.de/mapi
EWS (internal URL)	https://mail.frankysweb.de/EWS/Exchange.asmx
EWS (external URL)	https://mail.frankysweb.de/EWS/Exchange.asmx
ECP (internal URL)	https://mail.frankysweb.de/ecp
ECP (external URL)	https://mail.frankysweb.de/ecp
Outlook Anywhere (Internal)	mail.frankysweb.de
Outlook Anywhere (external)	mail.frankysweb.de
Autodiscover (Internal)	https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml

The certificate now results from this configuration.

Considerations for the certificate

The requirements for the certificate already result from the configuration above. Only the FQDNs (DNS names) are specified on a certificate, not URLs! Therefore, only one certificate with exactly two names is required:

• mail.frankysweb.de
• autodiscover.frankysweb.de

In this case, a SAN certificate (Subject Alternate Name) is therefore required, which contains the names specified above. Nothing more.

However, the certificate must be issued by a certification authority if it is to be recognized as valid. It is possible to operate a certification authority yourself, but this is usually not worth the effort in small environments, as a corresponding certificate is available free of charge or for a small fee. In addition, an own certification authority that is installed on a Windows server is only trustworthy within the Active Directory. A smartphone or a client that is not a member of the Active Directory will not regard the certificate as trustworthy and will again react with the familiar errors.

My recommendation is therefore to obtain the appropriate certificate from an official certification body.

Exchange Server configuration

As this article has already become quite long, the configuration will be covered in the next article. As soon as the article is online, I will link to it here.

Update: TPart 2 is now also available.