Site icon Franky's Web

Exchange 2016: Configuring certificates (part 2)

Frank Zöchling

This is the second part of the article series. As already announced in the first part, this article deals with the configuration.

Important: Beforehand absolutely read the first partas this article builds directly on it.

Exchange 2016 configuration

The first part ended with the considerations for the URLs to be used to access Exchange. For the sake of simplicity, here is the table with the URLs again:

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 configuration of the URLs is important for Autodiscover. These URLs are distributed to Outlook by Autodiscover so that Outlook can find the corresponding Exchange server. If the virtual directories are not configured with the corresponding URLs, certificate errors will occur again later. It is therefore important to ensure that a corresponding internal and external URL is set for each virtual directory. Autodiscover will otherwise distribute incorrect URLs to the clients.

The URLs can be set via the Exchange Administrative Center, here for OWA:

here for ECP:

All virtual directories are configured in this way, with the exception of "Powershell" and "Autodiscover". "PowerShell" and "Autodiscover" are _NOT_ changed and do not receive any new URLs:

This means that only the following virtual directories are filled with the URLs from the table:

 

Once the virtual directories have been configured, the host name for Outlook Anywhere can also be assigned; this is also possible via the Exchange Administrative Center:

One small exception is the autodiscover URL for the CAS service, which can only be set via the Exchange Management Shell. The internal server name is also entered here by default:

The URL is changed accordingly with the following command:

Set-ClientAccessService EX1 -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"

After these steps have been carried out, the IIS server can be restarted using "iisreset":

The Exchange configuration is now complete and we will continue with the required DNS entries.

DNS configuration

After the above steps, Exchange will only listen to mail.frankysweb.de and Autodiscover to autodiscover.frankysweb.de. To ensure that these two FQDNs can now also be resolved in the internal network as well as from the Internet (home office), corresponding DNS entries must be configured.

Once again, the communication process (simplified)

An internal computer usually has the domain controller configured as DNS server. Outlook on the internal computer will first request autodiscover.frankysweb.de to find the Exchange Server. The DNS server on the domain controller responds to the client's query with the internal IP address of the Exchange server. The client retrieves the configuration and then queries the internal DNS server for mail.frankysweb.de. The image shows the DNS queries and responses in simplified form (green and red arrows):

The same applies to clients in the home office. Most routers will have a DNS forwarder running. This DNS forwarder on the router forwards the client's DNS queries from the home office to the corresponding DNS servers on the Internet. There are still several DNS servers involved here, but ultimately the hoster's DNS server will have to respond to the autodiscover. The queries to autodiscover.frankysweb.de and mail.frankysweb.de should now be answered with the external IP address of the company's Internet connection. The Outlook connection will therefore follow this path (blue arrows)

Internally, Outlook will connect to mail.frankysweb.de which points to the internal IP address of the Exchange server. Externally, it will also be mail.frankysweb.de, with the only difference that the external IP will now be resolved.

To do this, the DNS servers must be configured accordingly:

Configure internal DNS server

As Autodiscover will now distribute the URLs as specified above after configuration, the URLs must now also be available. On the domain controller, the DNS zones will look something like this:

As the ActiveDirectory in this case has the name frankysweb.local, there are two corresponding internal zones and normally also a reverse lookup zone with the corresponding subnets.

Internally, however, Exchange must now be accessible via the names mail.frankysweb.de and autodiscover.frankysweb.de, as these names have been configured accordingly. A new DNS zone is therefore created first:

The zone type is left as "Primary zone":

Zone replication can also be left as it is:

The zone name "mail.frankysweb.de" is entered:

Dynamic updates can be switched off:

A new HOST-A entry is now created within the new zone:

_KEIN_ Name is configured for the HOST-A entry. The internal IP of the Exchange server is entered in the IP address field and the "Create linked PTR entry" checkbox is unchecked:

It should now look like this:

The steps are repeated accordingly for Autodiscover. Another new zone with the name "Autodiscover.frankysweb.de" is created:

A HOST-A entry with the internal IP of the Exchange server is also created in the autodiscover.frankysweb.de zone:

The two zones can now be checked using nslookup.

Autodiscover.frankysweb.de and mail.frankysweb.de must point from an internal client/computer/server to the internal IP of the Exchange server:

Configuration of external DNS (hoster)

In order for the Exchange server to be accessible from the Internet (home office) under the name mail.frankysweb.de, the corresponding DNS entries must be set at the domain hoster. Depending on the hoster (Strato, 1und1, HostEurope etc.), the configuration process is slightly different. In this example it is Strato:

First, two new subdomains are created:

One is the subdomain with the name "mail", which results in "mail.frankysweb.de":

The same applies to the subdomain with the name "autodiscover", resulting in autodiscover.frankysweb.de.

An A-record is now defined for both subdomains:

The external IP address of the company's Internet connection is specified as the IP address:

Note: This is the WAN IP of the company's router / firewall.

The WAN IP is entered for autodiscover and mail. The overview of the domain should now look something like this:

Autodiscover.frankysweb.de and mail.frankysweb.de each have an A-record with the company's external IP address.

The DNS resolution using nslookup should now return the external IP for autodiscover.frankysweb.de and mail.frankysweb.de:

The port forwarding on the company's router is still missing so that the Exchange server can also be reached on port 443.

Configuration of port forwarding on the router / firewall

The END entries have now been configured, but port forwarding is still missing on the company's router so that the Exchange server can also be reached from the Internet via port 443. Again, the setup depends on the router or firewall used. The name also varies from manufacturer to manufacturer, NAT rule, port forward, DNAT, port forwarding or port sharing are common terms here.

The logic behind this is as follows:

A connection that arrives at the external IP address of the router on a specific port is forwarded to an internal IP address and port.

Note: Setting up port forwarding makes the Exchange server accessible from the Internet via port 443. It would be better to use an appropriate firewall or proxy (Here is an example) between the Internet and Exchange Server. However, the setup is not the subject of this article.

If the company has a Fritzbox, setting up port sharing works as follows:

As can be seen in the screenshot, only port 443 (TCP) is forwarded to the internal IP of the Exchange server on port 443.

The red scarf (Exchange Certificate)

Finally, it is the turn of the "red cloth", better known as the certificate. However, if the preparations have all been completed, this is no longer a problem.

Let's briefly return to the background:

In the previous configuration, the virtual directories and the Outlook Anywhere configuration were adjusted so that they listen to mail.frankysweb.de. This FQDN then results in the corresponding URLs with which the directories (internal and external URLs) were configured accordingly. Internal and external DNS have also been configured so that the Exchange server can be reached under these URLs. This means that only the following FQDNs are relevant for the certificate:

Nothing else needs to be on the certificate. Just these two names. In case anyone is already wondering: What if I have several domains and also e-mail addresses with, for example, "@frankysweb.com"? Read more, coming soon...

To save the certificate request, a folder should be created in advance. Preferably on the Exchange server itself under C:\. In this case it is C:\Certificate:

The certificate request can now be created.

Create certificate request

A certificate request is required so that a certification authority can issue a certificate. The certificate request informs the certification authority of the properties for the certificate. To stay with the ID card example: The certificate request is the application for an ID card, whereby the application contains the name, address, etc. The application (certificate request) must now be issued by an authority/country (certification body).

A certificate request can be created via the Exchange Admin Center:

The display name "mail.frankysweb.de" is entered:

The next dialog can be left as it is, nothing needs to be selected here:

The certificate is stored on EX1 on the Exchange Server:

All URLs are displayed again in the following dialog:

If you scroll through the list, you will notice that internal server names and URLs are still displayed here. These can also be left as they are:

The entries for the certificate can be edited in the next dialog. Everything is now deleted here so that only "mail.frankysweb.de" and "autodiscover.frankysweb.de" remain.

Before:

After:

Now a few details need to be completed. The organization name corresponds to the company name, the department name can be freely chosen, city, state and country should be clear:

Finally, the storage location for the certificate request is specified. The folder c:\Certificate was created on the Exchange server in advance. This folder can now be accessed via Administrative Sharing:

The request has been created and you can now see a pending request in the Admin Center:

Pending request in this case means as much as: Application completed, but no card issued yet.

A file with the name "Request.txt" can now be found under C:\Certificate. This file contains the request for the certification authority, also known as the "Certificate Signing Request" (CSR):

The application (CSR) must now be submitted to a certification body.

Request a certificate from an official certification body

The previously generated request must now be submitted to a certification body. The certification authority then issues a corresponding certificate.

As already mentioned several times, there must be two names on the certificate (SAN certificate) (autodiscover.frankysweb.de and mail.frankysweb.de). This is also stated in the generated request. The reseller PSW offers a corresponding certificate quite cheaply:

https://www.psw-group.de/ssl-zertifikate/detail/c44-geotrust-quickssl-premium/

3 years validity costs 99 EUR. Various other CAs also offer certificates free of charge, whereby StartSSL, probably the best-known representative, has had problems with Mozilla (StartSSL and WooSign have not taken their own security very seriously).

However, the process for submitting a request is similar for most certification bodies:

  1. Log in
  2. Submit certificate request
  3. Go through validation (the procedure can vary, usually an email to webmaster@domain.tld or hostmaster@domain.tld)
  4. Certificate received
  5. Payment (possibly also free of charge)

Despite the problems with StartSSL, certificates can still be applied for, as the process is relatively similar for most certification authorities, here is the example with StartSSL. The registration has already been completed:

The two DNS names must then be entered in StartSSL and the content of the Request.txt file uploaded:

After appropriate validation by the certification authority, you will receive the certificate. StartSSL can still be used wonderfully for test environments, I assume that the problems with Mozilla will be resolved in the foreseeable future.

For productive environments I would recommend buying a certificate, the price in the above example is certainly not too high and with a 3-year term quite affordable.

As soon as you have received the certificate from the certification authority (usually by download or email), it can be saved on the Exchange server under C:\Certificate.

Most certification authorities issue the certificate in different formats. Exchange Server can handle .CER and .CRT files. In this example, it is a .CRT file:

Complete certificate request and assign services

As soon as the certificate has been saved in the C:\Certificate folder, the pending request can be completed. This process can be carried out again using the Exchange Admin Center:

The administrative release and the name of the certificate are then specified again in the dialog:

As soon as the request has been completed, the certificate is marked "Valid":

A valid certificate is now available, but this certificate has not yet been assigned to the Exchange services.

To ensure that Exchange continues to use this certificate in the future, it must be bound to the relevant services. To do this, double-click to open the properties of the certificate and assign the following services:

 

The warning must be confirmed, then the certificate is replaced:

From now on Exchange will use the new certificate.

Review

Several tests can now be carried out to check this.

First, the DNS resolution of internal and external computers can be tested:

Internally, the internal IP of the Exchange server must be resolved, externally the corresponding IP of the router with port forwarding.

Outlook Web Access can then be accessed from internal and external computers, in each case under the name mail.frankysweb.de. A certificate warning must no longer appear when calling up the program:

Both names must be entered in the certificate details under "Alternative applicant name":

Outlook only shows mail.frankysweb.de as the server name in the connection status, internal names may no longer appear here:

The Outlook mode "Test e-mail autoconfiguration" only returns URLs with https://mail.frankysweb.de/...

Exchange Remote Connectivity Analyzer passes the autodiscover test cleanly:

An error may occur with the URL "https://frankysweb.de:443/Autodiscover", as Exchange cannot be reached under this URL, for the URL "https://autodiscover.frankysweb.de:443/autodisover" it must run through cleanly (without certificate warning)

Addendum

This was the basic configuration with one e-mail domain and one official certificate. Now there are of course other cases with an internal certification authority or several e-mail domains. This will be a case for part 3 (already in progress, will be linked when ready).

Exit mobile version