As mentioned earlier, many components in Exchange 2007 use certificates. Generally, all internal Exchange data paths that are secured by certificates do not require a certificate issued by a public CA.

All internal SMTP and UM traffic is secured by self-signed certificates that are installed when you run Exchange 2007 Server Setup. Although you should renew these certificates yearly by using the New-ExchangeCertificate cmdlet, you do not have to have a certificate issued by a public CA to run the default internal Exchange messaging components.

Note:
Self-signed certificates that are created by Exchange expire in one year. 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.

Exchange 2007 includes a set of cmdlets to create, request, and manage TLS certificates. For more information about these cmdlets, see Certificate Cmdlets later in this topic. By default, these certificates are self-signed. As explained earlier in this topic, a self-signed certificate is a certificate that is signed by its own creator. In Exchange 2007, the self-signed certificate is created by the computer that is running Microsoft Exchange by using the underlying Windows Certificate API (CAPI). Because the certificates are self-signed, the resulting certificates are generally less trustworthy than certificates that are generated by a CA. Therefore, we 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.
  
  

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. We 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.

Use the New-ExchangeCertificate cmdlet to generate a certificate request according to the specifications of the third-party public CA that will issue your certificate

For more information, see the following topics:

• New-ExchangeCertificate
  
  
• Creating a Certificate or Certificate Request for TLS
  
  
• Exchange 2007 lessons learned - generating a certificate with a 3rd party CA
  
  

  Note:
  The content of Wikis and blogs and their URLs are subject to change without notice.

The rest of this section provides information about how to determine the type of public certificate that you must purchase and whether you must purchase multiple certificates to help secure the clients that your organization uses to access Exchange 2007.

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?
  
  

The following sections examine these factors more closely.

Client Support of Wildcard Names in Certificates

Wildcard names may be used in the Subject or SAN extensions of X.509 certificates. For more information about wildcard names, see "CertificateDomains" in Understanding Certificate Attributes and How Exchange 2007 Uses Them later in this topic.

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
  
  

  Note:
  When wildcard certificates are deployed across Exchange servers that are running the Client Access role, Autodiscover settings require some configuring to allow Outlook 2007 clients to connect successfully. To learn more about this issue and to resolve it, see Wildcard Certificate Causes Client Connectivity Issues for Outlook Anywhere.

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

Important:
Clients running Windows Mobile 5.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.
   
   

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.

For more information, see Understanding Namespace Planning For Exchange Server 2007.

Where to Get Your Certificate

As previously mentioned, for external client access, we 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, we 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.
  
  

Return to top

As explained earlier, certificate fields are attributes within the signed data of the X.509 certificate itself. This section explains the certificate fields that are used by Microsoft Exchange services and displayed in the output of the Get-ExchangeCertificate cmdlet.

Some of these fields are also parameters that you can set when you create a new certificate or a certificate request with the New-ExchangeCertificate cmdlet. For more information about the New-ExchangeCertificate cmdlet, see New-ExchangeCertificate.

Each certificate field in this section is listed according to the output of the Get-ExchangeCertificate cmdlet. Each Exchange certificate field name in this section maps to an X.509 certificate extension name.

Issuer

Subject

This field identifies the subject of the certificate. Subject is an X.500 string that usually represents a single name that is used to access the service that uses the certificate. When a certificate is created by the New-ExchangeCertificate cmdlet, if the subject is not explicitly provided, Subject will be the first value that is listed on the DomainName parameter when you run the New-ExchangeCertificate cmdlet. The following X.500 fields may be present:

• C = Country
  
  
• ST = State
  
  
• L = Location
  
  
• O = Organization
  
  
• OU = Organizational Unit
  
  
• CN = Common Name
  
  

Some of these fields are required when generating certificate requests for third-party CAs. For an in-depth explanation of the Subject field, see Creating a Certificate or Certificate Request for TLS.

If you are running Microsoft Internet Security and Acceleration (ISA) Server 2006 in front of Exchange for bridging, make sure that you read the blog post, Certificates with Multiple SAN Entries May Break ISA Server Web Publishing, for more information about subject names and ISA Server behavior.

Note:
The content of Wikis and blogs and their URLs are subject to change without notice.

When Exchange generates a self-signed certificate without any user arguments, it creates a certificate that contains a subject name of CN=hostname.

The X.509 certificate extension name is also Subject.

You set the Subject field by specifying the SubjectName parameter in the New-ExchangeCertificate cmdlet.

CertificateDomains

The CertificateDomains field identifies all DNS domain names associated with a certificate. DNS domain names can be in either the common name (cn=) attribute of the Subject or in the SAN extension of a certificate. The output of Get-ExchangeCertificate cmdlet displays the union of the domain in the Subject field and any domains found in the SAN.

The values found in the CertificateDomains field may include the host name or FQDN that are used to access the server. To use a certificate, the FQDN that a client uses to connect to the server must appear on the CertificateDomains field for the certificate.

For example, if a client is connecting to a server by using POP3 with mail.fourthcofee.com as the server name, the certificate associated with the POP3 settings may contain mail.fourthcofee.com on its CertificateDomains field.

You might also find certificates with wildcard names, such as *.fourthcofee.com. This is an acceptable domain. However, you should be aware that some legacy clients and mobile devices do not support wildcard names on a certificate and therefore may not support using wildcard domains.

Note:
The SAN field is not exposed through Exchange directly. You can view it only in Certificate Manager in MMC or through the Internet Information Services (IIS) Manager. Certificates bound to a Web site, such as those used by IIS for Outlook Web Access, Exchange ActiveSync, or Autodiscover, are also viewable in IIS Manager.

For an in-depth explanation of how to use SANs and wildcard names in certificates, see Creating a Certificate or Certificate Request for TLS. Also, the Exchange Team Blog, Exchange 2007 lessons learned - generating a certificate with a 3rd party CA, contains practical advice on how to create a certificate request with multiple SANs.

Note:
The content of Wikis and blogs and their URLs are subject to change without notice.

The X.509 certificate extension name is Subject Alternative Name but, as noted earlier, the output of Get-ExchangeCertificate cmdlet also adds the value that is contained in the Subject certificate extension to the list of names in the CertificateDomains field.

You set the CertificateDomains field by specifying the DomainName and Subject parameters of the New-ExchangeCertificate cmdlet.

NotBefore and NotAfter

CertificateRequest

As explained earlier, certificate properties are attributes which are metadata of the certificate or private key. Some properties are intrinsic to the certificate or private key such as the thumbprint of the certificates but many properties can be altered without the certificate being re-signed.

Except for the Thumbprint property, no Exchange certificate properties correspond to an X.509 certificate extension.

This section explains the certificate properties.

IsSelfSigned

RootCAType

Services

Status

HasPrivateKey

Thumbprint

Windows, Windows Mobile, and various third-party operating systems include a set of built-in third-party public root CAs. If you trust the certificates issued by these third-party public root CAs, you can verify certificates issued by these CAs.

Trust is automatic if the following conditions are true:

• Your organization uses the default Windows installation,
  
  
• The client software and mobile devices used in your organization also trust the built-in third-party public root CAs,
  
  

In this case, additional trust configuration is not required.

Private Trusted Root Certification Authorities

A private trusted root CA is a root CA that has been deployed by a private or internal PKI. For example, when your organization has deployed an internal PKI with its own root certificate, you must make additional trust configurations.

Generally, it is not a best-practice to use certificates issued by a private PKI for client applications that support external connections into your organization.

When private root CAs are used, you must update the Windows Trusted Root certificate store on all devices, clients, and Windows operating systems where certificate authentication is required.

You can configure trust in two ways: direct root trust and cross-certification.

Direct Root Trust

If you want to trust a certificate that has been issued by a private root CA, you can manually add that root certificate to the Trusted Root certificate store on a computer that is running Windows. In some cases, you can add a root certificate to the trusted root store of mobile clients also. For more information about how to manually add certificates to the local certificate store on a computer that is running Windows, see the Help file for Certificate Manager in MMC. For more information about how to install certificates on Windows Mobile devices, see How to install root certificates on a Windows Mobile-based device.

Important:

You probably won't be able to install certificates on all computers and devices that users will use to access Exchange. For example, some users may try to access Outlook Web Access from a kiosk or from a friend's computer. In this scenario, users receive a warning but are not prevented from accessing their mail. Because this behavior, in effect, trains users to ignore certificate warnings, it is not a best practice. Therefore, using certificates issued from trusted third-party CAs is a best practice.

Cross-Certification

Cross-certification occurs when one CA signs a certificate that is generated by another CA. Cross-certification is used to build trust from one PKI with another PKI. If you have your own PKI, instead of using direct manual trust for a root CA of another private PKI, you can create a cross-certificate for the other CA under your root CA. In this case, trust is established because the cross-certificate ultimately chains back to your trusted root CA.

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

To verify your PKI and proxy configuration for a specific Exchange server, use Certutil.exe to verify the certificate chain for the server certificate. Certutil.exe is a command-line tool that is installed as part of Certificate Services in Windows Server operating systems. For more information, see How to Test PKI and Proxy Configuration.

Return to top

In earlier versions of Exchange Server, all certificate management was done through IIS and Certificate Manager in MMC. In Exchange 2007, you perform most certificate management tasks that relate to Exchange by using the following ExchangeCertificate cmdlets with the Exchange Management Shell:

• New-ExchangeCertificate   This cmdlet generates self-signed certificates and certificate requests for certification authorities.
  
  
• Import-ExchangeCertificate   This cmdlet imports certificates that have been previously exported and imports certificate files generated by CAs.
  
  
• Export-ExchangeCertificate   The cmdlet exports certificates for backup or for use on multiple servers.
  
  
• Enable-ExchangeCertificate   This cmdlet enables specific services on a certificate.
  
  
• Get-ExchangeCertificate   This cmdlet displays the attributes of a certificate.
  
  
• Remove-ExchangeCertificate   This cmdlet removes certificates from Exchange Server and the local certificate store.
  
  

For more information about how to create certificate requests for certification authorities, see Creating a Certificate or Certificate Request for TLS.

The following sections provide short examples to illustrate how you can use the ExchangeCertificate cmdlets to perform common certificate tasks. For more information and examples, see the ExchangeCertificate cmdlet Help under Global Cmdlets.

Generating Self-Signed Certificates

To generate a self-signed certificate for use by the SMTP service for a server that has the host name of Server1 and a domain of fourthcoffee.com, run the following command:

	Copy Code
New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Cloning Self-Signed Certificates

If an existing self-signed certificate has to be renewed, you can clone it by running the following command:

	Copy Code
Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

The thumbprint placeholder is the thumbprint of the certificate to be renewed. The services for the new certificate can also be specified in the command as follows:

	Copy Code
Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

You can then enable this certificate by running the following command:

	Copy Code
Enable-ExchangeCertificate <thumbprint>

Creating Certificate Requests and Installing Trusted Certificates

Installing a public, third-party certificate is a more complex process. You must generate a certificate request, import the issued certificate and all the necessary CA certificates, and then enable the issued certificate for its intended use or uses.

This section provides an example of how to enable the POP3 service for certificate use. In this example, clients connect to the POP3 service by connecting to the FQDN, popserver.fourthcoffee.com.

Certificate Request

Because the resulting certificate comes from a public, third-party CA, you must first generate a certificate request by running the following command:

	Copy Code
New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

If the certificate request is correctly generated, a certificate request file (.cer or .der) will be created in the root of the system drive and the Exchange Management Shell will display a Thumbprint for the request.

Note:
Certificates returned by providers will support different extensions for the certificate request file, such as .der or .cer. These extensions represent the encoding method that is used on the certificate file. By default, the New-ExchangeCertificate request will create a Base64-encoded file (.cer). Use the BinaryEncoded parameter switch to create a .der file.

In the previous command, the PrivateKeyExportable parameter is set to $True so that this certificate can be exported together with the private key for use on multiple Exchange servers that may have to be accessed by using the same FQDN. For example, multiple Client Access servers may be load-balanced to support POP3 connections.

Note:
The PrivateKeyExportable parameter is optional. You should specify it only when you generate certificate requests for trusted CAs. By setting the PrivateKeyExportable parameter to $True, you can move and archive the certificate and the associated keys. You do not have to do this with self-signed certificates.

The previous command also specifies the Subjectname parameter as an X.500 name. Most third-party CAs require that you specify a valid X.500 name for the Subject name of the certificate. At a minimum, most CAs require that the organization listed in the organizationName (o=) field owns the domain name that appears in commonName (cn=) of the Web server.

After the request is completed, the request file can be submitted to a certificate vendor to obtain a certificate.

Note:

The Get-ExchangeCertificate cmdlet returns certificates and also certificates that are still pending requests. To differentiate between the two, certificate requests contain a CertificateRequest attribute that displays the output that is stored in the certificate request file. This output may be useful if you accidentally delete the certificate request file or generate the request without the parameter. The CertificateRequest data is base64-encoded and can be copied into a file and sent to your CA for a certificate request.

Importing a Certificate

After a certificate is returned from a CA, you must import it to the Exchange server. To correctly import a certificate for which a request was generated by using the New-ExchangeCertificate cmdlet, run the following command:

	Copy Code
Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

If the certificate is successfully imported, this command will return a certificate thumbprint that you can use to enable specific services.

Important:
You must import the certificate onto the same computer where the certificate request was generated. Also, do not use Certificate Manager in MMC to import Exchange certificates.

Enabling a Certificate

Enabling a certificate lets you specify which services can use a specific certificate. The following command enables the issued certificate for the POP3 service:

	Copy Code
Enable-ExchangeCertificate <thumprint> -Services:"POP"

You can import and enable a certificate at the same time by running the following command:

	Copy Code
Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Validating Certificate Installation

To confirm that all required steps have been completed and the certificate is installed and operational, run the following command:

	Copy Code
Get- ExchangeCertificate <thumbprint> | fl *

Note:
If you are running Exchange 2007 SP1 or later versions, do not include the asterisk (*) on the command argument.

The output of this command returns data similar to the following:

Copy Code

AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule} CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com} HasPrivateKey : True IsSelfSigned : False Issuer : CN=3rdPartyCAExample.com NotAfter : 8/7/2008 10:04:02 AM NotBefore : 8/7/2007 10:04:02 AM PublicKeySize : 2048 RootCAType : ThirdParty SerialNumber : 83FAE8B2398F2A9E44485CBA85D548DF Services : POP Status : Valid Subject : C=us,o=contoso corp, CN=fourthcoffee.com Thumbprint : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Inspect the output of this command to validate that the following information is true:

• The domain names that you expect to be present are listed in the CertificateDomains field.
  
  
• The HasPrivateKey property is set to True.
  
  
• The RootCAType property is set correctly. For more information about the RootCAType property, see Certificate Properties earlier in this document.
  
  
• The required services are enabled for the certificate.
  
  
• The Status is set to Valid.
  
  

Services, such as POP, IMAP, IIS, and SMTP, can be enabled on a certificate. Services are not fields in the certificate itself. They are metadata properties of the certificates. Therefore, you can change them without invalidating the certificate.

When services are enabled, configuration changes occur on other components, such as in the IIS Metabase, the file system, or on the IMAP4 and POP3 settings. This section describes the configuration changes that occur when you enable a given service by running the Enable-ExchangeCertificate cmdlet.

POP and IMAP

When POP and IMAP are added as additional services to a certificate, the x509CertificateName attribute on the POPSettings object or IMAPSettings object is updated to include the domain in the subject of the certificate.

For example, to verify that the POPSettings object has been updated, run the following command

	Copy Code
Get-POPSettings | fl *

Note:
If you are running Exchange 2007 SP1 or later versions, do not include the asterisk (*) on the command argument.

IIS

SMTP

Microsoft Exchange Unified Messaging Service

STARTTLS is the SMTP verb that initiates a secure TLS session. STARTTLS is only advertised by Exchange if a valid certificate exists on the computer that is running Exchange.

To advertise or use STARTTLS, Exchange selects a certificate based on the FQDN and a matching value in the CertificateDomains field of a certificate. The FQDN is based on the following information:

• Outbound STARTTLS   The certificate is selected based on the value of FQDN on a Send connector.
  
  
• Inbound STARTTLS   The certificate is selected is based on the value of FQDN on a Receive connector.
  
  

  Note:
  For outbound STARTTLS and inbound STARTTLS, if the FQDN of the connector is not specified, the physical FQDN of the Exchange server is used for the match.

After the FQDN is determined, Exchange searches Personal certificate store on the host computer for all valid certificates. A certificate is valid for TLS use if it meets all the following requirements:

• The Enhanced Key Usage field contains either the Server Authentication object identifier (also known as OID) or is null.
  
  
• The PKI certificate extension lists an RSA key with a minimum of 1024 bits.
  
  
• The certificate validates the certificate chain up to a trusted root, or the certificate is self-signed.
  
  
• The certificate and certificate chain passes the revocation check.
  
  
• The private key is present and available.
  
  
• The private key is not stored in a removable device.
  
  
• The private key is not protected with a password.
  
  

If more than one valid certificate is found, Exchange selects a certificate based on the following criteria:

• The value in the NotBefore field   Exchange selects the newest valid certificate.
  
  
• Certificates issued by a trusted CA vs. self-signed certificates   Exchange selects certificates issued by a trusted CA over self-signed certificates.
  
  

In most cases, Exchange selects a certificate issued by a trusted CA over a self-signed certificate regardless of the age of the certificate. If a valid certificate is not found, STARTTLS is not advertised.

X-AnonymousTLS is used to help secure communication between two Hub Transport servers and between Hub Transport servers and Edge Transport servers. In Exchange 2007 SP1, the certificate selection process has been simplified so that if no certificate is found, a temporary encryption key is generated for the session.

Exchange searches for an internal transport certificate. If a valid internal transport certificate cannot be found, Exchange searches for a valid CA certificate.

Therefore, for Hub-to-Hub communication where the Kerberos protocol is used for authentication, the absence of a valid internal transport certificate does not fail the SMTP session. The SMTP session is encrypted by using the temporary encryption key. In this case, an event is logged and you must create a new internal transport certificate by running the New-ExchangeCertificate cmdlet without arguments on the computer that is generating the event.

For Hub-to-Edge communication, where the Edge Transport server is subscribed to the organization, if a valid internal transport certificate is not found, the session fails and an error is logged. In this case, you must run the New-ExchangeCertificate cmdlet without arguments on the computer that generates the event and then run the Microsoft Exchange EdgeSync service again.

As with the certificate selection process for SMTP STARTTLS, in the process for POP3 and IMAP4, Exchange must select a FQDN and find a certificate based on a matching value in the CertificateDomains field. The FQDN is chosen on the basis of the X509CertificateName attribute in the POP3 or IMAP4 service settings. You can view the X509CertificateName attribute by running the Get-POPSettings cmdlet or the Get-IMAPSettings cmdlet. For more information, see Get-POPSettings and Get-IMAPSettings.

The selection process for POP3 and IMAP4 in Exchange 2007 SP1 is the same as the process for SMTP STARTTLS.

Note:

In Exchange 2007 RTM, there are two major exceptions in the certificate selection processes for POP3 and IMAP4. Certificates issued by a trusted CA are not preferred over self-signed certificates. Instead, Exchange 2007 selects the newest certificate. Also, in Exchange 2007 RTM, POP3 and IMAP4 do not support wildcard domains on certificates. This means that if the X509CertificateName attribute is set to mail.fourthcoffee.com for either the POP3 settings or IMAP4 settings, Exchange 2007 will not support a certificate that only contains *.fourthcoffee.com as a certificate domain.

If the Microsoft Exchange Unified Messaging service is started in Secured mode, it will query the local Personal certificate store to find a valid certificate to use for TLS to enable encryption. The Microsoft Exchange Unified Messaging service will first look for a valid certificate that has been issued by a private PKI or a public CA. If an appropriate certificate is not found, it will look for a self-signed certificate. If no PKI, public, or self-signed certificate is found, the Microsoft Exchange Unified Messaging service creates a self-signed certificate to use to start in Secure mode. If the UM server is starting in Unsecured mode, no certificate is needed.

All the details of the certificate that is used to start in Secured mode are logged whenever a certificate is used or if the certificate has changed. Some details that are logged include the following:

• Issuer Name
  
  
• Serial Number
  
  
• Thumbprint
  
  

The thumbprint is the Secure Hash Algorithm (SHA1) hash. It can be used to uniquely identify the certificate that is used. You can export the certificate that is used by the Microsoft Exchange Unified Messaging service to start in Secured mode from the local certificate store and import this certificate onto the Unified Messaging IP gateways and IP PBXs on your network into the trusted certificate store.

After an appropriate certificate has been found and used, the Microsoft Exchange Unified Messaging service logs an event one month before the certificate that is being used expires. If you do not make any changes to the certificate during this time, the Microsoft Exchange Unified Messaging service logs an event each day until the certificate expires and each day after the certificate has expired.

When the Unified Messaging server looks for a certificate to use for mutual TLS to establish an encrypted channel, it looks in the trusted root certificate store. If there are multiple certificates that are valid and from different issuers, the Unified Messaging server selects the valid certificate that has the longest time remaining before expiration. If multiple certificates exist, the Unified Messaging server selects the certificates based on the issuer and the date that the certificate will expire. The Unified Messaging server looks for a valid certificate in the following order of preference:

1. PKI or public certificate with the longest expiration period.
   
   
2. PKI or commercial certificate with the shortest expiration period.
   
   
3. Self-signed certificate with the longest expiration period.
   
   
4. Self-signed certificate with the shortest expiration period.
   
   

Return to top