Understanding TLS Certificates

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

In cryptographic terms, the certificate and related private keys that are generated by the New-ExchangeCertificate cmdlet are TLS keys. The New-ExchangeCertificate cmdlet lets you specify metadata about the certificate so that different services can use the same certificate and private key. Before you create certificates or certificate requests for Exchange services that use TLS, you should understand the metadata that are used by the certificates for SSL and TLS services. This metadata is referred to as "fields" in the resulting certificate.

To view the fields of computer certificates on a specific computer, you can use the Get-ExchangeCertificate cmdlet in the Exchange Management Shell. Alternatively, you can use the Certificate Manager snap-in in the Microsoft Management Console (MMC).

Looking for management tasks related to TLS certificates? See Certificates.

Contents

Fields Used by Certificates for TLS Services

Certificate Selection

Creating TLS Certificates

References

Fields Used by Certificates for TLS Services

If you're using the New-ExchangeCertificate cmdlet to generate a certificate request from a third-party or other public key infrastructure (PKI) certification authority (CA), make sure that you validate which certificate fields and certificate format are required by the CA.

This section explains the most important certificate fields and provides some best practices for generating certificates and certificate requests.

Subject Name

The Subject Name of a TLS certificate is the field that is used by DNS-aware services. The Subject Name field binds a certificate to a particular server or domain name.

A subject name is an X.500 distinguished name that consists of one or more relative distinguished names, also known as RDN. The following table lists the frequently used relative distinguished names for identifying organizations or server entities.

The Country/Region codes are the ISO 3166-1 codes. For more information, see English country names and code elements.

Domain Component and Country/Region are by convention mutually exclusive. It's a best practice to reference the name by Country/Region or reference the name by Domain Name System (DNS) name. Also, be aware that the maximum size of the Domain Component (255 characters) is the total of all Domain Component values.

Specifying Relative Distinguished Names

When creating certificate requests using the New-ExchangeCertificate cmdlet, subject names are represented as a single parameter that consists of a series of comma-separated names. Each name is identified by the abbreviation for the relative distinguished name. For example, the following subject name represents Country/Region = US, Organization = Contoso Corp, and Common Name = mail1.contoso.com:

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

Other examples of subject names that can represent the same server include the following examples:

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

If you have a registered DNS name that you use to send SMTP mail, it's a best practice to use the domain component convention and the DNS name for the certificate name, such as DC=contoso, DC=com, CN=mail1.contoso.com.

However, when you generate a certificate request for a CA provider, you must understand the Subject Name field requirements of the CA and your unique PKI needs. In some cases, you may have to use the Country/Region code ("C"). If that's the case, you must register your relative distinguished name with an X.500 registration authority.

International Subject Names

For subject names that contain non-ASCII characters, you can enter the SubjectName parameter as a distinguished name enclosed in quotation marks, as follows:

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Subject Names and Domain Names

By convention, a common name can contain a fully qualified domain name (FQDN). Although this practice is widespread, be aware of the following two issues with this approach.

First, the maximum size of the Common Name field is 64 characters. This is fewer characters than the maximum size of a FQDN. Therefore, for FQDNs that are more than 64 characters, you must put the domain name in the Subject Alternative Name. The DomainName parameter is the parameter that maps to the Subject Alternative Name on the resulting certificate.

Second, the FQDN is restricted to a subset of the ASCII character set. However, the common name (CN) supports Unicode. Therefore, you can create a valid certificate with a CN that seems like a DNS name but is an invalid DNS name. Software that is looking for a FQDN in a certificate CN will not return the correct result if the CN contains non-ASCII characters. For example, if you create a certificate with a Subject Name where CN=mail.mïcrosoft.com, the name would be ignored as a FQDN because the name contains a Unicode character (the ï character with the diacritic (x00ef)). To the eye, the Unicode CN can be easily be mistaken for a FQDN because of the small difference between the ï character with the diacritic (x00ef) and the ASCII i (x0069). The Exchange certificate task doesn't require or enforce that the subject CN be a valid FQDN. By default, this means that the cmdlet includes the FQDN of the server as the default CN.

Certificate Domain Names

For TLS, certificates must contain DNS names because the TLS relies on DNS resolution. Clients verify the DNS name of the server to which they are connecting with the DNS name that they expect to be connecting to. This is true for Web browsers that connect to a Web site over HTTPS and for SMTP servers that transmit e-mail over the Internet or intranet.

A single server may support multiple DNS names for the following reasons:

• A SMTP server supports multiple accepted domains

• A client can access an e-mail server by the server name, by the domain name, by a FQDN local name, or by a load-balanced name.

When a TLS connection is established, if the client finds the name that it is looking for, the client ignores the other names in the certificate. Multiple domain and server names can be added to the Subject Alternative Name field of a TLS certificate. You can create a certificate that contains multiple Subject Alternative Names by using the DomainName parameter of the New-ExchangeCertificate cmdlet. The DomainName parameter is multivalued so that it can accept multiple names.

X.509 certificates can contain zero, one, or more DNS names in the Subject Alternative Name (SubjectAltName) certificate extension. DNS names in the SubjectAltName extension exactly match the restrictions of a DNS name. They must not exceed 255 characters and must consist of A-Z, a-z, 0-9 and a dash (-).

Name Matching Logic for the Domain Security Feature

The certificate name matching logic for the Domain Security feature checks whether a domain name in the received certificate matches the domain name when it sends mail to that domain. For example, consider the FQDN of the recipient domain woodgrovebank.com. The certificate name matching logic searches through all DNS names in the certificates, and as long as one DNS name matches, the certificate is verified as a match for the specified domain.

In this example, the certificate name matching logic accepts a certificate with an exact domain match, such as woodgrovebank.com. It also supports using wildcard character domain names in certificates so that a certificate with a DNS name of *.woodgrovebank.com is accepted as a match. For more information about wildcard character domain names, see "Wildcard Character Domain Names" later in this topic.

The certificate name matching logic also searches DNS one node deep. Therefore, mail1.woodgrovebank.com is also accepted as a match for woodgrovebank.com. However, DNS names more than two nodes deep aren't accepted. Therefore, mail1.us.woodgrovebank.com, for example, would not be accepted as a match for woodgrovebank.com.

Best Practices for Domain Names for Internet SMTP

When you create a certificate or a certificate request for an Edge Transport server performing SMTP TLS over the Internet, the set of domain names that you should include in the request are as follows:

• The fully qualified Internet domain name of the server   This may be different from the internal FQDN that is used between Edge Transport servers and Hub Transport servers and should match the A record that is published on the Internet (public) DNS server. This name should be entered as a CN in the SubjectName parameter of the New-ExchangeCertificate cmdlet.

• All the accepted domain names of the organization   Use the IncludeAcceptedDomains parameter of the New-ExchangeCertificate cmdlet to populate the Subject Alternative Name for the resulting certificate.

• The FQDN for the connector if it isn't covered by either of the previous items   Use the DomainName parameter of the New-ExchangeCertificate cmdlet to populate the Subject Alternative Name for the resulting certificate.

Wildcard Character Domain Names

Wildcard character domain names are a special type of domain name that represents multiple sub-domains. Wildcard character domain names can simplify certificates because a single wildcard domain name represents all the sub-domains for that domain. They are represented by an asterisk character ( * ) at the DNS node. For example, *.contoso.com represents contoso.com and all the sub-domains for contoso.com. When you use a wildcard character to create a certificate or a certificate request for all accepted domains, you can simplify the request significantly.

Certificate Selection

Exchange follows different certificate selection processes depending on the type of SMTP connection.

When Hub Transport servers are communicating with each other or with the Edge Transport servers in your organization, anonymous TLS certificates are used. For more information, see Selection of Inbound Anonymous TLS Certificates and Selection of Outbound Anonymous TLS Certificates.

When an SMTP host or client connects to the Edge or Hub Transport servers, then the STARTTLS certificate selection process is used. For more information, see Selection of Inbound STARTTLS Certificates.

Creating TLS Certificates

Exchange 2010 creates a self-signed certificate during installation that uses all the server and domain names that are known to Exchange at the time of installation. You can clone this certificate to use it on additional servers. You can also replace this certificate with certificates that are issued by a third-party CA. The following topics provide step-by-step instructions for each task.

• Generate Request for Third-Party Certificate Services

• Install Certificates Issued for Certificate Requests

• Clone an Existing Certificate

References

For more information about cryptography and certificate technologies and concepts, see the following publications:

• Windows Server 2008 PKI and Certificate Security

• Housley, Russ and Tim Polk. Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure. New York: John Wiley & Son, Inc., 2001.

• Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd Edition. New York: John Wiley & Son, Inc., 1996.

 © 2010 Microsoft Corporation. All rights reserved.