In this HowTo I describe how to install an internal certification authority and how to have a SAN certificate issued for Exchange 2013. This HowTo is not intended for a productive environment. The implementation of a certification authority must be planned carefully.
In my test environment, I have installed 2 Windows Server 2012 Datacenter, 1 DC + CA and an Exchange Server 2013.
Please note that not all functions of the certification authority are available if the CA is installed on Server 2012 Standard. This HowTo therefore only applies to certification authorities running on Windows Server 2012 Datacenter.
The howto for Exchange 2010 and Server 2008 R2 can be found here: https://www.frankysweb.de/?p=456
Installation of the certification authority
First, we install the certification authority on a suitable server. For an Active Directory integrated certification authority (CA), the server must be a member of the Active Directory. Roles and features can be added via the "Server Manager" under "Manage"
The "Role-based or feature-based installation" is selected in the following dialog
If several servers have been added to the server manager, the server on which the role is to be installed can be selected. In this case, it is the local server "DC02"
The "Active Directory Certificate Services" role is now selected
In this case, only the certification authority is required as a role service
After confirming the installation, the role is installed
As soon as the role has been installed, a note on the configuration of the "Active Directory Certificate Services" role appears in the Server Manager
The role is now configured; if you are logged in as a domain administrator, the login information does not need to be changed
The next dialog asks which role is to be configured, as only the certification authority has been installed, no other roles are offered here
You can now select the type of CA to be installed. I select Enterprise Certification Authority so that the CA is integrated into the Active Directory
Since in this example it is the first CA in the hierarchy, i.e. the root certification authority, "root certification authority" is selected as the type
If the CA has not been migrated, a new private key can be created
I leave the cryptography settings at the default values. SHA-1 is not necessarily the best hash algorithm, but it is the most compatible, see here: https://www.frankysweb.de/?p=363
Update: SHA1 will no longer be supported as a signature hash algorithm from 01.01.16. It is better to choose SHA256 straight away.
Now the name of the CA can be assigned. I choose "FrankysWeb-CA". In the default setting, the server name is also entered here, but this could cause confusion if the CA is migrated to another server. A general name is therefore recommended here.
The validity period of the CA can now be defined. The validity period of the CA should exceed the validity period of the certificates to be issued. I choose 20 years here, alternatively you could also use the value "Years until retirement".
The storage location of the database and the logs can be specified in the next dialog. The paths can be customized as desired. I leave them in the default setting
Next, a summary of the settings is displayed, which can be confirmed with "Configure"
As soon as the configuration of the CA is complete, the entry "Certification authority" can be found in the start menu
Customize the certificate template for Exchange SAN certificates
First, we create a new template by right-clicking on Certificate Templates in the MMC via the certification authority, then on "Manage"
Now search for the web server template and click on "Duplicate template"
I choose "Exchange Server Certificates" with a validity of 2 years as the name of the new template
In order to enter all DNS aliases of the Exchange servers later, the checkbox "Include symmetric algorithms permitted by the requestor" must be activated on the "Request processing" tab. If you want to export the certificate later, you should also check the box "Allow export of private keys".
On the Security tab, the "Exchange Servers" group is given full access to the template, and I also give the Domain Admins group full access. The template can then be saved by clicking on "Apply"
Back in the MMC certification authority, the new template can now be added by right-clicking on "Certificate templates" -> "New" -> "Certificate template to be issued". In the next dialog, the "Exchange Server Certificates" template is selected and added.
Applying for a SAN certificate for Exchange
If you want to apply for a new certificate immediately afterwards, you should first update the group policies so that the root certification authority certificate is installed. Certutil /pulse can also do no harm so that the registration policy is displayed.
gpupdate /force
certutil /pulse
An empty MMC can now be opened, to which the "Certificates" snap-in for the local computer is added. Under "My certificates" -> "Certificates", the new certificate for Exchange can be requested via the menu item "All tasks" -> "Request new certificate".
The Active Directory registration policy should now be displayed in the following dialog.
After clicking on "Next", the template just created is displayed, check the box and click on "Additional information..."
The basic information must be provided in the Applicant section:
- Organization (company name)
- Country
- Organizational unit (IT, EDP...)
- General name (for reasons of compatibility, the external access name, i.e. owa.frankysweb.de)
Attention:
Im Abschnitt “Alternativer Name” können/müssen nun DNS-Namen hinzugefügt werden unter denen auf Exchange zugegriffen wird, diese Einstellungen sind abhängig von der Exchange Konfiguration. Die DNS Namen müssen je nach Umgebung die internen Zugriffsnamen „(owa.frankysweb.local) und die externen Namen, also die Namen unter den Exchange über das Internet erreichbar ist (owa.frankysweb.de) enthalten. In dem Screenshot weiter unten sieht man das ich die jeweiligen Exchange Dienste, alle unter separaten DNS-Namen veröffentliche (EAS, OWA, EWS…) Man kann die Dienste auch unter einem Namen zusammenfassen, wie zum Beispiel mail.frankysweb.de/local. Wer es sich ganz einfach machen will, kann an dieser Stelle auch *.frankysweb.local und *.frankysweb.de eintragen. Dabei handelt es sich um ein Wildcard Zertifikat welches alle Hosts die auf frankysweb.local oder frankysweb.de hören akzeptiert. Man sollte sich also VORHER Gedanken machen unter welchen Namen die Exchange Dienste veröffentlicht werden. Ebenfalls sollte der Eintrag autodiscover.frankysweb.de/local nicht fehlen.
A display name for the certificate can be assigned on the "General" tab; this is only used for easier identification.
Once all the information has been entered, the certificate can be requested.
As mentioned above, I have a separate DNS entry for each service. In my test environment, I forward port 443 directly from the firewall to the Exchange server. So I don't have a reverse proxy that is only accessible under the external name. I can only recommend this procedure in test environments, in productive environments a reverse proxy/application firewall should be connected upstream of the Exchange server.
Bind Exchange services to the new certificate
To ensure that the UM services of Exchange 2013 also accept the certificate, the start mode must be changed before the services are assigned. The start mode can be changed via the Exchange Management Shell
Get-UMservice | Set-UMService -UMStartupMode dual
Set-UMCallRouterSettings -UMStartupMode dual
A valid new certificate should now be displayed in the Exchange management console, the Exchange services still need to be assigned to this certificate. Assigning the services can also be done via the console
The created certificate is valid for all Exchange services
The warning indicates that the certificate is being exchanged and can be confirmed with "Yes"
If everything went well, the console should now look like this:
Finally, restart the "Microsoft Exchange Unified Messaging" and "Microsoft Exchange Unified Messaging Call Router" services so that the changes also take effect there.
The certificate of the root certification authority is automatically distributed to all AD members. As soon as the
GPOs have been updated, all clients should trust the certificate and, provided the DNS names have been configured correctly, no more warnings should be displayed. To ensure that smartphones and clients outside the Active Directory also trust the certificate, the root certification authority certificate must be installed. The certificate can be found on the server that has the CA role in the directory c:\Windows\System32\CertSrv\CertEnroll.