Secure Sockets Layer (SSL) is the foundation for almost all network-layer protection of Exchange data in Exchange Server 2007. SSL is a technology that allows a network client and a server to negotiate an encryption key that is used as a session key to encrypt data sent between the client and the server. The client requests the server's certificate (which will become important here shortly) and uses the server's public key to initially exchange an encryption key.
While the technology was designed for use with the HTTP protocol, it can be adapted to be used with almost any protocol, including SMTP, POP3, and IMAP4. It should be noted that the actual technology that is used with SMTP is Transport Layer Security (TLS), which is the Internet standardize version of SSL.
Using Self-Signed Certificates and Exchange 2007
A certificate is automatically installed on all Exchange Server 2007 Hub Transport and Client Access servers so they can use SSL or TLS. This certificate is a self-signed certificate that is generated automatically by the installation process. The self-signed certificate allows Outlook Web Access clients to use HTTPS web services and it allows Hub Transport servers to use TLS.
You might think this is all well and good, but self-signed certificates are problematic for a few reasons. First, when a user connects to an Outlook Web Access site that is using a self-signed certificate, they see a web browser error like the one shown in Figure 20.3.
While the user can simply click Continue to This Website (Not Recommended) and proceed to Outlook Web Access and SSL will work, we strongly discourage any organization from allowing end users to do this. Getting users in the habit of ignoring security warnings is never a good thing.
The second problem will occur with Outlook 2007 when the client connects to the Autodiscover, Availability, and offline address book virtual directories. Figure 20.4 shows the error that may be displayed if the client does not trust the server's certificate.
Outlook Anywhere clients may not work if they don't trust the certificate authority that signed the certificate on the Hub Transport server. Remote SMTP servers that attempt to initiate TLS to Exchange 2007 Hub Transport servers may also not transmit mail if they do not trust the Hub Transport server's certificate.
Requesting and Installing Certificates for Exchange Server 2007
When planning an Exchange deployment that includes the use of SSL or TLS, you need to ensure that certificates that are used by Hub Transport servers and Client Access servers are properly trusted. Let's look at the general properties of a self-signed certificate used for an Exchange server; this property page is shown in Figure 20.5.
Trusted certificates have three characteristics:
-
The date range for the certificate includes the current date. This is the Valid From information.
-
The FQDN that the server was issued to matches the name that the client used to connect to the server. This is the Issued To information.
-
The issuer of the certificate is a certificate authority that is trusted by the local computer. This is the Issued By information.
The reason the self-signed certificate is invalid is that the issuer is not one of the trusted certificate authorities. You need to get a certificate that has been issued by a trusted certificate authority. This can be one of many third-party certificate authorities or it could be your own internal certificate server. If you use an internal certificate server, you still have to distribute your certificate server's certificate to all clients that will use certificates issued by that server.
| Tip | For a list of certificate authorities that are trusted by Windows by default, see the Microsoft Root Certificate Program Members list at http://preview.tinyurl.com/2ktu9m. |
For simplicity's sake, we recommend using a third party's certificate server. Though an annual fee is usually involved, this is the simplest approach and ensures that clients do not receive security warnings or errors.
With simple websites and with Exchange 2000/2003, generating a certificate request was pretty simple since you all you needed to do was to generate the request and use the FQDN that the users would be using to connect to your site. Then you sent the certificate request to the certificate authority to be signed.
Exchange 2007 Client Access servers use different URLs for internal and external clients. This is not only because of Outlook Web Access, but also due to Autodiscover, the Availability service, offline address books, and other web services that may be associated with the default website in IIS. Let's take as an example a server that hosts the Hub Transport and Client Access server roles for an organization. It may be referred to by a number of different names under different circumstances. The server's name is HNLEX04, the Active Directory DNS name is volcanosurfboards.int, and the public domain name is somorita.com. The following hostnames and fully qualified domain names may be used against this server:
-
hnlex04
-
hnlex04.volcanosurfboards.int
-
mail.somorita.com (by remote web clients)
-
autodiscover.somorita.com (by remote Autodiscover clients
You might think that you need multiple virtual web servers in order to support all of these different names, but that is not the case thanks to a feature of X.509v3 certificates called a subject alternative name that allows for other hostnames and DNS domain names. However, you cannot use the Internet Information Services Manager to generate a certificate request. You must use the Exchange 2007 Exchange Management Shell (EMS) cmdlet New-ExchangeCertificate to generate the request. Let's do an example that requests a certificate with the following information:
| Organization name | Somorita Surfboards |
| Organizational unit | IT Department |
| FQDN domain name | mail.somorita.com |
| Additional names | hnlex04, hnlex04.volcanosurfboards.int, autodiscover.somorita.com |
| Certificate request filename | C:\CertReq.txt |
On the console of server hnlex04, you must type the following command to generate the certificate request file. Below the command is the output of the certificate request generation:
New-ExchangeCertificate -GenerateRequest -SubjectName
"ou=IT Department,o=Somorita Surfboards, cn=mail.somorita.com" -domainname hnlex04,
hnlex04.volcanosurfboards.int,autodiscover.somorita.com"
-path c:\CertReq.txt
Thumbprint Services Subject
---------- -------- -------
5BDE878D6A6D34DE6462557F785B19D424642D42 ..... CN=mail.somorita.com, 0...
The certificate request file (CertReq.txt) is not exactly a beauty-come-hither. As a matter of fact, it is a format that almost no one but a certification authority could love. Figure 20.6 shows the text of the certificate signing request.
The text that you see in Figure 20.6 is actually a base64 encoded request of the information that we created using the New-ExchangeCertificate cmdlet. We will need to take this text and give it to the certification authority; usually this is done by copying the CSR text and pasting it in to a text box on the certificate authority's website, as shown in Figure 20.7.
Figure 20.7: Pasting the certificate signing request into a text box on a certificate authority's website Depending on the certificate authority, you may get a signed certificate back immediately (especially if you have an account) or you may have to wait a few hours or even days for verification to take place. Ultimately, you will download a certificate file or the CA will e-mail the file to you. You need to save this to a file on to the server's local file system (hnlex04, in our case) and use the EMS cmdlet Import-ExchangeCertificate to import the certificate in to the machine's certificate store.
| Note | At the time of this writing, the only 3rd party certificate authority we are aware of that will sign a certificate request containing subject alternate names is Entrust (www.entrust.com). |
In the following example, we are importing a newly generated certificate into the machine's certificate store. The certificate file name is WebServices.cer and we will assign it the friendly name of HNLEX04 Web Services Certificate. Here is an example:
Import-ExchangeCertificate -path c:\WebServices.cer
-FriendlyName"HNLEX04 Web Services Certificate"
Thumbprint Services Subject
---------- -------- -------
A171D0FA13E121AA553A83A4BDDC7BE830CB8034 ..... CN=mail.somorita.com, 0...
This imports the certificate into the certificate store, but it does not enable the certificate. You now have to use the Enable-ExchangeCertificate cmdlet to associate the certificate with IIS (or other Internet services). Notice the thumbprint attribute; this will come in handy. Here is the command to enable the certificate for use with web services (IIS) as well as SMTP, POP3, and IMAP4:
Enable-ExchangeCertificate -Thumbprint
A171D0FA13E121AA553A83A4BDDC7BE830CB8034 -Services"IIS,POP,IMAP,SMTP"
If you don't remember the thumbprint, you can use the Get-ExchangeCertificate to retrieve it for you. Here is an example:
Get-ExchangeCertificate | where {$_.subject - like"*mail.somorita.com*"}| FL
AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule,
System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {mail.somorita.com, hnlex04, hnlex04.volcanosurfboards.int,
autodiscover.somorita.com}
HasPrivateKey : True
IsSelfSigned : False
Issuer : CN=hnldc01, DC=volcanosurfboards, DC=com
NotAfter : 1/22/2009 7:08:17 PM
NotBefore : 1/23/2007 7:08:17 PM
PublicKeySize : 2048
SerialNumber : 5334E5FC000000000009
Status : Valid
Subject : CN=mail.somorita.com, OU=IT Department,
0=Somorita Surfboards
Thumbprint : A171D0FA13E121AA553A83A4BDDC7BE830CB8034
