Lync Server utilizes SSL
certificates to protect connections by authenticating the endpoint and
then encrypting transmissions. Lync Server can utilize either public or
private certificates. This is to say that a Lync Server administrator
has the option to purchase certificates from a publicly trusted third
party such as Verisign or Digicert or he can choose to issue his own
certificates from an internally developed PKI.
A PKI consists of hardware
and software in addition to policies and procedures to create and manage
digital certificates.
Understanding PKI Roles
Most PKIs consist of many
roles. Some roles are optional and based on the level of assurance
desired, but it is useful to understand PKI terminology. Following are
some terms you should know:
Certificate Authority (CA)— An entity that issues digital certificates that certify ownership of a public key by the named subject of the certificate.
Root CA—
The first CA in a PKI, this role anchors the CA hierarchy. The entire
PKI is only as trustworthy as the Root CA. Any user, computer, or
service that trusts the Root CA implicitly trusts any certificate issued
by other CAs in the hierarchy.
Policy CA—
Typically located at the second tier of a CA hierarchy, the Policy CA’s
job is to issue certificates to other CAs, not to end consumers. The
Policy CA defines the rules by which the lower tier CAs operate. Policy
CAs are typically used only in wide-reaching PKIs.
Issuing CA—
The Issuing CA is the CA that provides certificates to the end
consumer. The Issuing CA can issue certificates only for which it has
templates defined.
Understanding Certificates
Digital certificates are a form
of electronic credentials that validate the identity of entities on a
network. Certificates allow a public key to be signed by a trusted
authority to vouch for
another entity’s identity. Certificates can be used for different
purposes depending on the Object Identifier (OID) assigned to the
certificate by a template. This allows a certificate to be used for
authentication, encryption, or data integrity.
The best way to
understand how this process works is to compare it to a process with
which people are already familiar. The process parallels nicely to the
idea of a driver’s license.
A driver’s license is a
well-accepted form of identification for people. To request a driver’s
license, you need to go to the DMV. The DMV acts like a registration
authority because it validates the identity of the requestor. The DMV is
allowed to issue only one type of item: a driver’s license. The license
has a standardized appearance and standard information. This is similar
to the concept of a certificate template on a CA. It defines what
information must be gathered and what information can go into the
certificate. The local DMV acts like an Issuing CA, and the state-level
DMV acts like a Root CA and a Policy CA in that it sets forth the
standards for what the local DMV is allowed to issue.
After a user is issued a
driver’s license, he can present it to other entities as a form of
identity validation. This is functionally equivalent to authentication.
Although the entity that looks at the license can’t personally
authenticate the card holder, he is able to compare the identity on the
license to the information available about the license holder. Because
the entity trusts the DMV, it can assume that the DMV did a sufficient
job of validating the identity of the card holder and trust that the DMV
vouches for the identity of the card holder. This is the same way in
which a computer trusts the identity of another computer based on the
certificate it holds. If the queried information on the computer matches
what is in the certificate and if the Root CA at the top of the CA
hierarchy is trusted, the connection is trusted.
Note
This process allows a client
to be sure that the server to which he is connecting is the server he
thinks it is. Without this type of authentication, a client can be
redirected to a malicious host and can potentially send sensitive
information to an untrustworthy host. This is typically called a man in
the middle attack; the use of certificates is an excellent way to
prevent this situation.
Installing Certificate Services
Although certificate
services are offered by a number of vendors. In smaller scenarios, an
Enterprise Root CA can be provisioned, although in many cases, those
smaller organizations might still want to consider a standalone Root and
a subordinate Enterprise CA. For the single Enterprise Root CA
scenario, however, the following steps can be taken to provision the CA
server:
1. | Open Server Manager (click Start, All Programs, Administrative Tools, Server Manager).
|
2. | In the Nodes pane, select Roles, and then click the Add Roles link in the tasks pane.
|
3. | On the welcome page, click Next.
|
4. | On the Select Server Roles page, check the box for Active Directory Certificate Services, and then click Next.
|
5. | Review the information about AD CS on the Introduction page, and then click Next to continue.
|
6. | On the Select Role Services page shown in Figure 1, choose which role services are required. A base install needs only the Certificate Authority role. Click Next to continue.
|
7. | Select
whether to install an Enterprise (integrated with AD DS) CA or a
Standalone CA on the subsequent page. In this example, you install a
domain-based Enterprise Root CA. Click Next to continue.
|
8. | On the Specify CA Type page, specify the CA type, as shown in Figure 2. In this case, you install a Root CA on the server. Click Next to continue.
|
9. | On
the following Set Up Private Key page, you can choose whether to create
a new private key from scratch or reuse an existing private key from a
previous CA implementation. In this example, we create a new key. Click Next to continue.
|
10. | On the Configure Cryptography for CA page, enter the private key encryption settings, as shown in Figure 3.
Normally, the defaults are fine, but there might be specific needs to
change the Crypto Service Provider (CSP), key length, or other settings.
Click Next to continue.
|
11. | Choose
a common name to identify the CA. Keep in mind that this name displays
on all certificates the CA issues. For this example, enter the common
name CompanyABC-CorpCA. Click Next to continue.
|
12. | Set
the validity period for the certificate to be installed on this CA
server. If this is a Root CA, the server has to reissue the certificate
chain after the expiration period has expired. In this example, a 5-year
validity period is used, although many production scenarios have a
20-year CA created for the root. Click Next to continue.
|
13. | Specify a location for the certificate database and log locations, and then click Next to continue.
|
14. | Review the installation selections on the confirmation page, as shown in Figure 4, and then click Install.
|
15. | Click Close when the wizard is complete.
|
16. | After
you install AD CS, additional CAs can be installed as subordinate CAs,
and the administration of the PKI can be performed from the CA console
(choose Start, All Programs, Administrative Tools, Certification Authority).
|
