- Microsoft Pki Infrastructure
- Pki Microsoft Documents
- Microsoft Pki 2008
- Microsoft Pki Design Software
- Microsoft Pki Design Center
News and information for public key infrastructure (PKI) and Active Directory Certificate Services (AD CS) professionals Design Considerations before Building a Two Tier PKI Infrastructure Amerk MSFT June 19, 2010 7.
-->Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012
Certificate hierarchy planning is one of the most important aspects of PKI design because the design will affect how certificates are validated and used by PKI-enabled solutions. This section introduces a number of recommendations for designing a certificate hierarchy that can be used to meet today’s pressing business needs as well as future needs that may not yet be identified.
A PKI can be implemented either as part of the IT infrastructure or by using external, commercial CAs. In general, the following are the PKI design options:
- Implement a completely self-managed PKI within your organization that contains internal CAs chained to an internal root CA at the top of the chain
- Purchase a CA certificate from a commercial CA and issue certificates within the organization from internal, self-managed CAs that are chained to the external root CA
- Purchase certificates from a commercial CA that are chained to a public root CA (preferably a member of the Microsoft Root Certificate Program that are automatically distributed to clients that use Microsoft Windows® platforms)
If the security solutions supported by the PKI do not require external parties to trust the issued certificates, and will not in the future, then you may opt for a self-managed PKI that uses an internal root CA as the trust anchor for the PKI. Using an internal root CA allows you to maintain direct control over its security policies and to align its Certificate Policy (CP) with the overall security policy. Therefore, you will use internal CAs for issuing certificates to end users, to computers, and to services. These internal CAs can be expanded to include additional functionality, such as support for new certificate types, at a lower cost than buying external certificates.
CA Hierarchy Options
In a hierarchical PKI (a typical deployment), there are generally three types of hierarchies – one tier, two-tier, and three-tier.
Single/One-Tier Hierarchy
- One-Tier Hierarchy – Consists of one single CA. The single CA is both a root CA and an issuing CA. A root CA is the trust anchor of the PKI, so a root CA public key serves as the beginning of trust paths for a security domain. Any applications, users, or computers that trust the root CA also trust any certificates issued by the CA hierarchy. The issuing CA is a CA that issues certificates to end entities.This one-tier hierarchy is not recommended for any production scenario because with this hierarchy, a compromise of this single CA equates to a compromise of the entire PKI. For security reasons, root and issuing CAs are normally separated because it is generally very difficult to quickly distribute a new root CA certificate to replace a compromised CA. This is especially true when the environment includes computers not joined to management domain or devices where a special process is required to provision the root CA certificate. Because of this, a one-tier hierarchy may be sufficient for only simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility.A common finding in PKI assessments is that some organizations install a single CA in order to support a major project that may have required it. Perhaps this is an installation of System Center Configuration Manager, or wireless network protection, or some other PKI-consuming technology and one small line-item in the project’s plan is dedicated to the CA installation. Over time, this single CA begins to get a lot of use as it is leveraged more and more for purposes other than those originally conceived. Suddenly, there is a need for a proper PKI and administrators face some uneasy questions:
- Can I install multiple PKIs in my forest without them interfering with each other?
- How do I set up my new PKI properly so that it is scalable and manageable?
- How do I get rid of my old CA without causing an interruption in my business?
- Is the configuration of this CA posing a security risk to the enterprise?
So there are multiple security risks in using a one-tier hierarchy – your only CA is online and more susceptible to compromise, and you cannot revoke this CA if it was compromised. This hierarchy is also more difficult to expand to support other scenarios. If you are in the position to move to the recommended CA hierarchy design, refer to the Moving Your Organization from a Single Microsoft CA to a Microsoft Recommended PKI article.
Three-Tier Hierarchy
- Three-Tier Hierarchy – In a three-tier hierarchy, there is a root CA tier (offline), an issuing CAs tier (usually online), and an intermediate tier placed between them. The placement of this intermediate CA can be for several different reasons. The first reason would be to use the second tier CA as a policy CA. For example, one policy CA will issue certificates that requires that a user has to appear in person and another CA will issue certificates to any authenticated corporate users. In other words, the policy CA is configured to issue certificates to the Issuing CA that is restricted in the type of certificates it issues. The policy CA can also just be used as an administrative boundary. That is, you only issue certain certificates from subordinates of the policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative and not technical perspective.Another reason to have the second tier added is that if you need to revoke a number of CAs due to a key compromise, you can perform it at the second tier level, leaving other branches available. It should be noted that second tier CAs in this hierarchy should, like the root, be kept offline.Following the paradigm, security increases with the addition of a tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage and cost goes up.Note that performance of certificate chain building on PKI solution clients is affected with an increase in the number of tiers because three-tier hierarchy clients need to verify certificate and certificate status information for both issuing CAs and policy CAs. Another consideration is policy or administrative boundary requirements because a three-tier hierarchy will increase operational costs. Also note that if you are not going to implement policy or administrative boundaries, then the middle tier will be unused and is unneeded. Because of this, three-tier CA hierarchies are usually not recommended (with the exception of a few unique cases). In fact, Microsoft IT changed its design to a two-tier CA hierarchy for its internal PKI. Refer to Deploying and Managing PKI inside Microsoft for more information.
Two-Tier Hierarchy
- Two-Tier Hierarchy – A two-tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the one and three-tier hierarchies. In this design there is a root CA that is offline and a subordinate issuing CA that is online. The level of security is increased because the root CA and issuing CA roles are separated. But more importantly the root CA is offline so the private key of the root CA is better protected from compromise. The two-tier hierarchy also increases scalability and flexibility due to the fact that there can be multiple issuing CAs subordinate to the root CA. This allows CAs to exist in different geographical locations, as well as with different security levels. Manageability is increased since the root CA has to be brought online to sign CRLs. Capital cost is increased marginally because all you need is an additional server or a virtual machine. The two-tier hierarchy is the recommended design for most PKI solutions.Another advisable idea is to restrict certificates of the subordinate issuing CAs to limit their impact on the CA hierarchy, so that subordinate CAs cannot issue “rogue” certificates that could be used for unintended purposes. This is important when you have more complex certificate hierarchies. The most obvious case occurs when an issuing CA is operated by different parts of an organization, but even for internal issuing CAs, it may make sense to restrict the scope of issued certificates. You want to limit certificates issued for a specific scenario (for example, server authentication) so one CA does not affect others (for example, issuing certificates for smartcards) in case of security breach. The best way to accomplish this task is to implement path length constraint and limit Extended Key Usages (EKUs) for the issuing CA’s certificate as described in the Securing PKI: Planning Certificate Algorithms and Usages section. Please note that there are many shared elements of multiple enterprise subordinate CAs in Active Directory® environment (for example, certificate templates), so this restriction should not be the only mitigation.
Conclusion
For a complete list of the recommendations for planning a CA hierarchy, along with the level of business impact at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.
See Also
The series:
Chris here again. This is part of a five part series. In Part I, I will cover design considerations, and planning for deploying a PKI. When implementing a PKI planning is the most important phase, and you can prevent a lot of issues by properly planning your PKI implementation.
I recommend reading the following MSPress books on PKI and Certificate Services before implementing a Windows PKI, or any PKI for that matter. Both books are written by Brian Komar.
Here is a link to the Windows 2003 Book: http://www.microsoft.com/learning/en/us/Books/6745.aspx
And a link to the Windows 2008 Book: http://www.microsoft.com/learning/en/us/books/9549.aspx
They are both excellent resources for anyone implementing, managing, or designing solution that use a Microsoft PKI. And both books go into far more detail then I can here.
Why Deploy a PKI?
There are a host of reasons to deploy a PKI; a few are listed here:
- Control access to the network with 802.1x authentication
- Approve and authorize applications with Code Signing
- Protect user data with EFS
- Secure network traffic IPSec
- Protect LDAP-based directory queries Secure LDAP
- Implement two-factor authentication with Smart Cards
- Protect traffic to internal web-sites with SSL
- Implement Secure Email
In addition a number of applications can use certificates in some fashion. Here is a brief list:
- Active Directory
- Exchange
- IIS
- Internet Security & Acceleration Server
- Office Communications Server
- Outlook
- System Center Configuration Manager
- Windows Server Update Services
Another thing to consider is what future applications you may need to support with your PKI. This may not be an answerable question, nor should you be expected to know for sure. In fact some of the applications or technologies that your PKI may be required to support may not have even been conceived of yet. My point here is that your design should incorporate plenty of flexibility. Not only do you want to deploy a PKI solution that supports existing technologies, but one that is scalable, and can support future technologies.
Costs
The next thing you want to think about is cost. I understand how difficult it can be to get budgets approved in any business. Despite our wishes as technology professionals that we could implement the appropriate solutions, sometimes we are handicapped by the budget that we have to complete a project. How much money is your business willing to invest in the PKI solution? What are the costs for implementing a PKI? Here are some items that may need to be included in your budget:
Hardware Costs
- Servers
- Hardware Security Modules (HSMs)
- Backup Devices
- Backup Media
Software Costs
- Windows Server Licenses
Human Capital
- Paying someone to design, implement, and manage the PKI infrastructure.
Cost Savings
While you are planning your budget, it is important not to forget the cost savings that a Windows PKI solution can provide. The two key areas of savings that I see in a PKI solution are:
Integration
Microsoft CA’s, especially Enterprise CAs, have a tight integration with Microsoft products. The integration makes managing and requesting certificates from Microsoft Operating Systems and applications fairly straight forward, to the point that you do not really need any PKI experience to be able to request a certificate.
Automation
The greatest advantage of the Windows PKI solution is automation. An Enterprise CA is tightly integrated with Active Directory. Using autoenrollment, a simple group policy can be configured to automate the deployment of certificates to computers and users. The deployment is so transparent, that users do not have to do anything to request a certificate.
Manageability
In designing your PKI solution you will have to take into account the resources you have to manage the PKI solution. Day-to-day management for the most part is very limited, but you will need someone to provide the care and feeding of your PKI. You will need someone to issue and revoke certificates. You will need to have someone manage the hardware, apply patches, take backups. In other words, you need a Server Administrator. Also, you will need to have someone that publishes Certificate Revocation Lists and manages the CA itself.
Security
You will need to determine the level of security required for your PKI. In order to determine the level of security it is important to step back and understand what a Public Key Infrastructure and the certificates associated with the Public Key Infrastructure can be used for. Certificates can be used for identification, encryption, non-repudiation, and in some cases authentication. In your organization you probably have some standard on how a user receives a user account. When hired there was some form indicating that he/she needs a domain user account and the manager approves this form; in other words, the manager was assuring the identity of the user. Since certificates can be used for identification the same standard should be used when issuing certificates, if they are going to be used for that purpose. If you are using certificates just for encryption, you may be less concerned with the user’s identity. If using the keys from the certificate for encryption, it would depend on what data is being decrypted. If a user is just encrypting his/her recipes you may perhaps not require the same level of protection of the private keys as you would if the user is encrypting top secret government documents. In other words the level of security is going to be determined by the level of risk. This determination should include any corporate security policies for PKI and certificates. When creating your PKI security policy, you should also consider any industry or government regulations.
Flexibility and Scalability
The flexibility and scalability of your solution should be taken into consideration. If you have a high level of confidence that you will not need to change or adapt your PKI solution you can have a fairly simple design. However, if you need a solution that will need to support a variety of technologies, different levels of security, and a global presence, then your solution can get much more complicated.
Physical Design
When designing your PKI solution you will have to determine the hierarchy that you will use. There are generally three types of hierarchies, and they are denoted by the number of tiers.
Single/One Tier Hierarchy Opera download win 8.1.
A single tier Hierarchy consists of one CA. The single CA is both a Root CA and an Issuing CA. A Root CA is the term for the trust anchor of the PKI. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. The Issuing CA is a CA that issues certificates to end entities. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility. The level of security can be enhanced if the CA’s keys are protected by an HSM, but at the expense of higher equipment and management costs.
Two Tier Hierarchy
A two tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the One and Three Tier hierarchies. In this design there is a Root CA that is offline, and a subordinate issuing CA that is online. The level of security is increased because the Root CA and Issuing CA roles are separated. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise. It also increases scalability and flexibility. This is due to the fact that there can be multiple Issuing CA’s that are subordinate to the Root CA. This allows you to have CA’s in different geographical location, as well as with different security levels. Manageability is slightly increased since the Root CA has to be brought online to sign CRL’s. Cost is increased marginally. I say marginally, because all you need is a hard drive and Windows OS license to implement an Offline Root. Install the hard drive, install your OS, build your PKI hierarchy, and then remove the hard drive and store it in a safe. The hard drive can be attached to existing hardware when CRLs need to be re-signed. A virtual machine could be used as the Root CA, although you would still want to store it on a separate hard drive that can be stored in a safe.
Three Tier Hierarchy
Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA. The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.
The other reason to have the second tier added is so that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.
Following the paradigm, security increases with the addition of a Tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage. And, of course, cost goes up.
Security
Private Key Protection
One of the key aspects of designing a PKI solution is to make sure the proper controls are in place. Security for a PKI solution mostly revolves around protecting the private key pair of the CA. Each CA has a private/public key pair. The private key is used to sign CRL’s as well as certificates that are issued by the CA. Clients and application verify the signature so that they can be assured that a certificate was issued by a particular CA. If you install a Microsoft CA, the private key is protected by software, or more specifically the Data Protection API (DPAPI). Although this method does provide protection it does not prevent a user that is a member of the Administrators group on the CA from accessing the private key. This can be a cause for concern, because you may have administrators whose job is just to patch the system, and yet they have access to the private key which violates the concept of least privilege.
There are generally two methods for protecting the private key of a CA. The first method is to keep the CA offline and the hard drive stored in a safe. By controlling the conditions the hard drive can be used, the opportunities for key compromise are reduced. The second method is to use a hardware device to protect the private key. For example, a smartcard can be used to store the private key of the CA. This is not the best solution since the smart card must remain in the reader attached to the CA in order to be used. Also, a smart card may not be as resilient, or provide the level of security that is required. It is however a low cost solution. A more standard solution is to use a Hardware Security Module (HSM). HSM’s are fairly expensive, but are normally certified for FIPS compliance — a standardized measure of relative security. HSM’s are accepted as the most secure way to protect the private key for a CA.
Role Separation
Aside from private key protection you will most likely want to have some control as to the level of administrative access to a CA. In some cases you may have administrators that are responsible for performing every function on the CA. But in larger or higher security environments you will want to have some granular control over what access different role holders have. Below is a list of common roles on a CA:
- CA or PKI Administrator whose role is to manage the CA itself.
- Certificate Manager who issues and revokes certificates.
- Enrollment Agent is typically a role used in conjunction with smart cards; an Enrollment Agent enrolls for a certificate on behalf of another user.
- Key Recovery Manager if using key archival. If you are using key archival, the Key Recovery Manager is responsible for recovering private keys. Also, if you are using EFS an EFS Recovery Agent role may be created to recover data encrypted using EFS.
In addition to these roles that have direct interaction with the CA, you also will have ancillary roles that support the CA. These include:
- Backup Operator who is responsible for backing up the CA and restoring data in case of failure.
- Auditor who is responsible for reviewing audit logs and ensuring policy is not being violated.
Physical Security
Certificates issued by CAs are used in many cases for very sensitive operations such as establishment of identity, authentication and encryption. As such, it is important to not only protect the private key but to protect physical access. Law #3 of the Ten Immutable Laws of Security, states: “If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.” For this reason you will want to protect physical access to the CAs. This will depend on the resources you have available, but typically in larger organizations the CAs are stored in a locked cage in a data center. Only individuals that need physical access to the CA to perform their duties should be given access.
Policy
Generally the security requirements, such as those mentioned above, are dictated by a corporate security policy. A security policy usually takes into consideration regulatory and industry requirements as well as unique requirements for the individual company. The policy may also specify technical aspects of the PKI such as the encryption algorithms that must be used as well as operation of the Certificate Authorities.
In addition to security policies there may be CA-specific policies that need to be developed before implementing the PKI. These include Certificate Policy and Certification Practice Statement. The Certificate Policy explains what methods are used to establish the identity of a subject before issuing a certificate. A Certification Practice Statement outlines the operation of the PKI from a security perspective. Many companies, especially third parties companies that issue certificates, have their Certificate Policies and Certification Practice Statements available publicly. It may be helpful to view one of these public documents when writing your own policy documents.
Additional Security Considerations
In addition to the topics discussed it is important to apply any relevant security patches to your online CAs and to install them in a timely manner. In addition to patches, you should have an anti-malware solution installed on your CA.
So far we have covered reasons to deploy a Public Key Infrastructure. We also have covered the various costs involved in a PKI infrastructure, as well as the impact of various design considerations. Now we will dive a little deeper into specific configuration decisions and technical aspects of the Certificate Authorities.
CA Configuration
Certificate Validity Period
Digital certificates have a lifetime, a start date and an end date for which they are considered valid. You should determine what values for this lifetime are appropriate for each CA certificate and end-entity certificate issued by your CA’s. For CA’s, this lifetime is set when the CA is installed and when the private key is renewed. For end-entity certificates there are a number of factors taken into account:
- These include the validity period for the issuing CA. The CA will not issue certificates that are valid past the CA’s lifetime.
- The validity period specified in the Certificate Template.
- The value of this registry key, specified in this KB article: http://support.microsoft.com/kb/254632
The certificate issued will be configured with the validity period that is the shortest of these items.
Key Length
The length of a key definitely affects security of information protected with that key. Thus, you will need to determine the key lengths you will use with each key pair. First you will need to determine the key lengths that will be used for each of the CA key pairs. Additionally, you will need to determine the key lengths for any certificates issued by the issuing CA. The key lengths for the CA certificates are determined by the key size requested when the CA is installed and when the key pair is renewed. The key length at installation is set during the CA Setup process. The key length for renewal is determined by a value set in the CAPolicy.inf configuration file installed on the CA.
For certificates issued by the issuing CA the maximum key size is limited by the CSP that is being used. The specific key size that is required can be specified in the certificate request or in the Certificate Template if using an Enterprise CA. As a general guideline, the longer the lifetime of the certificate the longer the key length should be. For applications that will be using certificates you will need to determine the maximum key length they support. Some applications have limitation on the key size not only in the actual certificate it is using, but also for any certificates in the CA hierarchy. From a security standpoint it is recommend that 4096 bit key is used for Certification Authorities key pair. However, if you wanted to insure maximum compatibility with network devices and applications a 2048 bit key would be the better choice.
AIA Locations
When a client or application is validating a certificate it needs to not only validate the certificate that is being used but also the entire chain of the certificate. In other words, the application or client needs a certificate from each CA in the chain beginning with the issuing CA and ending with the Root CA. If the application or client does not have access to the certificates in the chain locally the application or client needs a place from which to obtain the certificates. This location is called the Authority Information Access or AIA. The AIA location is the repository where the CA certificate is stored so that it can be downloaded by clients or applications validating a certificate. The AIA location is included in the AIA extension of a certificate. Before implementing your PKI it is important to think about what types of clients will be validating the certificates and where they reside. If you are using Windows clients that are internal to your network and are domain members then LDAP locations in Active Directory are a good place for clients to access the AIA repository. If you have non-Windows clients or Windows clients that are not domain members that are internal then an internally hosted web site would be the ideal location for the AIA repository. However, if clients may need to validate a certificate when outside the network, then you will need an AIA repository that is available externally, perhaps on the public network.
CDP Locations
A CRL Distribution Point (CDP) is where clients or applications that are validating a certificate download the certificate revocation list (CRL) to obtain revocation status. CA’s periodically publish CRLs to allow clients and applications to determine if a certificate has been revoked. CRLs contain the serial number of the certificate that has been revoked, a timestamp indicating when the certificate was revoked, as well as the reason for revocation. Similar to AIA Locations, you need to keep in mind what types of clients you are supporting and where they are located.
CRL Validity and Overlap Periods
Like certificates, CRLs have a start date and an end date denoting a period for which they are valid. As such, you will need to consider what the CRL lifetime should be for each CA. In general, the CRL lifetime is proportional to the number of certificates the CA is expected to issue. Offline CA’s that issue relatively few certificates, and those only to other CAs, would tend to have CRLs with a more extended lifetime, for example, six months to a year. This reflects the fact that, in a properly managed PKI, an offline CA would rarely revoke a certificate. Issuing CAs, on the other hand, can be expected to issue large numbers of certificates to end-entities. It is quite common to revoke an end-entity certificate for any number of reasons, so the lifetime of an issuing CA’s CRL can be quite short; a few days or even hours.
![Center Center](/uploads/1/2/4/9/124954836/172115384.gif)
Another thing to consider is the overlap period. The overlap period is a short time interval beyond the expiration date of the CRL, and reflects the period between when a new CRL is published, and when the old CRL actually expires. During this time both CRLs are valid. This allows time for the new CRL to replicate to all of the repositories before the old CRL expires.
Delta CRLs
Delta CRLs are CRLs that contain revocation information for certificates that have been revoked since the base CRL was last published. For example, you have a Certificate A and it is revoked. The CA then publishes a new Base CRL that includes the revocation information for Certificate A. Shortly thereafter, Certificate B is revoked. At the designated interval a Delta CRL is published which contains the serial number and reason for revocation for Certificate B. When a client needs to determine revocation status Certificates A or B it downloads both the base CRL and the Delta CRL. The client determines that Certificate A is revoked from the base CRL, and then determines that Certificate B is revoked from the Delta CRL.
The reason for Delta CRLs is due to limitations with base CRLs. Base CRLs can grow rather large over time as they contain the serial number and revocation reason for every valid certificate that has been revoked from a CA. Instead of publishing a large CRL over and over again, revocation status can be updated with the smaller Delta CRL. In this way clients that have a time valid CRL will just need to download the Delta CRL. Like base CRLs you will need to determine how often Delta CRLs are published. It should be noted that the use of Delta CRLs is completely optional and is not normally used with offline CAs for obvious reasons.
OCSP URIs
Windows Vista, Windows 7, Windows 2008 and Windows 2008 R2 can obtain revocation information from an Online Responder via the Online Certificate Status Protocol. If you are using an Online Responder to provide revocation status, you should include the URI that points to the Online Responder.
Microsoft PKI
Other than the benefits of the Windows PKI, most of the things I have mentioned so far apply to any Public Key Infrastructure. I am now going to focus on a Microsoft-specific implementation.
Operating System Version
Currently both Windows 2003 and Windows 2008 are supported so you need to determine which OS you’re going to use for your CAs. In order to make that decision you will need to know what additional features Windows Server 2008 has over Windows Server 2003. Here are a few of the many new features in Windows Server 2008:
- Supports Suite B Cryptographic Algorithms
http://blogs.technet.com/pki/archive/2009/04/15/suite-b-pki-in-windows-server-2008-and-windows-server-2008r2.aspx - New Crypto API called Cryptography Next Generation (CNG)
http://technet.microsoft.com/en-us/library/cc730763.aspx - PKIView is installed with the Certificate Services Role (Really nice when troubleshooting) http://technet.microsoft.com/en-us/library/cc732261.aspx
- Certificate Authorities can be clustered (Active/Passive)
http://technet.microsoft.com/en-us/library/cc742517.aspx - Version 3 Certificate Templates
http://technet.microsoft.com/en-us/library/cc730826.aspx - New Certificate Templates
http://technet.microsoft.com/en-us/library/cc730826.aspx - Network Service permissions can be configured on Version 3 Templates
http://technet.microsoft.com/en-us/library/cc725621.aspx - Here is an article that goes into more detail on new features in Windows 2008 PKI
http://technet.microsoft.com/en-us/magazine/cc137986.aspx
Microsoft Pki Infrastructure
Windows Server 2008 R2
Windows Server 2008 R2 adds a number of new features to Certificate Services. These features include:
- Cross-Forest enrollment– Windows 2008 R2 Supports Cross-Forest enrollment which will allow a CA or multiple CAs in one forest to support clients in multiple Forests.
- Certificate Enrollment Web Service and Policy Service– Allows clients to enroll for certificates over web interfaces. This new capability allows clients to retrieve certificates even if they are not located on the same physical network as Active Directory and the CA. Clients query the Enrollment Policy Service, to determine which Certificates they should enroll for, the Enrollment Policy Service contacts Active Directory and responds to the client with CA and Certificate Template information. The client then queries the Enrollment Web Service, to enroll for certificates. The Enrollment Web Service than contacts the CA on behalf of the client, and returns the enrolled certificates back to the client.
- Non-persistent certificates (not stored in the CA database) – Certificate Templates can be configured to not store certificates in the CA database. The is useful for CAs that issue certificates for network authentication, in which certificates have a lifetime of hours or days and the storage of the certificates in the database would impact CA performance unnecessarily.
Operating System Edition
There are three editions of the OS on which you can install the Certificate Authority role. Those editions are Standard, Enterprise, and Datacenter. Standard or Enterprise Editions are normally used.
Below are the key features that Enterprise and Datacenter Edition supports and Standard Edition does not. It is important to note that Datacenter Edition does not offer any additional functionality in terms of Certificate Services over Enterprise Edition.
- Version 2 Templates
- The ability to duplicate and modify Certificate Templates
- Certificate Autoenrollment (requires version 2 templates)
- Common Criteria Role Separation enforcement
- Key Archival and Retrieval
Pki Microsoft Documents
Certificate Authority Type
Next, you need to consider what type of Windows CA is required. A Standalone CA does not require Active Directory and can be installed on a non-domain member server. Requests for certificate enrollment can be sent through Web Enrollment if installed, or by sending a request file to the CA. The request files are usually generated through the Certreq.exe tool. Also, in Windows Server 2008 and Vista you can use the Certificate Management Console to build custom requests.
An Enterprise CA is integrated with Active Directory and requires AD in order to function. The Enterprise CA supports the same enrollment methods as the Standalone CA. In addition, however, an Enterprise can receive requests submitted through the Certificates MMC console. An Enterprise CA also allows for computer or user Autoenrollment which allows certificate request and issuance to be automated through a Group Policy setting. Enterprise CAs also use certificate templates which allow define what types of certificates a user or computer request from the CA.
Additionally, PKI related configuration information is stored in Active Directory. This makes it easy for applications and clients to locate an issuing CA, associated Certificate Templates, CRL’s and AIA information.
Certificate Templates
![Design Design](/uploads/1/2/4/9/124954836/581671366.jpg)
Certificate Templates allow you to create a template from which the values in the certificate request are generated. When a user requests a certificate based on a Certificate Template, the request generated by the client is built based upon the configuration of the template. Certificate templates are key to Autoenrollment, since Autoenrollment requires certificate templates. The importance of certificate templates is that it reduces management cost, and makes the CA easier to use. This is due to the fact that the user does not have to use complicated methods such as using certreq.exe and the associated configuration file to generate requests. Certificate Templates are stored in Active Directory and replicated to all domain controllers in the forest. This makes them highly available in order to support all clients in the forest.
For more information about Certificate Templates, please visit the following URLs:
- Certificate Templates Overview: http://technet.microsoft.com/en-us/library/cc730826.aspx
- Implementing and Administering Certificate Templates in Windows Server 2003: http://technet.microsoft.com/en-us/library/cc755996.aspx
- Certificate Templates: http://technet.microsoft.com/en-us/library/cc758496.aspx
Enrollment
Another important aspect to consider is how clients will enroll for certificates. There are several methods to enroll for certificates and the actual method you choose may vary. But for the majority of customers most enrollments will be done through Autoenrollment. For one off situations and testing enrollment, manual enrollment or Web Enrollment will typically be used. Beginning with Windows 2008 there is Network Device Enrollment Service that can be used for network devices to enroll.
Autoenrollment
Autoenrollment adds a high level of automation to certificate issuance. In order to deploy Autoenrollment, you must first configure a certificate template from which clients will generate their requests. You then need to enable a Group Policy setting that enables Autoenrollment. Once you enable autoenrollment the computer or user, depending on what template is configured will automatically request a certificate based on the template after Group Policy refreshes.
For more information about Autoenrollment, please visit the following URLs:
- How Autoenrollment Works: http://technet.microsoft.com/en-us/library/cc787781.aspx
- Configure Autoenrollment in Group Policy: http://technet.microsoft.com/en-us/library/cc771025.aspx
- Troubleshooting: http://technet.microsoft.com/en-us/library/cc755801.aspx
Manual Enrollment
There are several different methods for manual enrollment. The first method is to use the Certificates Management Console to enroll for certificates directly. The second method is to use the Certificate Management Console to generate a request file that can later be submitted to the Certification Authority. Third, a tool called certreq.exe can be used to create requests that can later be submitted to the CA. Certreq.exe can also be used to submit the request to the CA and also to download, and install the resulting certificate.
Web Enrollment
Web Enrollment is a web page that can be used to submit requests and download issued certificates from a CA. Web enrollment has typically been used to generate custom requests. However, with the ability to create custom requests in Windows Vista and Windows 2008 there is less of a need to use Web Enrollment
Application Specific Enrollment
Many Microsoft applications, such as Internet Information Services and Office Communication Server have built in wizards that assist with enrolling for certificates that are used by those applications.
Network Device Enrollment Service (NDES)
NDES is a role that uses the SCEP protocol to allow network devices to enroll for certificates.
Additional Considerations
Key Archival and Retrieval
Key Archival is a feature that allows the CA to archive the private key associated with a certificate in its database. A Key Recovery Manager can than recover the private key for a certificate if required. Although separate from Key Archival, an EFS Recovery Agent can be configured to recover EFS encrypted files.
For more information about Key Archival and Retrieval, please visit the following URLs:
- Key Archival and Management in Windows Server 2003: http://technet.microsoft.com/en-us/library/cc755395.aspx
- Implementing Key Archival Walkthrough: http://technet.microsoft.com/en-us/library/cc738977.aspx
- Troubleshooting: http://technet.microsoft.com/en-us/library/cc787039.aspx
Active Directory and Group Policy
Microsoft Pki 2008
Aside from Autoenrollment, Active Directory and Group Policy allow the configuration of PKI related settings for clients. This includes EFS-related configuration, automatically publishing Root CA certificates to the Trusted Root Certification Store on clients, revocation checking configuration, and more…
For more information about PKI-related Group Policy settings, please visit the following URL:
Configure Public Key Group Policy: http://technet.microsoft.com/en-us/library/cc962057.aspx
Conclusion
Microsoft Pki Design Software
I attempted to cover many aspects of the PKI implementation you will need to consider before deploying a Public Key Infrastructure. There is a great deal of information out there. As I mentioned before I would strongly recommend reading the Brian Komar books. I would also invite you to review PKI related posts on the Ask Directory Services Team Blog:
and the Windows PKI Blog:
As well as the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure, which is located at:
http://www.microsoft.com/downloads/details.aspx?familyid=0BC67F4E-4FCF-4717-89E8-D0EE5E23A242&displaylang=en.
And the Windows Server 2003 PKI Operations Guide that can be downloaded from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8e25369f-bc5a-4083-a42d-436bdb363e7e&DisplayLang=en .
Microsoft Pki Design Center
– Chris “two-fer” Delay