Managing Exchange Certificates
An overview of the different Exchange components that use certificates.
If you would like to read the other parts in this article series please go to:
Certificates can be used to encrypt the communication flow between two endpoints (both clients and servers). Certificates can also be used by these endpoints to authenticate themselves from each other. Exchange 2007 uses X.509 certificates for authentication and for encryption. X.509 certificates follow a standard format as published by the Telecommunication Standardization Sector (ITU-T).
An X.509 certificate is issued by a Certificate Authority (CA) that will bind the public key to a designated Distinguished Name, formatted according to the X.500 tradition, or to a so-called Subject Alternative Name or any of the Subject Alternative Names.
There are several components in Exchange 2007 that rely on certificates for encryption, authentication or both. In this article I will provide you with an overview of the different Exchange components that use certificates. I will then go deeper into the features of the by-default generated self-signed certificate. In part 2 of this article I will cover the naming requirements of a certificate you need to keep in mind when getting your certificates. To end, in part 3 of this article I will take a closer look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
Certificate Usage by Exchange Server 2007 Components
As already stated, several Exchange Server 2007 components rely on X.509 certificates for encryption, authentication or both. You will notice that when you install the Exchange 2007 Hub Transport server role, Client Access server role, Unified Messaging server role, and Edge Transport server role, Exchange will create by default a self-signed certificate to make sure its required components can use that certificate to function as required.
Figure 1 below shows you the self-signed certificate that is created by Exchange during the installation of the Exchange 2007 Client Access, Hub, and Unified Messaging server role. This certificate will be used by the following services: IIS, SMTP, POP, IMAP, and UM.
Figure 1: Self Signed Certificate created by default when installing the Exchange 2007 HUB, CAS, UM server role
Hub/Edge Transport server role and certificates
Transport Layer Security between Active Directory sites
The Exchange 2007 Hub Transport server role uses a certificate to encrypt all SMTP traffic between Active Directory sites. It is not possible
to configure Exchange to allow unencrypted SMTP traffic between Hub Transport servers, located in different sites.
In order to see which certificate is used between two Hub Transport servers located in different Active Directory sites, you can enable SMTP protocol logging on the intra-organization Send connector on every Hub Transport server, as you can see in figure 2 below, by using the Exchange Management Shell cmdlet Set-TransportServer.
Figure 2: Setting IntraOrgConnectorProtocolLogging to verbose
By setting the so-called IntraOrgConnectorProtocolLoggingLevel to verbose, protocol logging will be added to the Send connector protocol log. After sending a mail from a mailbox homed in Site B to a mailbox located on an Exchange 2007 Mailbox server in Site A, looking at the Send protocol log reveals that the Exchange Hub Transport server in Site B (Ex2007SE) uses the certificate offered by the Exchange Hub Transport server in the destination Active Directory site (Ex2007EE) to start Transport Layer Security, as can be seen in Figure 3.
Figure 3: Send Protocol Log between Active Directory Sites
A quick look at the certificate on the Hub Transport server available for TLS, shows that it is a self-signed certificate used (Figure 4).
Figure 4: Self Signed Certificate
Once EdgeSync is configured between your internal Hub Transport servers and the Edge Transport server(s), both servers will use a certificate to encrypt their communication. In addition both certificates will be used as a means to provide direct trust. Direct trust is a method of authentication where a certificate can be used for authentication when the provided certificate is present in Active Directory (for the Hub Transport server role) or ADAM/LDS (for the Edge Transport server role). When setting up EdgeSync, the requested certificates are published in the correct location.
Opportunistic Transport Layer Security
Whenever a SMTP server opens a connection to the Exchange 2007 Hub/Edge Transport server role, Exchange will allow for opportunistic TLS, by offering its certificate.
Certificates can also be used by the Hub/Edge Transport server to configure Domain Security with partner organizations, both for encryption and authentication.
Client Access Server role and certificates
Certificates are used by the Client Access server role to allow the communication flow to be encrypted between the Client Access server and its different clients. By default SSL is required for:Source: m.msexchange.org