Sdílet prostřednictvím

Creating a Certificate or Certificate Request for TLS

  • Článek

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

This topic explains how to create X.509 Transport Layer Security (TLS) certificates or a certificate request by using the ExchangeCertificate cmdlets in the Exchange Management Shell.

Important

Before reading this topic, be sure you are familiar with general certificate use in Microsoft Exchange Server 2007. See Certificate Use in Exchange Server 2007.

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 given computer, you can use the Get-ExchangeCertificate cmdlet in the Exchange Management Shell. Alternatively, you can use the Certificate Manager snap-in in Microsoft Management Console (MMC). For more information about how to use the Certificate Manager snap-in, see How to Add Certificate Manager to Microsoft Management Console.

Understanding the Fields Used by Certificates for TLS Services

If you are 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.

Name Abbreviation Type Max Size Frequency Max.\Recommended in certificate\request Order in subject

Country/Region

C

ASCII

2

1\1

1

Domain Component

DC

ASCII

255

Many

1

State or Province

S

Unicode

128

1

2

Locality

L

Unicode

128

1

3

Organization

O

Unicode

64

1\1

4

Organizational Unit

OU

Unicode

64

Many\Many

5

Common Name

CN

Unicode

64

Many\1

6

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

Note

The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

Domain Component and Country/Region are by convention mutually exclusive. It is 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.

Important

Although certificates can have more than one common name fields, some services are implemented on the assumption that there is only one common name. Therefore, multiple common names can cause interoperability issues. We recommend that the certificate or certificate request that you create contains only one common name.

Implementing Relative Distinguished Names

Subject names are represented in the New-ExchangeCertificate cmdlet 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 is 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 is true, 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 and is recommended, you must understand the following two issues.

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 FQDN 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)). With the naked 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 does not 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 is a DNS-based protocol. 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 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 the purposes of 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 are not accepted. Therefore, mail1.us.woodgrovebank.com, for example, would not be accepted as a match for woodgrovebank.com.

For more information about how Exchange selects certificates see SMTP TLS Certificate Selection.

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 IncludeAcceptedDomain parameter of the New-ExchangeCertificate cmdlet to populate the Subject Alternative Name for the resulting certificate.

  • The FQDN for the connector if it is not 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.

Best Practices for Domain Names for a Client Access Server

When you create a certificate or certificate request for a Client Access server, the set of domain names that you should include in the request are as follows:

  • Local or NetBIOS name of the server, for example, owa1

  • All the accepted domain names for the organization, for example, contoso.com

  • The fully qualified domain name for the server, for example, owa1.contoso.com

  • The Autodiscover domain name for the domain, for example, Autodiscover.contoso.com

  • The load-balance identity of the server if you are using one, for example, owa.contoso.com

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.

Cloning an Existing Certificate

Exchange 2007 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. These certificates are valid for 12 months. In some cases, it may make sense to clone these certificates if the Subject and Subject Alternative Names can be used for other computers. Be aware that only the certificate metadata and not the key sets are cloned.

To run the following cmdlets on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

To clone a new certificate from an existing certificate, you must first identify the current certificate for the domain by running the following command:

Get-ExchangeCertificate -DomainName mail1.contoso.com

Where mail1.contoso.com is the server name or the FQDN that you want to make a cloned certificate of.

The first certificate that is listed in the output is the default SMTP TLS certificate for the server.

To clone the certificate, run the following command:

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

Where the value for Thumbprint is from the first certificate that was listed in the output for Get-ExchangeCertificate.

This command extracts the names from the existing certificate that are identified by the thumbprint and uses them in the new self-signed certificate.

Generating Requests for Third-Party Certificate Services

If you are using a CA to generate certificates, you must provide a certificate request according to the CA's requirements.

To generate a certificate request, you can use the New-ExchangeCertificate cmdlet. To generate a certificate request, use the GenerateRequest parameter together with the Path parameter to define where the request file will be created. The resulting file will be a PKCS #10 request (.req) file. PKCS #10 is the Certification Request Syntax Standard that is specified by RFC 2314 (https://www.ietf.org/rfc/rfc2314.txt).

Note

The third-party Web site information in this topic is provided to help you find the technical information you need. The URLs are subject to change without notice.

The following examples show some typical certificate requests.

The first example generates a certificate request for Contoso's server, mail1. The CN of the Subject Name contains the FQDN of the server and the Subject Alternative Name contains of all the accepted domains for Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

The second example generates a certificate request for Contoso's server, mail1. Contoso has a Send connector on each Edge Transport server that has a FQDN of mail.contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

The third example creates a certificate request from an existing Contoso.com certificate.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

The last example shows how to create a certificate request with a wildcard character for all Contoso.com sub-domains.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

For more examples, see the Microsoft Exchange Team Blog entry, Lessons Learned: Generating a Certificate with a 3rd Party CA.

Note

The content of each blog and its URL are subject to change without notice. The content within each blog is provided "AS IS" with no warranties, and confers no rights. Use of included script samples or code is subject to the terms specified in the Microsoft Terms of Use.

Installing Certificates Issued from Certificate Requests

After you have sent the certificate request to a CA, the CA issues a certificate or chain of certificates. In both cases, the certificates are delivered as files that you must install with the Import-ExchangeCertificate cmdlet.

Important

Do not use the Certificate Manager snap-in to import the certificates for any service on an Exchange server. Using the Certificate Manager snap-in to import certificates on Exchange servers will fail. Therefore, TLS or other Exchange certificate services will not work.

The following example shows how to import a certificate for SMTP TLS

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

The next example shows how to import a certificate and enable it for a Client Access server that supports Post Office Protocol version 3 (POP3) clients.

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

For More Information

For more information about certification authorities that currently operate Exchange-specific Web sites, see Microsoft Knowledge Base article 929395, Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.

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