Академический Документы
Профессиональный Документы
Культура Документы
Exchange Exchange Server 2013 Mailbox and Client Access Servers Client Access Server Digital Certificates and SSL Create a Digital Certificate Request Exchange 2013 Certificate Management UI
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's transmitted. For Windows-based users, computers, and services, trust in a CA is established when there's 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 2013, a self-signed certificate is automatically configured on the Mailbox servers. 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. This self-signed certificate is used to encrypt communications between the Client Access server and the Mailbox server. The Client Access server trusts the self-signed certificate on the Mailbox server automatically, so no third-party certificate is needed on the Mailbox server. When you install Exchange 2013, a self-signed certificate is also created on the Client Access server. This self-signed certificate will allow some client protocols to use SSL for their communications. Exchange ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate. Outlook Anywhere won't work with a self-signed certificate on the Client Access server. 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 confirms the trust, then SSL communications can continue.
Note:
By default, the digital certificate installed on the Mailbox server or servers is a self-signed certificate. You dont need to replace the self-signed certificate on the Mailbox servers in your organization with a trusted third-party certificate. The Client Access server automatically trusts the self-signed certificate on the Mailbox server and no other configuration is needed for certificates on the Mailbox server.
Frequently, small organizations decide not to use a third-party certificate or not to install their own PKI to issue their own certificates. They might make this decision because those solutions are too expensive, 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's much more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation when you use self-signed certificates.
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 PKIgenerated 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. These PKI certificates can't be deployed publicly, as other types of certificates can be. However, 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.
IIS
All the following Exchange services use the same certificate on a given Exchange Client Access server: Outlook Web App Exchange Administration Center (EAC) Exchange Web Services Exchange ActiveSync Outlook Anywhere Autodiscover Outlook Address Book distribution Because only a single certificate can be associated with a website, and because all these services are offered under a single website by default, all the names that clients of these services use must be in the certificate (or fall under a wildcard name in the certificate).
POP/IMAP
Certificates that are used for POP or IMAP can be specified separately from the certificate that's used for IIS. However, to simplify administration, we recommend that you include the POP or IMAP service name in your IIS certificate and use a single certificate for all these services.
SMTP
A separate certificate can be used for each receive connector that you configure. The certificate must include the name that SMTP clients (or other SMTP servers) use to reach that connector. To simplify certificate management, consider including all names for which you have to support TLS traffic in a single certificate.