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 roleHub/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 verboseBy 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).
EdgeSync
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.
Domain Security
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
Client Access
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:
-Outlook Web Access
-Outlook Anywhere
-Exchange ActiveSync
-POP3
-IMAP4
-Exchange Web Services as Autodiscover, EWS, and Unified Messaging
The only virtual directory for which the use of a certificate is not required by default is the one that makes the Offline Address Book available for download by Microsoft Office Outlook 2007 clients and later.
Figure 6: OAB Virtual Directory does not require SSL by default
Certificate Based Authentication
It is possible to configure certificate based authentication, thereby allowing clients to authenticate themselves against the Client Access server by using their personal certificate. For more information.
Unified Messaging Server Role and Certificates
Certificates are used by the Unified Messaging Server role to encrypt the communication when sending a recorded Voice Mail message to the Exchange Hub Transport Server role. Certificates can also be used to encrypt the SIP and/or RTP traffic to the UM IP Gateway, and have to be used when you decide to deploy Office Communications Server in your environment, since Office Communications Server only communicates with other server roles through encryption.
What is all this about the Self-Signed Certificate?
When you deploy any Exchange 2007 Server role, except for the Mailbox Server role, Exchange will generate a self-signed certificate, and allow Exchange to use this certificate when required for the services IIS, SMTP, POP3, IMAP4, and UM.
Characteristics of this Self-Signed Exchange Certificate
Let us have a look at some of the features of this by default generated Self-Signed certificate.
Self-Signed certificates are only valid for one year
Self-Signed certificates are valid for one year, as can be seen in Figure 7, and will need to be renewed after a year.
Figure 7: Self-Signed Certificate only valid for one year
To renew a Self-Signed certificate, you can use the Exchange Management Shell cmdlet New-ExchangeCertificate. If you first grab the existing certificate by running Get-ExchangeCertificate, you can pipe the object to the cmdlet New-ExchangeCertificate, which will generate a new Self-Signed Certificate with the same settings, and enable it for the same services by default.
In Figure 8 you can see how the existing Self-Signed Certificate is renewed.
Figure 8: Renew an existing Self-Signed Certificate
The Exchange 2007 Client Access server only allows one certificate to be enabled for usage with IIS, but you can have multiple certificates enabled for POP, IMAP, UM, and SMTP. When multiple certificates are available, Exchange will select a certificate based on different criteria. I will come back this certificate selection process in part 2 of this article.
Self-Signed Certificate has by default one Common Name and two Subject Alternative Names
The Self-Signed certificate that is created when deploying Exchange 2007 will have its common name set to the Host name of the Exchange server, and have two Subject Alternative Names set to its Host name and its Fully Qualified Domain Name.
Figure 9: Self-Signed Certificate and its Subject and CertificateDomains
It is possible however to generate a Self-Signed Certificate with another Subject and Subject Alternative Names to make sure it can be used in your Exchange organization.
Using the Exchange Management Shell cmdlet New-ExchangeCertificate, you can create for example a certificate with Common Name webmail.proexchange.global, and then specify Subject Alternative Names like the Exchange server its Host and Fully Qualified Domain Name, as seen in Figure 10.
Do not forget to add the boolean parameter PrivateKeyExportable and set it to True, if you want to be able to export this Self-Signed certificate to enable your users to trust it (full details on this in part 2 of the article).
Figure 10: Generating a new Self-Signed Certificate with customized Subject Alternative Names
In part 2 of this article, I will come back to the required names of a certificate. In part 3 I will explain in more detail the used cmdlets.
Self-Signed Certificate are only trusted by its issuer
It is very important to know that the Self-Signed certificate is only trusted by the issuer of the certificate itself, which could break Exchange functionality if not configured correctly. Let us see what you need to consider if you decide to use the Self-Signed certificate:
Outlook Anywhere and Exchange ActiveSync do not support the use of a self-signed certificate
The Autodiscover web service will not check if the issuer of the certificate is trusted when launching Microsoft Office Outlook 2007 from a domain-joined client pc, but will complain about the certificate if you are using Microsoft Office Outlook 2007 from a non-domain-joined client pc, as shown in Figure 11.
Figure 11: Self-Signed certificate not trusted
When Microsoft Office Outlook 2007 clients (domain-joined or not) use the Exchange Web Services provided by the Microsoft Exchange Client Access server, they will be prompted by Outlook that the certificate is not issued by a company they have chosen not to trust. Figure 12 shows the Security Alert shown when someone requests Free and Busy information.
Figure 12: Self-Signed Certificate not trusted
Microsoft does support the use of Self-Signed certificates, but only for internal scenarios, like:
-To encrypt SMTP sessions between Hub Transport servers in different sites;
- To encrypt SMTP sessions between Hub Transport servers and Edge Transport servers;
- To encrypt the synchronization of configuration and recipient information by configuring EdgeSync between internal Hub Transport servers and Edge Transport server(s);
- To encrypt SMTP sessions between Unified Messaging servers and Hub Transport servers;
- To encrypt SIP and RTP sessions between Unified Messaging servers and Office Communications servers (this does require you to make sure that the Office Communication Mediation server trusts your Exchange server as the issuer of that Self-Signed certificate);
- To encrypt internal client access to Exchange (POP,IMAP,Outlook Web Access).
If you do not want Exchange to generate a self-signed certificate during installation, you can specify the /NoSelfSignedCertificates parameter next to Setup in the command prompt. Be careful: this parameter can only be used when installing the Client Access server role or the Unified Messaging server role. If your server does not have a valid certificate available to encrypt communication between clients and the Client Access server or the Unified Messaging server, communication will be unencrypted, and therefore, insecure.
Summary
In the first part of this 3-part article on certificates and Exchange, you have seen which Exchange 2007 components use certificates, and what characteristics the self-signed certificate carries. In part 2 of this article I will show how you can trust the self-signed certificate and I will cover the requirements of a certificate you need to keep in mind when getting your certificates. To end, in part 3 of this article I will give you a close look at the different Exchange Management Shell cmdlets that are available to create, manage, and remove Exchange certificates.
No comments:
Post a Comment