Aracılığıyla paylaş

Understanding SSL for Client Access Servers

  • Makale

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

 

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

Secure Sockets Layer (SSL) is a method for securing communications between a client and a server. For a computer that is running Microsoft Exchange Server 2007 that has the Client Access server role installed, SSL is used to help secure communications between the server and the clients. Clients include mobile devices, computers inside an organization's network, and computers outside an organization's network. These include clients with and without virtual private network (VPN) connections.

By default, when you install Exchange 2007, client communications are encrypted by using SSL when you use Outlook Web Access, Exchange ActiveSync, and Outlook Anywhere. By default, Post Office Protocol version 3 (POP3) and Internet Message Access Protocol Version 4 rev1 (IMAP4) are not configured to communicate over SSL.

SSL requires that you use digital certificates. This topic provides an overview of the various types of digital certificates and information about how to configure the Client Access server to use these types of digital certificates.

Overview of Digital Certificates

Digital certificates are electronic files that work like an online password to verify the identity of a user or a computer. They are used to create the SSL encrypted channel that is used for client communications. A certificate is a digital statement that is issued by a certification authority (CA) that vouches for the identity of the certificate holder and enables the parties to communicate in a secure manner by using encryption.

Digital certificates do the following:

  • They authenticate that their holders—people, Web sites, and even network resources such as routers—are truly who or what they claim to be.

  • They protect data that is exchanged online from theft or tampering.

Digital certificates can be issued by a trusted third-party CA or a Microsoft Windows public key infrastructure (PKI) by using Certificate Services, or they can be self-signed. Each type of certificate has advantages and disadvantages. Each type of digital certificate is tamper-proof and cannot be forged.

Certificates can be issued for several uses. These uses include Web user authentication, Web server authentication, Secure/Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol security (IPsec), Transport Layer Security (TLS), and code signing.

A certificate contains a public key and attaches that public key to the identity of a person, computer, or service that holds the corresponding private key. The public and private keys are used by the client and the server to encrypt the data before it is transmitted. For Microsoft Windows-based users, computers, and services, trust in a CA is established when there is a copy of the root certificate in the trusted root certificate store and the certificate contains a valid certification path. For the certificate to be valid, the certificate must not have been revoked and the validity period must not have expired.

Types of Certificates

There are three primary types of digital certificates: self-signed certificates, Windows PKI-generated certificates, and third-party certificates.

Self-Signed Certificates

When you install Exchange 2007, a self-signed certificate is automatically configured. A self-signed certificate is signed by the application that created it. The subject and the name of the certificate match. The issuer and the subject are defined on the certificate. A self-signed certificate will allow some client protocols to use SSL for their communications. Microsoft Exchange ActiveSync and Office Outlook Web Access can establish an SSL connection by using a self-signed certificate. Outlook Anywhere will not work with a self-signed certificate. Self-signed certificates must be manually copied to the trusted root certificate store on the client computer or mobile device. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. If the client continues, SSL communications can continue.

Frequently, small organizations decide not to use a third-party certificate or not to install their own PKI to issue their own certificates because of the expense, because their administrators lack the experience and knowledge to create their own certificate hierarchy, or for both reasons. The cost is minimal and the setup is simple when you use self-signed certificates. However, it is much more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation when you use self-signed certificates.

Windows Public Key Infrastructure Certificates

The second type of certificate is a Windows PKI-generated certificate. A PKI is a system of digital certificates, certification authorities, and registration authorities (RAs) that verify and authenticate the validity of each party that is involved in an electronic transaction by using public key cryptography. When you implement a CA in an organization that uses Active Directory, you provide an infrastructure for certificate life-cycle management, renewal, trust management, and revocation. However, there is some additional cost involved in deploying servers and infrastructure to create and manage Windows PKI-generated certificates.

Certificate Services are required to deploy a Windows PKI and can be installed through Add Or Remove Programs in Control Panel. You can install Certificate Services on any server in the domain.

If you obtain certificates from a domain-joined Windows CA, you can use the CA to request or sign certificates to issue to your own servers or computers on your network. This enables you to use a PKI that resembles a third-party certificate vendor, but is less expensive. Although these PKI certificates cannot be deployed publicly, as other types of certificates can be, when a PKI CA signs the requestor's certificate by using the private key, the requestor is verified. The public key of this CA is part of the certificate. A server that has this certificate in the trusted root certificate store can use that public key to decrypt the requestor's certificate and authenticate the requestor.

The steps for deploying a PKI-generated certificate resemble those required for deploying a self-signed certificate. You must still install a copy of the trusted root certificate from the PKI to the trusted root certificate store of the computers or mobile devices that you want to be able to establish an SSL connection to Microsoft Exchange.

A Windows PKI enables organizations to publish their own certificates. Clients can request and receive certificates from a Windows PKI on the internal network. The Windows PKI can renew or revoke certificates.

For more information, see the following topics:

Trusted Third-Party Certificates

Third-party or commercial certificates are certificates that are generated by a third-party or commercial CA and then purchased for you to use on your network servers. One problem with self-signed and PKI-based certificates is that, because the certificate is not automatically trusted by the client computer or mobile device, you must make sure that you import the certificate into the trusted root certificate store on client computers and devices. Third-party or commercial certificates do not have this problem. Most commercial CA certificates are already trusted because the certificate already resides in the trusted root certificate store. Because the issuer is trusted, the certificate is also trusted. Using third-party certificates greatly simplifies deployment.

For larger organizations or organizations that must publicly deploy certificates, the best solution is to use a third-party or commercial certificate, even though there is a cost associated with the certificate. Commercial certificates may not be the best solution for small and medium-size organizations, and you might decide to use one of the other certificate options that are available.

Choosing a Certificate Type

When you choose the type of certificate to install, there are several factors to consider. A certificate must be signed to be valid. It can be self-signed or signed by a CA. A self-signed certificate has limitations. For example, not all mobile devices let a user install a digital certificate in the trusted root certificate store. The ability to install certificates on a mobile device depends on the mobile device manufacturer and the mobile operator. Some manufacturers and mobile operators disable access to the trusted root certificate store. In this case, neither a self-signed certificate nor a certificate from a Windows PKI CA can be installed on the mobile device.

Most mobile devices have several trusted third-party commercial certificates preinstalled. For the optimal user experience, implement certificate-based authentication for Exchange ActiveSync by using devices that are running Windows Mobile 6.0 and a digital certificate from a trusted third-party CA.

For More Information

For more information, see the following topics: