3. Working with Exchange Server certificates
When
you install an Exchange server, the setup process creates several
self-signed security certificates that are used for authentication. The
default certificates available depend on whether the server has the
Mailbox Server role, the Client Access Server role, or both installed
and can include:
-
Microsoft Exchange
. A self-signed certificate used by IMAP, POP, IIS, and
SMTP. If Autodiscover is configured, this certificate is also used for
Autodiscover. This is the primary certificate used by Exchange.
-
Microsoft Server Auth Certificate
. A self-signed certificate for authenticating SMTP connections.
-
Exchange Delegation Federation
. A self-signed certificate used when federated sharing is configured in the Exchange organization.
-
WMSVC
. A self-signed certificate used by the Windows Management service.
As Figure 3
shows, you can view these certificates in Exchange Admin Center by
selecting Servers in the feature pane and then selecting Certificates.
Because the default certificates are not issued by a trusted authority,
you see a related error message whenever you use HTTPS to access
services hosted by your Client Access servers, including Exchange Admin
Center, the PowerShell application, and Microsoft Outlook Web App.
The best way to
eliminate this error message is to install a certificate from a trusted
authority on your Client Access servers. Web browsers should already be
configured to trust certificates issued by your organization’s
certification authority (CA) or by a trusted third-party authority.
Typically, browsers need additional configuration only when you use
your own CA with non-domain-joined machines.
The services a certificate can be used with include Internet Message
Access Protocol (IMAP), Post Office Protocol (POP), SMTP, Internet
Information Services (IIS), and Unified Messaging (UM). The default
self-signed certificates are assigned services automatically during
setup based on the roles installed on the Exchange server.
When you work with certificates, it’s critical that you ensure the
certificate is used for the right subject name and alternative names.
As an example, the Microsoft Exchange certificate created by default
has the Subject set as cn=ServerName, where ServerName is the name of the server, such as cn=MailServer21, and the Subject Alternative Names is set as DNS Name=ServerName, DNS NAME=FullyQualifiedServerName, and DNS Name=DomainName. If Autodiscover is configured, there’s also a Subject Alternative Name entry for DNS Name=Autodiscover.DomainName. For example, MailServer21 in the Pocket-consultant.com domain means the subject name is set as:
cn=MailServer21
and the Subject Alternative Name entries typically are:
DNS Name = MailServer21
DNS Name = MailServer21.pocket-consultant.com
DNS Name = pocket-consultant.com
DNS Name = Autodiscover.pocket-consultant.com
Real World
I
caution against using Exchange Admin Center and Exchange Management
Shell to work with Exchange certificates. Anyone who has experienced problems after remotely managing Exchange
certificates may agree—and I also have experienced related issues
firsthand on multiple occasions. Specifically, if you modify
certificates using either tool, you might find that Outlook Web App
(OWA) and Exchange Admin Center are inaccessible as a result of a
required SSL certificate becoming corrupted or being invalidated. If
this happens, you will need to access Exchange directly and re-create
the required certificate or certificates.
One way to safeguard yourself against this problem is to create
copies of the original certificates using the Certificates snap-in.
When you add this snap-in to a Microsoft Management Console, specify
that you want to manage certificates for a computer account. You’ll
then find the certificates under the Personal node. Export each
certificate in turn using the Certificate Export Wizard. To start this
wizard, press and hold or right-click a certificate, select All Tasks,
and then select Export.
If your organization has a CA, have your security administrator
issue a certificate. Generate the certificate by completing the
following steps.
-
In a web browser, open Certificate Services by entering the appropriate URL, such as https://CertServer03/certsrv.
-
Specify that you want to create a new request and then choose the advanced creation option.
-
Submit a certificate request by using a base 64 encoded PKS #7 or PKS #12 file.
-
Once the certificate request file is generated, open the file in a text editor.
-
While you are working with Certificate Services in your browser,
access the request. Copy the contents of the certificate request file
and paste them into the request.
-
Select web server as the server type, and leave all other attributes blank.
-
Save the certificate.
After you create the certificate, you must make it available on the
designated Exchange server. To do this, access the Exchange server and
then import the certificate using Import-ExchangeCertificate. Next, use
Enable-ExchangeCertificate to enable the certificate for specific
Exchange services.
If you can purchase a certificate from a trusted third-party
authority, you also must make the certificate available on the
designated Exchange server. To do this, access the Exchange server and
then import the certificate using Import-Exchange-Certificate. Next,
use Enable-ExchangeCertificate to enable the certificate for specific
Exchange services. Finally, ensure that the new certificate is in use
and test web services by using Test-OutlookWebServices as shown in the
following example:
test-outlookwebservices | fl
By
default Test-OutlookWebServices verifies the Availability service,
Autodiscover, Offline Address Book, and Exchange Web Services. You can
test Outlook client connectivity and Outlook Anywhere using
Test-OutlookConnectivity. You can test connectivity to the Outlook Web
App and ECP virtual directories using Test-OwaConnectivity and
Test-EcpConnectivity, respectively. However, before you can use any of
the Test cmdlets, you must create a test account by running the
Scripts\New-TestCasConnectivityUser.ps1 script. You’ll find this script
in the %ExchangeInstallPath%, which by default is C:\Program
Files\Microsoft\Exchange Server\V15\. The password you set for the test
account is temporary and will be automatically changed every seven days.
Once you’ve imported and enabled the certificate, you can
then view the certificate in Exchange Admin Center or by using
Get-ExchangeCertificate to confirm it is configured as expected. You’ll
want to ensure the status is valid, the expiration date is appropriate,
the subject name is correct, the subject alternative names are correct,
and that the assigned services are appropriate.
