You're not finished yet. As the Submission Confirmation page tells you, you need to return to the CA to check the status of the request and retrieve the issued certificate. (Depending on whether you're using an enterprise or standalone CA, the CA might automatically issue the certificate or require administrator intervention. For information about the difference between enterprise and standalone CAs, see the Certificate Services documentation in Windows Server Help.) To do so, return to the CA Welcome page at http://servername/certsrv, where servername is the name of your server. Select Check on a pending certificate, then click Next. The CA lists all known pending requests. Select yours, then click Next.
What you see then depends on whether the CA has issued your certificate. If it hasn't, the CA Web page tells you that the request is still pending. In that case, you'll need to approve the request (or have it approved). For an explanation of how to use the Microsoft Management Console (MMC) Certificate Services snap-in to approve a request, see the sidebar "Approving Pending Requests." If the CA has issued the certificate, you'll see a page like the one that Figure 4 shows. This page is a little confusing because it offers no clearly labeled "Download my new certificate" link. Click Download CA certificate and save the resulting file on your Exchange server. ESM expects the certificate to be stored in the Distinguished Encoding Rules (DER)encoded format, so be sure to choose that format when you save the certificate.
After you save the certificate, you're ready to associate it with your virtual server. Return to ESM, find the virtual server to which you want to attach the certificate, and open the server's Properties dialog box. On the Access tab, click Certificate to start the IIS Certificate Wizard. This time, the wizard states that a certificate request is pending; select Process the pending request and install the certificate. On the next page, specify the path to the certificate file you just downloaded, and click Next. ESM decodes the certificate and shows you a summary screen so that you can verify that you're installing the right certificate. When you're satisfied, click Next once more, then click Finish to install your certificate. To verify that the certificate is installed, check the status of the Access tab's Communications button—this button is available only when a valid certificate is installed for the virtual server.
Enabling STARTTLS
With a certificate in place, you can start using it to protect your SMTP traffic. You have three choices: You can force the use of TLS for all outbound mail; you can use TLS for mail to selected domains; or you can force other servers that contact you to use TLS. These options are independent of one another, so you can use them individually or together.
To turn on TLS for all outbound mail on a selected SMTP virtual server, go to the Delivery tab on the SMTP virtual server's Properties page. Click the Outbound Security button to display the Outbound Security dialog box, which Figure 5 shows. Select the TLS encryption check box and click OK. However, be aware that this option effectively restricts Exchange to communicating only with hosts that support TLS. This restriction has the unwelcome side effect of making email messages sent to other hosts sit in delivery queues forever, or until the retry interval expires and the messages are returned with a nondelivery report (NDR).
A better approach is to use SMTP connectors to tailor the use of TLS to specific domains. You're almost certainly better off restricting your outbound TLS use to domains that you know support TLS. (To find out whether a domain supports TLS, telnet to port 25 on the domain's mail server and run the SMTP EHLO command from a command prompt. If the response lists STARTTLS, the domain supports TLS.) The easiest way to tailor the use of TLS is to create SMTP connectors for domains that support TLS, which you do from within ESM's Routing Groups container. When you create the connector (or modify the properties of an existing container), the two crucial steps are to ensure that you've specified the correct domains in the Address Space tab and to ensure that you've turned on TLS on the Advanced tab (click the Advanced tab, click Outbound Security, and select the TLS encryption check box).
Turning on inbound TLS is almost as easy. Go to the Access tab on the virtual server's Properties page, then click Communication in the Secure Communication command group. In the Security dialog box, which Figure 6 shows, you can turn on TLS at its default 40-bit strength or specify the full (and highly recommended) 128-bit version. Be aware that selecting the Require secure channel check box does exactly that: Servers that don't support TLS, or can't successfully negotiate a set of TLS parameters with your server won't be able to deliver mail to you. Be careful about selecting Require secure channel; if the volume of inbound mail subsequently drops, you might need to consider whether improved privacy is worth losing messages.
Troubleshooting TLS
After you turn on outbound TLS, keep an eye on your server queues. Some systems (primarily those running variants of UNIX Sendmail) will reject TLS connections from systems that use self-signed certificates, whereas others will accept STARTTLS, then won't complete the security negotiation for some other reason. If your server can't successfully negotiate a TLS connection and if it or the other system requires TLS, mail won't flow to that system.
If you see mail backing up to a particular destination system after you turn on TLS, you'll need to find out whether TLS failure is the cause. If it is, you'll need to determine why TLS is failing. Check the SMTP logs and the System and Application event logs for clues. If that doesn't help, contact the remote system's administrator.
If you still can't resolve the problem, you might be able to work around it. Although the Exchange SMTP engine doesn't support domain-specific TLS settings, you can create another SMTP virtual server that doesn't use TLS, then pair it with an SMTP connector. Set the connector's properties to include the domains that you're having trouble communicating with. Because Exchange always prefers a more specific route to a less specific one, mail bound for the specified destinations will be sent over that connector, and your mail will flow again.
End of Article
