Exchange 2007 Certificate Needs – Part 3

This is the third part of a seven-part blog series on Exchange Server 2007, ISA 2006 and certificate design.

TLS Security

OK – trivia time. Who created the technology SSL? I’ll give you a hint – they pioneered web browsing. The answer is Netscape. Because SSL is owned by Netscape – and other companies using similar technology wants to avoid using this “S S L” acronym – a very similar protocol was invented. This new protocol was open and not ‘owned’ by anyone. Now, what to call it… I know… let’s call it TLS. Therefore, when SSL and TLS are mentioned, they can virtually mean the same thing.

Wikipedia opens its TLS article this way – “Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide secure communications on the Internet for such things as web browsing, e-mail, Internet faxing, instant messaging and other data transfers. There are slight differences between SSL and TLS, but the protocol remains substantially the same.”

TLS security in Exchange 2007 and Microsoft Office Outlook 2007 provides a relatively low-cost alternative to S/MIME or other message-level over-the-Internet security solutions. Today’s messaging demands require administrators a way to manage secured message paths between computers over the internal LAN and the public Internet. After these secured message paths are configured, messages that have successfully traveled over the secured path from an authenticated sender are displayed to users as "Domain Secured" in the Outlook and Outlook Web Access interface. This article will discuss the certificate and TLS requirements used by Exchange Server 2007.

Transport Layer Security (TLS) with mutual authentication (MTLS) is used to provide session-based authentication and encryption usually between servers. TLS with mutual authentication differs from TLS as it is usually deployed. Typically, when TLS is deployed, it is used only to provide confidentiality in the form of encryption and it’s usually involving a client connecting to a server – such as a OWA client connecting to a CAS server. In addition to this kind of deployment, sometimes when TLS is deployed, only the receiving server is authenticated. This deployment of TLS is typical of the HTTP implementation of TLS, which is Secure Sockets Layer (SSL).

With mutual TLS authentication, each server verifies the identity of the other server by validating a certificate that is provided by that other server. This scenario is likely what most of us will encounter when deploying Exchange 2007. This was also encountered with Exchange 2003 as well. Regardless of whether the messaging platform is Exchange 2003 or 2007, servers, clients and even mobile clients could get in the act of using certificates to prove authentication, and then data would be encrypted to provide secure transfer of data.

Exchange 2003 vs. Exchange 2007

Exchange 2003 can take advantage of SSL/TLS certificates in server authentication and by clients wishing to use S/MIME, just like in E2k7. However, the majority of clients used certs in E2k3 on the front end servers and ISA servers to protect HTTP, POP, IMAP and SMTP traffic. Very similar to how E2k7 uses certs (which is coming in a subsection below), E2k3 uses them to secure communication. Several differences exist however. E2k3 does not include self-signed certs like E2k7 servers can. This meant that if you wanted certs with E2k3, you had to go through the CSR (Certificate Signing Request) process, send your request to either a commercial or private CA, get the cert back and import it into the proper IIS location. Now, while the self-signed certs, created by default in E2k7, aren’t very useful, they are included for very simple deployments.

For E2k3, the most common need for certs was for two reasons: OWA and RPC over HTTPS. If the customer used ISA as their proxy, then the ISA server would get a copy of the cert and the front end server would get a copy. The back end server didn’t need a cert for OWA or RPC over HTTPS. Just like in E2k7, you had to decide on whether or not you could get a way with certs minted from an inside CA or a public commercial CA. This decision also exists for E2k7 deployments. So what are the real differences between E2k3 and E2k7 regarding certs? E2k7 servers by default use secure communication between themselves – hence the default-created self-signed cert. E2k3 servers such as front end and back end servers didn’t communicate with security by default. The protocol used was SMTP and it wasn’t very secure. The E2k3 mailbox servers used SMTP when communicating to bridge heads or smart host servers. Again, no security by default.

Exchange 2007 Roles with MTLS and TLS Needs

The following Exchange 2007 components use certificates to encrypt or authenticate sessions:

• SMTP   Certificates are used for encryption and authentication for Domain Security between partner organizations. Certificates are used for direct trust connections between Hub Transport servers and Edge Transport servers. Certificates are used between Hub Transport servers to encrypt the SMTP session. In Exchange 2007, direct trust is the authentication functionality for which the presence of the certificate in the Active Directory directory service or Active Directory Application Mode (ADAM) directory service validates the certificate. Active Directory is considered a trusted storage mechanism. Certificates are also used for opportunistic TLS sessions between organizations.
• EdgeSync synchronization   A self-signed certificate created by Exchange 2007 is used to encrypt the LDAP communication session between the ADAM instance on the Edge Transport servers and the internal Active Directory servers after the Microsoft Exchange EdgeSync service has replicated data from Active Directory to the ADAM instance on the Edge Transport server. A self-signed certificate is a certificate that is signed by its own creator. The Microsoft Exchange EdgeSync service is the data synchronization service that periodically replicates configuration data from Active Directory to a subscribed Edge Transport server.
• POP3 and IMAP4   Certificates are used to authenticate and encrypt the session between Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4rev1 (IMAP4) clients and Exchange servers.
• Unified Messaging   Certificates are used to encrypt the SMTP session to Hub Transport servers and to the Unified Messaging (UM) IP gateway and Microsoft Office Communications Server 2007.
• Autodiscover   Certificates are used to encrypt the HTTP path between the client and the Client Access server.
• Client Access applications   Certificates are used to encrypt the path between the Client Access server and various HTTP clients, such as, Outlook Anywhere, Microsoft Outlook Web Access, and devices that support Microsoft Exchange ActiveSync.

Public and Privately-Issued Certificates

I recommend that you deploy a certificate issued by a public CA whenever your users are accessing Exchange components that require authentication and encryption from outside your corporate firewall. For example, all the various clients that the Client Access server role supports, such as Exchange ActiveSync, POP3, IMAP4, and Outlook Anywhere, should be secured with a certificate that is issued by a public CA. In this topic, such components are referred to as external Exchange 2007 components. External refers to the fact that the data paths between the clients and the Exchange 2007 servers traverse the corporate firewall and extend into the Internet.

Internal Client Access to Exchange Can Use Self-Signed Certificates or Certificates Issued by a Internal CA

For MTLS – or server-to-server TLS, you can use an inside private CA to make certificates. As long as the source machine using the certificate to validate the identity of the destination server can verify the name matches the certificate, the certificate validity period is within range and the root CAs certificate can be obtained (validating the source CA minting the certificate), inside certificates will work fine. This is the strategy behind Microsoft using the self-signed certs. By automatically creating the self-signed certs, you are not required to deploy your own internal private CA. Self-signed certificates that are created by Exchange expire in one year, from the time of the server installation. The internal components that rely on the default self-signed certificates continue to operate even if the self-signed certificate has expired. However, when the self-signed certificate has expired, events are logged in Event Viewer. It is a best practice to renew the self-signed certificates before they expire. Because the certificates are self-signed, the resulting certificates are generally less trustworthy than certificates that are generated by a CA. Therefore, I recommend that you use self-signed certificates only for the following internal scenarios:

• SMTP sessions between Hub Transport servers: A certificate is used only for encryption of the SMTP session. Authentication is provided by the Kerberos protocol.
• SMTP sessions between Hub Transport servers and an Edge Transport server: A certificate is used for encryption of the STMP session and for direct trust authentication.
• EdgeSync synchronization between Edge Transport servers and Active Directory: A certificate is used to encrypt the LDAP communication session between the ADAM instance on the Edge Transport servers and the internal Active Directory servers after the Microsoft Exchange EdgeSync service has replicated data from Active Directory to the ADAM instance on the Edge Transport server.
• Unified Messaging communication: A certificate is used for encrypting Session Initiation Protocol (SIP) and Realtime Transport Protocol (RTP) traffic between UM servers and UM IP gateways, IP Private Branch eXchanges (PBXs), and computers that are running Office Communications Server 2007. The certificate is also used for encrypting SMTP traffic when voice mail or fax messages are submitted from UM servers to Hub Transport servers.
• A Client Access server that is accessed only by internal clients.

Ideally, I would recommend using an internal CA’s certificates to replace the self-signed ones to allow for longer validity periods. Again, the self-signed certs are good for one year – internally minted certs can be minted with validity periods of several years requiring less maintenance.

Tip: If you mint the internal certs with a validity period matching the external certs, your certs will expire at the same time and it’s easier to renew all certs at the same time. For example, if all certs are good for two years and you’ve deployed them at about the same time, they will be ready for renewal in two years and you will only have to focus attention to certificate renewal once every two years for all of your messaging cert needs.

External Client Access to Exchange Requires Certificates Issued by a Public CA

Internal Exchange components can rely on self-signed certificates because the certificates are not used for authentication. Authentication for most Exchange components is provided by Kerberos or NTLM. In communication between an Edge Transport server and a Hub Transport server, direct trust authentication is used. This is provided by a certificate and the fact that the Edge Transport server’s public key is stored in Active Directory, which is a trusted store. Otherwise, self-signed certificates are used to provide an ephemeral key to encrypt data paths between Exchange components.

However, for external client access from the Internet into the network where Exchange is hosted, traditional certificate trust validation is required. It is a best practice to use a certificate issued by a public CA for trust validation. In fact, when certificate authentication is required, using a self-signed certificate is not a best practice and is strongly discouraged. I recommend that you use a certificate from a public CA for the following:

• POP3 and IMAP4 client access to Exchange
• Outlook Web Access
• Outlook Anywhere
• Exchange ActiveSync
• Autodiscover
• Domain Security

The best practice for all these is to use a public CA that is trusted by all clients by default.

Determining the Type and Number of Public CA-Issued Certificates for Your Deployment

Selecting the appropriate public CA-issued certificate for your organization depends on the following factors:

• Client support of wildcard names in certificates   Ask yourself: What clients will I support? As mentioned earlier, "clients" in this context refer to clients that access Exchange from the Internet.
• Your organization’s namespace   How is your Internet-facing Internet Information Services (IIS) namespace configured?
• Source of your certificate   Where will you obtain your certificate? Does the public CA you select support using wildcard characters in the Subject or Subject Alternative Name (SAN) fields? If not, does it support using SANs? Are you planning to use Microsoft’s ISA server to publish and protect your Exchange environment?

Client Support of Wildcard Names in Certificates

Wildcard names may be used in the Subject or SAN extensions of X.509 certificates.

After you have determined which clients your organization will support, it is helpful to determine whether the clients support certificates where wildcard names are used in the server certificate that the client is connecting to.

If your client supports using wildcard names in the certificate, the overall certificate planning for your organization is greatly simplified. If all your clients support wildcard names in certificates and your organization uses a single domain name, you do not have to consider namespace planning for your certificate deployment strategy. Instead, you can create a single certificate that supports your namespace with a wildcard character. For example, if clients that are running Outlook Web Access use mail.contoso.com/owa to access their mail, and POP3 clients use pop.contoso.com to access their mail, a single certificate with a wildcard Subject of *.contoso.com will support both clients.

The following Microsoft clients support wildcard names in certificates:

• Outlook
• Internet Explorer (Outlook Web Access)
• Exchange Edge Transport server (Domain Security)

Important:

Clients running Windows Mobile 5.0 and Windows Mobile 6.0 do not support an encrypted channel to servers where wildcard names are used in the certificate.

If a client that your organization supports does not support wildcard names in the server certificate, and you have multiple client namespaces to support, you must either

1. Purchase a certificate that contains multiple names, such as mail.contoso.com, pop.contoso.com, and mobile.contoso.com in the SAN extension.
2. Purchase a certificate for each entity in the namespace that a client will connect to.

Because of the complex nature of having to predict all operating systems that can and cannot accept wildcard cert names, I recommend not planning on using wildcard names for certificates.

Planning for Your Organization’s Namespace

All clients require a URL or a fully qualified domain name (FQDN) to connect to. Each path that clients connect to must be associated with a valid certificate that contains the host name, NetBIOS name, FQDN, or common name of the host that the client is connecting to. Determining the list of names to include on the certificate is the process of namespace planning.

Generally, namespace planning for large organizations that support many different clients and span multiple regions with multiple servers is more complex than namespace planning for smaller organizations.

You must understand certificate namespace planning so that you know which host names to include in the SAN extension of the certificate that you use to help secure inbound connections to Exchange 2007.

Where to Get Your Certificate

As previously mentioned, for external client access, I recommend purchasing a certificate from a public third-party CA.

As you evaluate certificate authorities, consider the following criteria:

• Does the CA allow wildcard names in the certificate? If your clients can support wildcard names in the certificate, buying a certificate from a CA that supports wildcard names is the simplest method to deploy secured clients.
• Does the CA support the SAN extension? It may make sense to use a certificate that supports multiple names in the SAN if the following conditions are true:
  • You must support clients that do not support wildcard names in the certificate.
  • You have more than a single host path that clients must connect to.

Microsoft is partnering with public CAs to provide a Unified Communications certificate. For an up-to-date list of CAs that support Unified Communications certificates, see Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.

• Is the CA providing a high level of authenticity-checking? Some CAs are very inexpensive. Other CAs cost hundreds of dollars a year for a certificate. Because you rely on the integrity of this certificate to authenticate inbound traffic to your organization, I recommend that you not select a public CA by cost alone. Carefully evaluate and compare the services that are provided by each CA and the reputation of each CA before you decide.

Configuring Access to the Certificate Revocation List

When a specific service, such as the Microsoft Exchange Transport service in the SMTP/TLS scenario or IIS in the HTTPS scenario, retrieves a certificate, the service validates the certificate chain and validates the certificate. Validation of the certificate is a process in which many attributes of the certificate are confirmed. Most of these attributes can be confirmed on the local computer by the application that requests the certificate. For example, the intended use of the certificate, the expiration dates on the certificate, and similar attributes are verifiable outside the context of a PKI. However, verification that the certificate has not been revoked must be validated with the CA that issued the certificate. Therefore, most CAs make a certificate revocation list (CRL) available to the public to validate the revocation status.

To successfully authenticate with certificates, CRLs for CAs that you use must be available to the services that are authenticating the client. If the revocation check fails, the authenticating service will fail.

Your authenticating servers must be able to access CRLs for external CAs.

All public CAs have publicly available CRLs that your organization’s servers can contact. In some cases, CRLs for private, internal PKIs are available only with Lightweight Directory Access Protocol (LDAP). In most cases, with public CAs, CRLs are published by using HTTP. Make sure that the appropriate outbound ports and proxies are configured to let your servers and clients to contact the CRL. You can determine which protocol a given CRL distribution point accepts by opening a certificate in MMC and viewing the CRL Distribution Points field.

In some cases, you may have to make the CRL for the CA that issues your certificates publicly available. For example, if you are deploying Domain Security, you must understand that even when an Edge Transport server retrieves a certificate from your own organization, it validates the certificate chain to validate the certificate. Therefore, the CRL for your CA must be available to your own Edge Transport servers. In addition, all partners that you exchange domain-secured e-mail with must be able to access the CRL for the CA that issues your certificates.

Configuring Proxy Settings for WinHTTP

Exchange 2007 servers rely on the underlying Windows HTTP Services (WinHTTP) to manage all HTTP and HTTPS traffic. For example, both Hub Transport servers and Edge Transport servers may use HTTP to access updates for Exchange 2007 Standard Anti-spam Filter Updates and the Microsoft Forefront Security for Exchange Server anti-spam update service. All Exchange server roles will use WinHTTP to enable CRL validation.

Exchange Server Roles and Certificate Requirements

The following Exchange 2007 server roles have the following certificate requirements.

Client Access Server Protocols

In this CAS protocol figure above, note the use of HTTPS from the CAS servers supporting the client services such as the Availability and AutoDiscover. Also, OWA is using HTTPS, and POP and IMAP may be using SSL as well to encrypt the channel. All of these protocols are using certificates on the CAS servers to secure communication. What is not pictured here are ISA servers. If they are used, the outside clients will connect first to the ISA server using HTTPS. The ISA server will be configured to complete the secure communication channel between the client and itself, and then to create a new SSL channel from itself on to the CAS server. This SSL bridging allows the client to connect to the CAS server in a very secure way using web publishing rules on the ISA server.

The certificates you’ll need to place on the ISA server will have to come from exported certificates from the CAS servers. These exported certs from the CAS server must have the private key material; that is the exported certs will be in the .pfx file format. This file export format has the public and private key material from the CAS server. This .pfx cert file will be imported into the Personal certificate store on the ISA server. Then, when you make the web listeners, you will match the certificates to the appropriate web listener. The web listeners are components of the web publishing rule. More on this topic in the next blog article in this series.

Hub Transport Server Protocols

Note in this Hub figure above, the use of TLS between HUB servers and the Edge server role. SMTP and Kerberos both are using TLS in which certificates are used to encrypt. The authentication is not happening via the certificates but rather through Kerberos.

Also, if SMTP is to be secured from the outside, then MTLS providing both security and authentication would have to be configured between SMTP servers.

Edge Transport Server Protocols

Here, depicting the Edge Transport roles, certificates are used to provide the SMTP via TLA also shown in the previous figure above.

Mailbox Server Protocols

Note here the absence of certificates on the Mailbox servers – mailbox servers do not get automatically-created self-signed certs nor do you have to manually place them. Mailbox servers communicate using encrypted RPC.

Unified Messaging Protocols

The last figure here depicts the UM servers using TCP to communicate SIP, but because SIP is very vulnerable to sniffing, TLS is necessary to encrypt the channels between the UM server and the IP-PBX devices and VoIP Gateways. The UM servers communicate to the Hub and Mailbox servers using encrypted RPC.

This concludes this third in a series article on Exchange 2007, ISA and certificate requirements. The next article will be part 4 and will cover making certificate requests.