Welcome  |  Sign in
Skip Navigation Links
Exchange Server TechCenter
Click to Rate and Give Feedback
TechNet
TechNet Library
Exchange Server
 White Paper: Domain Security in Exc...
White Paper: Domain Security in Exchange 2007

Topic Last Modified: 2007-09-19

John Speare, Senior Technical Writer, Microsoft Exchange Server

February 2007

This white paper explains how to plan for and deploy the Domain Security feature set in Microsoft Exchange Server 2007.

Domain Security refers to the set of functionality in Exchange 2007 and Microsoft Office Outlook 2007 that provides a relatively low-cost alternative to S/MIME or other message-level over-the-Internet security solutions. The purpose of the Domain Security feature set is to provide administrators a way to manage secured message paths between domains over the 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.

Domain Security uses Transport Layer Security (TLS) with mutual authentication to provide session-based authentication and encryption. 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. No authentication occurs between the sender and receiver. 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. In this scenario, where messages are received from external domains over verified connections in an Exchange 2007 environment, Outlook 2007 will display a "Domain Secured" icon.

Important:
It is beyond the scope of this white paper to provide a detailed explanation of cryptography and certificate technologies and concepts. Before you deploy any security solution that uses cryptography and digital certificates, we recommend that you understand the basic concepts of trust, authentication, encryption, and public and private key exchange as they relate to cryptography. For more information, see the references listed at the end of this white paper. Also, you can learn more about how Exchange 2007 uses certificates by reading Certificate Use in Exchange 2007 Server.

Objectives and acknowledgements   Much of the information in this white paper originally appeared as individual Help topics in the Exchange Server 2007 Help. In this white paper, we have consolidated this information to provide an end-to-end, printable guide that you can use to deploy, test, and maintain Domain Security for Exchange 2007.

Note:
To print this white paper, click Printer Friendly Version in your Web browser.

This white paper is intended to walk you through the deployment of Domain Security. Read all of it. Also, as with any software deployment, we recommend that you set up the solution, by using self-signed certificates, in a lab and experiment with the functionality before you deploy it in the real world.

During the development of Exchange 2007, the Microsoft IT department deployed Domain Security with early adopter partners. As a result, configuration and deployment issues were discovered and fixed. Other minor configuration and deployment issues have also been identified and are documented in this white paper.

The following people were instrumental in deploying prerelease versions of Exchange 2007 and testing Domain Security functionality. Their experience and commitment to deploying this feature set resulted in invaluable information, much of which has been translated into the recommendations and best practices documented in this white paper: Victor Duchovni, Chris Henderson, Frank Hsieh, Robbie Roberts, Jonathan Ruckert, Andy Ryan, and Elmar Spreitzer.

The following people reviewed this content for technical accuracy: Chris Ahlers, Trevor Freeman, and Ross Smith IV.

Return to top

Compared to earlier versions of Exchange Server, Exchange 2007 provides additional administrative functionality and other enhancements that improve the overall management of TLS. Before you deploy Domain Security, it may help if you understand other TLS-related features and functionality. Some terms and concepts apply to more than one TLS-related feature. In this section, the brief explanation of each feature is intended to help you understand some of the differences and general terminology related to TLS and the Domain Security feature set.

  • Mutual TLS   As noted earlier, mutual TLS is TLS deployed in a configuration where both the sender and the receiver authenticate one another before they send data.
  • Domain Security   The set of features, such as certificate management, connector functionality, and Microsoft Office Outlook client behavior that enables mutual TLS as a manageable and useful technology.
  • Opportunistic TLS   In earlier versions of Exchange Server, you had to configure TLS manually. In addition, you had to install a valid certificate, suitable for TLS usage, on the Exchange Server. In Exchange 2007, Setup creates a self-signed certificate. By default, TLS is enabled. This allows any sending system to encrypt the inbound SMTP session to Microsoft Exchange. By default, Exchange 2007 also tries TLS for all remote connections.
  • Direct trust   By default, all traffic between Edge Transport servers and Hub Transport servers is authenticated and encrypted. Again, the underlying mechanism for authentication and encryption is mutual TLS. Instead of using X.509 validation, Exchange 2007 uses direct trust to authenticate the certificates. Direct trust means that 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. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority. When you subscribe an Edge Transport server to the Exchange organization, the Edge Subscription publishes the Edge Transport server certificate in Active Directory for the Hub Transport servers to validate. The Microsoft Exchange EdgeSync service updates ADAM with the set of Hub Transport server certificates for the Edge Transport server to validate.

Return to top

Deploying Domain Security does not require much configuration. You only have to perform the following high-level steps:

  • Figure out your certificate plan.
  • Install the certificate on Edge Transport servers.
  • Set the appropriate properties on the Send and Receive connectors.

However, as with all software deployments, you have to pay attention to some details and basic planning tasks that are described in this white paper.

Return to top

The only absolute prerequisite to deploy Domain Security is to have an Internet-facing Exchange 2007 transport server. Specifically, this means that the Exchange 2007 transport server cannot be behind any third-party message hygiene server or any kind of firewall or process that might otherwise modify Simple Mail Transfer Protocol (SMTP negotiation).

Although you can configure a Hub Transport server for Domain Security, we recommend that you run Domain Security functionality on the Edge Transport server. For more information about how to use the Hub Transport server for Domain Security, see "Appendix 2: Enabling Domain Security on Hub Transport Server" at the end of this white paper. Except for that section, the rest of this white paper assumes that you will use the Edge Transport server as the Internet-facing transport server.

An additional prerequisite to using the Edge Transport server is to subscribe all Edge Transport servers to the Exchange organization by using the Edge Subscription process. For more information about how to subscribe an Edge Transport server to the Microsoft Exchange Server organization, see "Subscribing the Edge Transport Server to the Exchange Organization" in Exchange Server 2007 Help.

Some organizations may want to test the functionality of Domain Security with other partner organizations before they widely deploy certificates on all Edge Transport servers. In this scenario, you may want to consider creating a subdomain, such as test.contoso.com, to test Domain Security. If you create a subdomain, you must update the MX resource records for that domain so that partner organizations can locate the test domain.

Return to top

Domain Security relies on mutual TLS for authentication. Successful mutual TLS authentication relies on a trusted, validated X.509 certificate chain for the TLS certificates that are used for Domain Security.

Therefore, before you can successfully deploy Domain Security, you must configure your Edge Transport server and your X.509 PKI to accommodate certificate trusting and certificate validation.

Configuring Root Certification Authorities

To validate a given X.509 certificate, you must trust the root certification authority (CA) that issued the certificate. A root CA is the most trusted CA, which is at the top of a CA. The root CA has a self-signed certificate. When you run an application that relies on certificate authentication, each certificate must have a certificate chain that ends in a certificate in the trusted root container of the local computer. The trusted root container contains certificates from root certification authorities.

To successfully send domain-secured e-mail, you must be able to validate the receiving server's X.509 certificate. Similarly, when someone sends domain-secured e-mail to your organization, the sending server must be able to validate your certificate.

There are two types of trusted root CAs that you can use to implement Domain Security: Built-in third-party root CAs and private root CAs.

Third-Party Root Certification Authorities

Windows includes a set of built-in third-party root CAs. If you trust the certificates issued by these third-party root CAs, this means you can verify certificates issued by these CAs. If your organization and your partner organizations are using the default Windows installation and trust the built-in third-party root CAs, trust is automatic. In this scenario, 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 or the organization that you exchange domain-secured e-mail with has deployed an internal PKI with its own root certificate, you must make additional trust configurations.

When private root CAs are used, you must update the Windows trusted root certificate store on the Edge Transport server for Domain Security to function correctly.

You can configure trust in two ways: direct root trust and cross-certification. You must understand that whenever the transport service picks a certificate, it validates the certificate before it uses it. Therefore, if you are using a private root CA to issue your certificates, you must include the private root CA in the trusted root certificate store on each Edge Transport server that sends or receives domain-secured e-mail.

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 the Edge Transport server computer. For more information about how to manually add certificates to the local certificate store, see the Help file for the Certificate Manager snap-in in Microsoft Management Console (MMC).

Cross-Certification

Cross-certification occurs when one CA signs a certificate that is generated by a different CA. Cross-certification is used to build trust from one PKI with another PKI. In the context of Domain Security, if you have your own PKI, instead of using direct manual trust for a root authority of a partner with an internal PKI, you might create a cross-certificate for the partner CA under your root authority. In this case, trust is established because the cross-certificate ultimately chains back to your trusted root.

You must understand that if you have an internal PKI and are using cross-certification, you must manually update the root certificate store on each Edge Transport server that receives domain-secured e-mail so that each Edge Transport server can validate certificates when they receive e-mail from partners that are trusted through cross-certificates.

For more information about how to manually add certificates to the local certificate store, see the Help file for the Certificate Manager snap-in in MMC.

Return to top

Configuring Access to the Certificate Revocation List

Whenever the transport service retrieves a certificate, it validates the certificate chain. Validation of the certificate chain is a process in which many attributes of the certificates in the certificate chain 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 by checking the revocation status of the certificate. In most cases, checking the revocation status means checking for the presence of the certificates on a certificate revocation list (CRL) issued by the CA. Therefore, most CAs make CRLs available to the public to validate the revocation status.

To successfully use Domain Security, CRLs for CAs that you use or are used by your partners must be available to the Edge Transport servers that send and receive domain-secured e-mail. If the revocation check fails, the receiving Exchange server issues a temporary protocol rejection of the message. A transient revocation failure can occur. For example, the Web server that is used to publish the CRL can fail. Or general network connectivity issues between the Edge Transport server and the CRL distribution point could fail the revocation check. Therefore, transient revocation failures only cause temporary mail delivery delays because the sending server will retry later. However, CRL validation is required for successful domain-secured e-mail transmission.

You must enable the following scenarios:

  • Your Edge Transport servers must be able to access CRLs for external CAs   Each partner that you exchange domain-secured e-mail with must have publicly available CRLs that your organization's Edge Transport server can contact. In some cases, CRLs are only available with Lightweight Directory Access Protocol (LDAP). In most cases, with public CAs, CRLs are published via HTTP. Make sure that the appropriate outbound ports and proxies are configured to let the Edge Transport server 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.
  • You must make the CRL for the CA that issues your certificates publicly available   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.

Return to top

Configuring Proxy Settings for WinHTTP

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

In most organizations, a proxy server is used for HTTP and HTTPS communications with destinations on the Internet. If your organization uses a proxy server and your Exchange Transport servers are not configured to use the proxy server for HTTP and HTTPS, you must configure them so that HTTP-enabled CRL validation works.

The simplest way to configure WinHTTP is to use ProxyCfg.exe, which is included in the %System32% directory on all Windows Server 2003 computers. ProxyCfg.exe is a command-line tool that you can use to set and view WinHTTP configurations.

In most cases, you only have to run the following command to specify the proxy server in your organization and to specify that all local traffic bypasses the proxy server:

proxycfg -p proxy_server "<local>"

This command specifies that both HTTP and HTTPS servers are accessed through a proxy server named "proxy_server", except for host names that do not contain a period specified by the "<local>" argument.

Even if you are not running a proxy server, we recommend that you use ProxyCfg.exe to check whether a previous proxy has been set. You can view the current configuration by running the tool without arguments, as follows:

proxycfg

To configure a direct Internet connection for WinHTTP or to remove an existing proxy configuration, run the following command:

proxycfg -d
Important:
You must restart the Microsoft Exchange Transport service and the Microsoft Exchange Anti-spam Update service after you have made configuration changes to WinHTTP.

For more information about how to ProxyCfg.exe, see ProxyCfg.exe, a Proxy Configuration Tool.

Return to top

Testing PKI and Proxy Configuration

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

Before you can run Certutil to verify the certificate chain for a given certificate, the certificate must first be in file (.cer) format. Therefore, you must first export the certificate, but not the private keys, to the DER (.cer) file format.

The first procedure in this section shows you how to add the Certificate Manager snap-in to MMC. The second procedure explains how to use the Certificate Manager to export a certificate. The third procedure shows how to run the Certutil command to verify the certificate chain.

To perform these procedures, the account you use must be delegated the following:

  • Membership in the local Administrators group

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

To add Certificate Manager to Microsoft Management Console

  1. Click Start, click Run, type mmc, and then click OK.

  2. In the File menu, click Add/Remove Snap-in.

  3. In the Add/Remove Snap-in box, click Add.

  4. In the Available Standalone Snap-ins list, click Certificates, and then click Add.

  5. Click Computer Account, and then click Next.

  6. Click the Local computer (the computer this console is running on) option, and then click Finish.

  7. Click Close, and then click OK.

To export a certificate

  1. Open the Certificate Manager that you created in the first procedure.

  2. Open the Certificates (Local Computer) folder, the Personal folder, and then the Certificates folder.

  3. In the results pane, right-click the certificate that you will use for Domain Security, click All Task, and then select Export. The Certificate Export Wizard will open.

  4. On the Welcome page, click Next.

  5. On the Export Private Key page, select No, do not export the private key, and then click Next.

  6. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.

  7. On the File to Export page, enter the path and file name where you want to save the exported certificate, and then click Next.

  8. On the Finish page, verify the settings and then click Finish.

To verify the certificate chain for a certificate

  • On the Edge Transport server, open a Command Prompt window. Type the following command

    Certutil -verify c:\CertificateName.cer

    Where CertificateName is the Edge Transport server certificate that you exported in the previous procedure.

Return to top

This section explains how to use the Exchange Management Shell to configure mutual TLS for Domain Security, the set of functionality in and Outlook 2007 that provides a relatively low cost alternative to S/MIME and other message-level security solutions.

For the purposes of illustration, this section explains how Exchange administrators at a fictitious company, Contoso, configure their Exchange 2007 environment to exchange domain-secured e-mail with their partner, Woodgrove Bank. In this scenario, Contoso wants to make sure that all e-mail that is sent and received from Woodgrove Bank is protected with mutual TLS. Also, Contoso wants to configure Domain Security functionality so that all mail to and from Woodgrove Bank is rejected if mutual TLS cannot be used.

Contoso has an internal public key infrastructure (PKI) that generates certificates. The PKI's root certificate has been signed by a major third-party CA. Woodgrove Bank uses the same third-party CA to generate their certificates. Therefore, both Contoso and Woodgrove Bank each trust the other's root CAs.

To set up mutual TLS, Exchange administrators at Contoso perform the following procedures:

  1. Generate a certificate request for TLS certificates.
  2. Import certificate to Edge Transport servers.
  3. Configure outbound domain security.
  4. Configure inbound domain security.
  5. Test mail flow.

The configuration of mutual TLS requires the following:

  • Access to internal Exchange 2007 servers by using the Set-TransportConfig cmdlet and by using the New-SendConnector cmdlet if you haven't configured Send connectors.
  • Access to the Edge Transport Server computers where the ExchangeCertificate cmdlets are run.

Generally, configuration changes that are made to Domain Security functionality that don't use the ExchangeCertificate cmdlets should be made within the organization and synchronized to Edge Transport servers by using the Microsoft Exchange EdgeSync service.

When you import and configure TLS certificates by using the ExchangeCertificate cmdlets, you must run the cmdlets on the Edge Transport server that you are configuring. To run the ExchangeCertificate 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 run the Set-TransportConfig cmdlet, the account you use must be delegated the Exchange Organization Administrator role.

To run the New-SendConnector cmdlet, the account you use must be delegated the Exchange Server Administrator role and local Administrators group on that computer.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

The Microsoft Exchange EdgeSync service must be fully deployed for Domain Security.

Generating a Certificate Request for TLS Certificates

As mentioned earlier in this section, Contoso has an internal PKI that is subordinated to a third-party CA. In this scenario, subordination refers to the fact that the CA that is deployed by Contoso in their corporate infrastructure contains a root certificate that has been signed by a public third-party CA. By default, the public third-party CA is one of the trusted root certificates in the Microsoft Windows certificate store. Therefore, any client that includes the same third-party CA in its trusted root store and that connects to Contoso can authenticate to the certificate that is presented by Contoso.

Contoso has two Edge Transport servers that require TLS certificates: mail1.contoso.com and mail2.mail.contoso.com. Therefore, the Contoso e-mail administrator will generate two certificate requests, one certificate request for each server.

The following procedure shows the command that the administrator uses to generate a base64-encoded PKCS#10 certificate request. The Contoso administrator must run this command two times: one time for CN=mail1.contoso.com and one time for CN=mail2.mail.contoso.com.

Note:
The common name (CN) in the Subject name of the resulting certificates is mail1.contoso.com and mail2.mail.contoso.com respectively. The Subject Alternative Name contains "mail.contoso.com," which is the fully qualified domain name (FQDN) of one of the accepted domains that is configured for Contoso.
To create a TLS certificate request

  • Run the following command:

    New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate" -Path c:\certificates\request.req -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com"  -DomainName mail.contoso.com

For detailed syntax and parameter information, see the "New-ExchangeCertificate" topic in Exchange Server 2007 Help.

Important:
The specific details of the certificate or certificate request that you create depends on many variables. If you are generating a request, make sure that you work closely with the CA or the PKI administrator who will issue your certificate. For more information about how to create a certificate request for TLS, see "Appendix 1: Creating a Certificate or Certificate Request for TLS" at the end of this white paper.

Return to top

Transporting Certificate and Related Keys

When you receive a certificate from your PKI or CA provider, convert the issued certificate to a PFX (PKCS#12) file so that you can back it up as part of a disaster contingency. A PFX file contains the certificate and related keys. In some cases, you may want to transport the certificate and keys to move them to other computers. For example, if you have multiple Edge Transport servers where you expect to send and receive e-mail that is Domain Secured, you can create a single certificate that will work for all servers. In this case, you must have the certificate imported and enabled for TLS on each Edge Transport server.

As long as you keep a copy of the PFX file securely archived, you can always import and enable the certificate. The PFX file contains the private key so it's important to physically protect the file by keeping in on storage media in a secure location.

It's important to understand that the Import-ExchangeCertificate cmdlet always marks the imported private key from the PFX as non-exportable. This functionality is by design.

When you use the MMC Certificate snap-in to import a PFX file, you can specify private key exportability and strong-key protection.

Important:
Do not enable strong-key protection on certificates that are intended for TLS. Strong-key protection prompts the user every time that the private key is accessed. With Domain Security, the "user" is the SMTP service on the Edge Transport server.

For more information about how to create certificates that can be used for multiple computers, see "Appendix 1: Creating a Certificate or Certificate Request for TLS" at the end of this white paper.

Importing Certificates to Edge Transport Servers

After the administrator generates the certificate requests, the administrator then uses the requests to generate the certificates for the servers. The resulting certificates must be issued as either a single certificate or a certificate chain and copied to the appropriate Edge Transport servers.

Important:
You must use the Import-ExchangeCertificate cmdlet to import the certificates.
Important:
Do not use the Microsoft Management Console (MMC) Certificate snap-in to import the certificates that do not contain private keys for TLS on the Exchange server. Using the MMC Certificate snap-in to import certificates on Exchange servers does not bind the request that is created in this procedure to the issued certificate. Therefore TLS might fail. You can use MMC to import certificates and keys that are stored as PFX files into the local computer store. After the certificates are imported, you can then enable the certificate for TLS by running the Enable-ExchangeCertificate cmdlet.

When you import the certificate to the Edge Transport server, you must also enable the certificate for the Simple Mail Transfer Protocol (SMTP) service. The Contoso administrator runs the following command on each Edge Transport server, one time for each respective certificate.

To import and enable a TLS certificate for Domain Security on an Edge Transport server

  • Run the following command:

    Import-ExchangeCertificate -Path c:\certificates\import.pfx | Enable-ExchangeCertificate -Services SMTP

This command imports and enables the TLS certificate by pipelining the Enable-ExchangeCertificate cmdlet.

You can also enable the certificate after you import it. To import the certificate, run the following command:

Import-ExchangeCertificate -Path c:\certificates\import.pfx

Then, copy the thumbprint to the Windows clipboard. To display the thumbprint of the certificate you have just imported, run the following command:

Get-ExchangeCertificate |FL

Copy the data from the Thumbprint field to the Windows clipboard.

Finally, to enable the certificate, run the following command:

Enable-ExchangeCertificate -Thumbprint AB493A0C9A6C0327162FE04EF74609CB8FB7FE24 -Services SMTP

Return to top

Configuring Outbound Domain Security

You must perform three steps to configure outbound Domain Security:

  1. Run the Set-TransportConfig cmdlet to specify the domain with which you want to send domain-secured e-mail.
  2. Run the Set-SendConnector cmdlet to set the DomainSecureEnabled property on the Send connector that will send mail to the domain with which you want to send domain-secured e-mail.
  3. Run the Get-SendConnector cmdlet to verify the following:
    • The Send connector that will send mail to the domain with which you want to send domain-secured e-mail routes mail with Domain Name System (DNS).
    • The FQDN is set to match either the Subject Name or the Subject Alternative Name of certificates that you are using for Domain Security.

Because the changes that you make in these three steps are global, you must make the changes on an internal Exchange server. The configuration changes that you make will be replicated out to the Edge Transport servers by using the Microsoft Exchange EdgeSync service.

Specifying the Sender Domain in Transport Configuration

It is relatively straightforward to specify the domain with which you want to send domain-secured e-mail. The Contoso administrator runs the following command on an internal Exchange 2007 server:

Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com

For more information, see the "Set-TransportConfig" topic in Exchange Server 2007 Help.

Note:
The TLSSendDomainSecureList parameter takes a multivalued list of domain names. The Set-TransportConfig command replaces the whole value for TLSSendDomainSecureList with the new value that is supplied in the cmdlet. Therefore, if you want to add a new domain, the value that you supply must include the existing list and the new domain.

Configuring a Send Connector

Contoso will use their default DNS-routed Send connector to send domain-secured e-mail to their partners. Because their default DNS-routed Send connector is a default Internet Send connector, it uses DNS to route mail and does not use a smart host. The FQDN is already set to mail.contoso.com. Because the certificates that the Contoso administrator created set the DomainName parameter of the New-ExchangeCertificate to mail.contoso.com, the Send connector can use the certificates without additional configuration.

If you have configured a subdomain for testing, you may have to update the FQDN of your Send connector to match the certificate that you have created (for example, subdomain.mail.contoso.com). On the other hand, if you have created a certificate that contains the subdomain in the Subject or Subject Alternative name Fields, you don't have to update the FQDN of the Send connector.

Therefore, the only configuration that the Contoso administrator must make to the Send connector is to set the DomainSecureEnabled parameter. To do this, the Contoso administrator runs the following command on an internal Exchange 2007 server for the "Internet" Send connector:

Set-SendConnector Internet -DomainSecureEnabled:$True

For more information, see the "Set-SendConnector" topic in Exchange Server 2007 Help.

You can also use the Exchange Management Console to enable domain-secured e-mail on a Send connector.

To use the Exchange Management Console to configure a Send connector for Domain Security

  1. On a Hub Transport server, open the Exchange Management Console, click Organization Configuration, click Hub Transport, and then in the result pane, click the Send Connectors tab.

  2. Select the Send connector that sends mail to the domain from which you want to send domain-secured e-mail, and then, in the action pane, click Properties.

  3. On the Network tab, select Enable Domain Security (Mutual Auth TLS), click Apply, and then click OK.

Return to top

Configuring Inbound Domain Security

You must perform two steps to enable inbound Domain Security:

  1. Run the Set-TransportConfig cmdlet to specify the domain from which you want to receive domain-secured e-mail.
  2. On the Edge Transport server, use the Exchange Management Shell or the Exchange Management Console to enable Domain Security on the Receive connector from which you want to receive domain-secured e-mail. Because Domain Security requires mutual TLS authentication, TLS must also be enabled on the Receive connector. 

Specifying the Receive Domain in Transport Configuration

It is relatively straightforward to specify the domain with which you want to receive domain-secured e-mail. To specify the domain, the Contoso administrator runs the following command on an internal Exchange 2007 server:

Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com

For more information, see the "Set-TransportConfig" topic in Exchange Server 2007 Help.

Note:
The TLSReceiveDomainSecureList parameter takes a multivalued list of domain names. The Set-TransportConfig command replaces the whole value for TLSReceiveDomainSecureList parameter with the new value supplied by the Set-TransportConfig cmdlet. Therefore, if you want to add a new domain, the value that you supply must include the existing list and the new domain.

Configuring a Receive Connector

You must configure the Receive connector on each Edge Transport server that accepts mail from the domain from which you want to receive domain-secured e-mail. The Contoso environment is configured to have a single Internet Receive connector, with an Identity of Inet, on both Edge Transport servers. Therefore, to enable TLS while mail is sent to or received from Woodgrove Bank, the Contoso administrator must make sure that TLS is enabled on the default Internet Receive connector on both Edge Transport servers.

To use the Exchange Management Shell to configure a Receive connector for Domain Security

  • On the Edge Transport server, run the following command:

    Set-ReceiveConnector Inet -DomainSecureEnabled:$True -AuthMechanism TLS

For detailed syntax and parameter information, see the "Set-ReceiveConnector" topic in Exchange Server 2007 Help.

To use the Exchange Management Console to configure a Receive connector for Domain Security

  1. On the Edge Transport server, open the Exchange Management Console, click Edge Transport, and then in the result pane, click the Receive Connectors tab.

  2. Select the Receive connector that accepts mail from the domain from which you want to receive domain-secured e-mail, and then, in the action pane, click Properties.

  3. On the Authentication tab, select Transport Layer Security (TLS) and Enable Domain Security (Mutual Auth TLS), and then click OK.

Be aware that specifying the authentication mechanism as TLS doesn't force TLS on all inbound connections.

TLS will be forced for connections from Woodgrove Bank for the following reasons:

  • Woodgrove Bank is specified in the Set-TransportConfig cmdlet on the TLSReceiveDomainSecureList parameter.
  • The DomainSecureEnabled parameter is set to $True on the Receive connector.

Other senders that are not listed on the TLSReceiveDomainSecureList parameter in the Set-TransportConfig cmdlet will only use TLS if TLS is supported by the sending system.

Note:
A side effect of enabling Domain Security on a Receive connector is that a client certificate is requested during TLS negotiation. If the domain from which the client is sending is not in the secure domain list, the client will not be required to submit the certificate.

Return to top

After you have configured domain-secured e-mail, you can test the connection by reviewing the performance logs and the protocol logs. Messages that have successfully authenticated over the domain-secured mail flow path are displayed in Outlook 2007 as "Domain Secure" messages.

Performance Counters

The Domain Security feature includes the following set of performance counters under MSExchange Secure Mail Transport:

  • Domain-Secured Messages Received
  • Domain-Secured Messages Sent
  • Domain-Secured Outbound Session Failures

You can create a new counter log file for domain-secured mail flow with these performance counters to monitor the number of messages sent and received and also to monitor failed mutual TLS sessions. For more information about how to create and configuring counter logs, see the Help file that is included with the Performance Logs and Alerts MMC snap-in.

Return to top

Protocol Logs

You can review the Send protocol logs and Receive protocol logs to determine whether TLS negotiation has been successful. Successful TLS negotiation generates logs that resemble the examples in the following two sections.

To view detailed protocol logs, you must set the protocol logging level to Verbose on the connectors that your organization uses to send and receive Domain Secured e-mail.

To use the Exchange Management Shell to configure a Receive connector for verbose protocol logging

  • On the Edge Transport server, run the following command:

    Set-ReceiveConnector Inet -ProtocolLoggingLevel Verbose

    Where Inet is the name of the Receive connector on which Domain Secured e-mail is enabled.

To use the Exchange Management Shell to configure a Send connector for verbose protocol logging

  • On the Edge Transport server, run the following command:

    Set-SendConnector Internet -ProtocolLoggingLevel Verbose

    Where Internet is the name of the Send connector where Domain Secured e-mail is enabled.

For more information about how to view protocol logs, see How to Configure Protocol Logging.

Example of a Send Protocol Log

<220 edgedns3 ESMTP Microsoft ESMTP MAIL Service, Version: 8.0.647.0; Tue, 29 Aug 2006 04:22:00 -0700 (PDT)
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-STARTTLS
<250-DELIVERBY
<250 HELP
>STARTTLS
<220 2.0.0 Ready to start TLS
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-DELIVERBY
<250 HELP
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, sending message
>MAIL FROM:<user@woodgrove.com> SIZE=614
>RCPT TO:<root@smi.extest.contoso.com>
<250 2.1.0 <user@woodgrove.com>... Sender ok
<250 2.1.5 <root@smi.extest.contoso.com>... Recipient ok
>DATA
<354 Enter mail, end with "." on a line by itself
<250 2.0.0 k7TBM0BZ000043 Message accepted for delivery
>QUIT
<221 2.0.0 edgedns3 closing connection

Example of a Receive Protocol Log

>220 edgea36 Microsoft ESMTP MAIL Service, Version: 8.0.647.0 ready at Mon, 28 Aug 2006 15:37:53 -0700
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-STARTTLS
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<STARTTLS
>220 2.0.0 SMTP server ready
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<MAIL From:<user@smi.extest.contoso.com> SIZE=16
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, receiving message
>250 2.1.0 user@smi.extest.contoso.com Sender OK
<RCPT To:<user@woodgrove.com>
>250 2.1.5 user@woodgrove.com Recipient OK
<DATA
>354 Start mail input; end with <CRLF>.<CRLF>
>250 2.6.0 <200608281121.k7SBHYi0004586@edgedns3> Queued mail for delivery
<QUIT
>221 2.0.0 Service closing transmission channel

Return to top

This section explains how to create X.509 TLS certificates or a certificate request by using the ExchangeCertificate cmdlets in the Exchange Management Shell.

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 MMC. For more information about how to use the Certificate Manager snap-in, see "To Add Certificate Manager to Microsoft Management Console" earlier in this white paper

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 PKI 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 white paper.

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.

Best Practices for Domain Names for Internet SMTP

When you create a certificate or a certificate request for an Edge Transport server performing mutual 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 (http://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

Return to top

Although it is not a best practice, you can enable Domain Security on Hub Transport servers.

To enable Domain Security, you must make the following configurations on the Receive connector that you will use for Domain Secure e-mail:

  • Enable the Domain Secure flag.
  • Add Partners to the permissions group.

After you have made these configurations, configure the Hub Transport server exactly as you would an Edge Transport server.

To run the Set-ReceiveConnector cmdlet, the account you use must be delegated the following:

  • Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

To use the Exchange Management Shell to enable Domain Security on a Hub Transport server

  • On the Hub Transport server, run the following command:

    Set-ReceiveConnector Inet  -DomainSecureEnabled $true  -PermissionGroups Partners

    Where Inet is the name of the Receive connector where Domain Secure e-mail is to be enabled.

By using the Domain Security feature in Exchange 2007, you can manage secured message paths between domains over the Internet.

For the complete Exchange 2007 documentation, see Exchange Server 2007 Help.

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

Return to top

Tags What's this?: Add a tag