Digital certificates are electronic files that work like an online passport to verify the identity of a user or computer and are used to create an encrypted channel that is used to protect data. A certificate is basically 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. They can be issued by a trusted third-party CA, such as by using Certificate Services, or be self-signed. Each type of certificate has its advantages and disadvantages. However, certificates are always tamper-proof, and cannot be forged. Certificates can be issued for a variety of functions, such as Web user authentication, Web server authentication, S/MIME, IPsec, Transport Layer Security (TLS), and code signing.
A certificate binds a public key to the identity of the person, computer, or service that holds the corresponding private key. The public and private keys are used by both the client and the server to encrypt the data before it is transmitted across the wire. Certificates are used by a variety of public key security services and applications that provide authentication, data integrity, and secure communications across networks such as the Internet. For 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 store and the certificate contains a valid certification path. This means that no certificates in the certification path have been revoked or have had the validity period expire.
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.
There are traditionally three options or kinds of certificates that Unified Messaging and IP gateways or IP PBXs can use. In all three approaches or options, the public key of the certificate owner is part of the certificate so that the server, user, Web site, or other resource that is on the other end can decrypt the messages. The private key is known only to the signer of the certificate. Each certificate has an EnhancedKeyUsage attribute set on it to dictate the specific usage for the certificate. For example, usage could be specified only for server authentication or for use with the encrypting file system. Unified Messaging uses the certificate for server authentication and data encryption.
Self-Signed Certificates
A self-signed certificate is a certificate that is signed by its own creator. The subject and the name of the certificate match. On self-signed certificates, the issuer and subject are defined on the certificate. Self-signed certificates do not require the presence of a CA from your organization or from a third party. You must configure these certificates explicitly and copy them to the trusted root certificate store on each IP gateway, IP PBX, other Unified Messaging servers, and other Exchange 2007 computers if they are to be trusted by the Unified Messaging server that has issued the certificate.
If a public key infrastructure (PKI)-based or third-party certificate is unavailable, the Unified Messaging server will search for a self-signed certificate in the local certificate store. If it cannot find a PKI or third-party certificate, it will generate a self-signed certificate for mutual TLS. However, because it is a self-signed certificate, it will not be trusted by the IP gateways, IP PBXs on the network, or other servers on the network. To make sure that the self-signed certificate is trusted by IP gateways, IP PBXs, or other servers, you have to import the self-signed certificate into the local trusted root certificate store for the devices and servers. After you do this, when the Unified Messaging server presents this self-signed certificate to the IP gateway, IP PBX, or server, it will be able to verify that the certificate was issued by a trusted authority because the issuer will equal the subject that is defined on the self-signed certificate.
If you are using only self-signed certificates, you must import a single self-signed certificate for each IP gateway, IP PBX, or server. In large network environments that have multiple devices or computers, this may not be the best choice for implementing mutual TLS. Using self-signed certificates in a large enterprise network does not scale well because of the additional administrative overhead. However, administrative overhead is not a problem if you have multiple devices and you are using a PKI or commercial third-party certificate. This is because each device has a certificate that has been issued by the same trusted root authority. Having a certificate from the same trusted root authority guarantees that all IP gateways, IP PBXs, and other servers trust the Unified Messaging server.
For mutual TLS to work using self-signed certificates:
-
Take the Unified Messaging server's self-signed certificate and import it into the trusted root certificate store on each IP gateway and IP PBX and on other servers that the Unified Messaging server will communicate with by using mutual TLS.
-
Take the self-signed certificate from each IP gateway, IP PBX, and other server and import it into the Unified Messing server's trusted root certificate store. If you are using a PKI or third-party certificate, you will import the certification authority's certificate into the trusted root certificate store on all devices and servers.
Self-signed certificates are frequently not the best certificate option when you deploy mutual TLS or certificate-based authentication. However, smaller organizations with a limited number of devices or computers may decide to use the self-signed certificate method because it is the most easy to configure and the least expensive method to use when you implement mutual TLS. Frequently, smaller organizations decide not to use a third-party certificate or 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 are using self-signed certificates. However, establishing an infrastructure for certificate life-cycle management, renewal, trust management, and revocation is much more difficult with self-signed certificates. For more information about how to create a certificate for TLS, see Creating a Certificate or Certificate Request for TLS.
Public Key Infrastructure
A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), 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. These qualities provide a solid infrastructure for all the certificates in your organization. However, there is some cost involved in deploying additional servers and infrastructure to create and manage these types of certificates.
You can install Certificate Services on any server in the domain. If you obtain certificates from a domain Windows-based 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 using a third-party certificate vendor but is less expensive. Although these PKIs cannot be deployed publicly, as other types of certificates can be, when a PKI is used, a CA signs the requestor’s certificate by using the private key and the requestor is verified. The public key of this CA is included with the certificate that is issued by the CA. Anyone who has this CA’s certificate as a root certificate can use that public key to decrypt the requestor’s certificate and authenticate the requestor.
When you use a PKI certificate to implement mutual TLS, you must copy the required certificates to the IP gateways or IP PBXs. Then you must copy the certificates on the IP gateways or IP PBXs to the Unified Messaging servers that are associated with the UM dial plan that has been configured in secure mode.
The setup and configuration for using PKI certificates and third-party certificates resemble the procedures that you perform when importing and exporting the self-signed certificates. However, you must not only install the computer certificate into the trusted root certificate store. You must also import or copy the trusted root certificate for the PKI into the trusted root certificate store on the Unified Messaging servers and the IP gateways and IP PBXs on your network.
To deploy mutual TLS when you have already deployed a PKI infrastructure, follow these steps:
-
Generate a certificate request on each IP gateway or PBX.
-
Copy the certificate request to use when requesting the certificate from a certification authority.
-
Request a certificate from the certification authority by using the certificate request. Save the certificate.
-
Import the certificate that you saved onto each device or computer.
-
Download the trusted root certificate for your PKI.
-
Import the trusted root certificate from your PKI on each device. If you are importing the trusted root certificate on an Exchange 2007 computer that is running the Unified Messaging role, you can also use Group Policy to import the trusted root certificate into the trusted root certificate store on the Unified Messaging server or other Exchange 2007 servers. However, this process is also used when you are configuring a server that is running the Unified Messaging server role.
.gif) Note: |
|---|
|
You will use the same steps if you are using a commercial third-party certificate to implement mutual TLS.
|
For more information about certificates and PKIs, see the following topics.
Third-Party Certification Authorities
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 trusted, you must make sure that you import the certificate into the trusted root certificate store on client computers, servers, and other 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, it is best 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 smaller and medium-size organizations, and you might decide to use one of the other certificate options that are available.
Depending on the configuration of the IP gateway or IP PBX, you might still have to import the third-party or commercial certificate into the trusted certificate store on the IP gateways and IP PBXs to be able to use the third-party certificate for mutual TLS. However, in some cases, the third-party certificate will be included in the trusted root certificate store on your Unified Messaging server and other Exchange 2007 computers in your organization.
The procedures that you perform to use a commercial third-party certificate for enabling mutual TLS are the same procedures that you perform when you use a PKI certificate. The only difference is that you will not have to generate a PKI certificate because you have purchased a certificate from a commercial third-party certificate vendor that will be imported into the trusted root certificate store on the servers and devices on your network.