Active Directory considerations
In the test network, we will implement a "two-tier" enterprise PKI with two levels of "certificate authority" (CA) servers. This type of PKI requires Active Directory.
Note: such a topology is in contrast with a "stand-alone" CA, comprised of a single server, which can function without Active Directory. More details are below in the section "Number of tiers".
We will use what is perhaps the most common Active Directory topology: a single forest with a single domain.
All our domain controllers run Windows 2008 R2 and we have a Windows 2008 R2 level schema.
Domain and forest functional level (DFL and FFL) are at Windows 2008 R2.
We will implement a PKI based on Windows 2008 R2 servers.
Note: other Active Directory topologies, schemas, domain and forest levels may vary. It is not my objective to examine all possible scenarios in which one might want to implement PKI. If your network is different in those respects, I would invite you to consult other resources on the subject, such as the references cited at the end of this post.
It is best practice to install the certificate authority role on servers that are not domain controllers and that do not hold any other roles. Other scenarios are possible and even supported but can complicate management.
Naming conventions
This is extremely important because we cannot rename CAs.
Besides the name of the CAs, we may want to name security groups, Organizational Units and GPOs related to the PKI, with a name that reflects this relationship.
For example:
- PKI-Root-CA for the offline root CA (there is only one)
- PKI-Sub-CA-1 for the first subordinate CA (it could also be designated as a policy or issuing CA).
- PKI-Servers = OU for servers with a PKI role.
- PKI-Admins = security group for PKI administrators
Number of tiers (or levels)
A PKI topology can consist of a single server or include many servers organized in a multi-level (or tier) hierarchy.
A single certificate authority (CA) is rather simple to install and may be perfect for a small organization that wants to use certificates for a particular purpose but cannot justify the cost and effort of configuring a more complex topology.
There are disadvantages, however, that may be significant.
First, the server cannot be taken offline (since it must be available to issue certificates and respond to inquiries about certificate validity). But taking a server offline, or rather never placing it online to begin, is the preferred method to secure a root CA and guarantee the integrity of the root certificate.
Second, a single server (this is true in general) cannot provide high availability. This is a more significant limitation than one might think at first glance. If the server is "down", certificates cannot be issued, of course, but worse, the validity of certificates already issued cannot be verified.
In essence, clients to which certificates have been issued, will query the CAs on a regular schedule to discover if any issued certificate has been revoked. This process can be somewhat complex but, in the end, if a certificate server is not available for a certificate revocation check, the issued certificates will stop working (sooner or later). This means that the services using those certificates will also cease functioning. That could be wifi access, encyption and decryption of email, or building entry with a smart card.
*
I will opt for what is known as a "two-tier" hierarchy with a total of two certificate authority servers (CAs): one offline root CA and one subordinate CA. In this case, the subordinate CA will also be an "issuing" CA because it will issue certificates to the various entities (users, computers, network devices) that request them.
Concerning the number of CAs, and their organization, we have to consider factors such as...
- Number of certificates (if many certificates are requested we may need more CAs)
- Availability - having more than one server is crucial here but we also need to consider reliability between sites. We may need a CA per site to ensure availability.
- Management style: if each team or each department intends to manage its own certificates, more CAs may be necessary than in a centralized environment (one team manages the PKI).
- Politics (or regulation). Legislation in the USA may be different than legislation in the EU. Multinational companies may have to consider this element.
In my network, however, two CAs should suffice to explore the aspects of PKI that interest me.
Proper planning also supposes that we answer questions about the following requirements (I will simply summarize, please see sources listed below, and Brian Komar's book in particular, for details):
- Applications. What systems will use the certificates: website authentication? encryption/decryption of email? Code signing? Smart Cards?
- Security. Do we need to place the root CA offline? Should we take additional measures to protect CA private keys? What determines if we approve a certificate request or not?
- Business. What will the PKI cost? To what extent can we minimize cost while providing expected level of service? What is our liability in case of certificate compromission?
- External. If we want to interact with a partner organization or a government, there are other considerations.
- Technical (administration):
- Who will manage the PKI?
- Will there be separation of roles?
- What kind of storage will be use for the CAs?
- What key length will we use (1024, 2048, 4096)? As a general rule, longer key is more secure but requires more computing power. 2048 in currently the recommended minimum.
- What will the validity period of the certificates be?
Some more details on these technical aspects...
Management of the PKI
With Windows 2008 R2 (and previously 2008), the management of the PKI can be separated among four roles:
- CA administrator ("Manage CA permissions") -> this role manages the entire CA.
- Certificate manager ("Issue and manage certificates") -> manages certificates: issuance, revocation, archiving.
- Backup operator -> backup and recovery of CA databases and configuration files.
- Auditor -> review PKI related logs, including Event Viewer.
If only one person manages the PKI, then obviously that person has all these roles.
Validity period of the certificates
A common practice is to start with the preferred lifetime of the issued certificates (5 years, for example), make the certificates of the subordinate CAs twice that duration (so 10 years) and the certificate of the root certificate twice the lifetime of the subordinate certificates (20 years).
***
References:
Windows Server 2008 PKI and Certificate Security, Brian Komar, Microsoft Press, 2008
Text is out of print.
It is possible to obtain a digital copy. See details here:
Komar Consulting
TechNet Security forum
Designing and implementing a PKI - Directory Services Team (Ned Pyle)
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 2: more concepts and description of test network. on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.