Most organizations must deal with the reality
of security threats both outside and within their company. To help
provide a higher level of security, many companies have started
deploying their own internal public key infrastructure (PKI). PKIs
allow you to deploy certificates to users, computers, network devices,
and applications. These certificates can then be used to encrypt data
and verify the identity of network objects. The most common form of PKI
you are probably familiar with is Secure Sockets Layer (SSL)-based Web
sites. Typically when you place an order from a well-known shopping
site, you will be connected via a secure session using SSL based upon
PKI technologies. Several Microsoft products themselves are starting to
rely on PKI to function properly or provide enhanced feature sets. Both
Exchange Server and Office Communications server rely on certificates
as part of their core functionality. Active Directory Certificate
Services is a Windows solution for deploying a PKI on your network.
Active Directory Certificate Services requires adequate planning to
ensure that the core PKI is secure and well managed.
1. Planning for Active Directory Certificate Services
Microsoft continues to evolve its core PKI
solution with each release of Windows Server to allow organizations of
all sizes to deploy their own internal certificate services providing
support for secure Web sites, smartcard logons, and encrypted data
transfers between servers. Though deploying an Active Directory
Certificate Services-based PKI is somewhat easy to set up, adequate
planning still needs to take place prior to setting up your own
deployment. Before you create a deployment plan, you should have a good
understanding of a few basic certificate services concepts. Some of
these key concepts are defined below:
-
Certificate—Certificates
are at the core of a PKI deployment. Certificates are used to encrypt
and decrypt data, verify the identity of the source, and ensure that
the data was not tampered with while moving from point A to point B.
Certificates are issued to users, computers, or network devices by
Certificate Authorities (CAs). CAs not only issue certificates but
manage their lifecycle, including the renewal process, as each
certificate has a defined expiration date and must be renewed to
continue to function properly. Figure 1 shows an example of a certificate used to secure an IIS Web site allowing for https-based, SSL-based connections.
-
Root certificate authority—In
most PKI deployments, the root certificate authority (CA) is the first
CA in a multilevel hierarchy. Typically, the Root CA only issues
certificates for intermediate CAs or issuing and policy CAs depending
on the number of levels in the hierarchy. Root CAs are typically taken
offline after the subordinate CAs have been set up.
-
Intermediate certificate authority—Intermediate
CAs are typically used in larger multilevel deployments with more than
two levels in the hierarchy. Intermediate CAs are a subordinate CA of
the Root CA and issues certificates used to set up issuing and policy
CAs.
-
Policy certificate authority—Policy CAs are used to enforce security policies for deploying certificates as defined by the organization.
-
Issuing certificate authority—Issuing
CAs are the actual CAs used to issue certificates to computers, users,
and network devices. The issuing CAs are usually subordinate of
intermediate or policy CAs.
-
Enterprise certificate authority—An
enterprise CA integrates with AD and uses AD to store CA configuration
data. The use of AD implies that to deploy an enterprise CA, the CA
must be a member of an AD domain. Additionally, certificates are
automatically issued when a user or computer requesting a certificate
has permissions to issue new certificates.
-
Stand-alone certificate authority—A
stand-alone certificate authority does not integrate with AD and uses
flat files to store configuration information. A stand-alone CA does
not require AD and can be deployed in environments with or without an
AD domain. Any certificate requested must be manually issued using the
certificate management console. A stand-alone CA is often used as a
Root CA as it can be easily taken offline without worrying about domain
membership issues or the need to talk to AD.
-
Certificate revocation lists (CRLs) and online certificate status protocol (OCSP)—CRLs
and the OCSP are the methods used to determine if a certificate has
been revoked by a CA. A certificate administrator may need to revoke a
certificate if a system is no longer in use or if the certificate has
been compromised. CRLs or OSCP are used to inform connecting clients or
servers that a certificate has been revoked. OSCP was first introduced
in Windows Server 2008 R1 (RTM) as an alternate method to determine if
a certificate has been revoked. The use of CRLs require that the CA
generate a new CRL list and clients to download the CRL list from a CRL
distribution point on a regular basis. Using OSCP is more of a
real-time request for the revoke list as the client requests the list
from a CA.
When planning your PKI deployment, you
will need to consider various decision points during the design
process. For example, will the PKI be supporting multiple domains or a
single domain?. You will also need to know what type of hierarchy to
deploy and the number of levels to include. Additionally, you will need
to ensure that your Active Directory Schema is updated to the Windows
Server 2008 schema level to support the new features in Windows Server
2008 R2 Active Directory Certificate Services.
Planning your Certificate Authority hierarchy
As a best practice, larger organizations will
want to deploy multiple levels of CAs for manageability and security
purposes. Additionally, the Root CA is typically used to create
intermediate CAs and is then taken offline for security purposes. Figure 2
depicts a two-level hierarchy. The Root CA that is used strictly for
creating a second CA acts as a policy-and certificate-issuing CA.
Planning for Certificate Revocation List distribution points
As part of your design, you need to properly
plan for CRL distribution points. By default, each Enterprise CA will
publish the CRL to AD and inform clients that the CRL can be accessed
using an LDAP URL. The disadvantage of using the default is that as the
CRL is published to AD, it must be replicated to all DCs in the domain
before you can be sure that all clients can see the updated CRL. As you
are aware, AD replication happens on a scheduled basis thus, it could
take some time for CRL changes to fully replicate throughout your
network. If you need CRL changes to be available sooner, you can create
http-based distribution points which can be managed by the CA. If CRL
changes are infrequent on your network, you may be ok with using the
default LDAP URL.
Other planning decisions you need to consider are:
-
Will clients outside the corporate firewall
need to use internal PKI protected systems? If so, the certificate
chain must be viewable from the outside world.
-
Who will manage the PKI? There are special
security groups created within AD for Enterprise CA deployments. Some
organizations may leave the administration to the AD admins, while
others may have dedicated security departments that manage the PKI.
-
You will want to monitor your PKI to ensure
that it remains healthy. This can be accomplished by reviewing the logs
on a regular basis. Additionally, there is a System Center Operations
Manager (SCOM) 2007 R2 Management Pack available to allow SCOM to
monitor your PKI deployment.
Be sure you spend ample time planning
and testing your design in a lab before implementing a PKI on your
production network. A simple PKI can be somewhat easy to implement but
a bad deployment could cause major headaches and possible security
issues.
