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. 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. 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. 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 using the keys from the certificate for encryption, it would depend on what data is being decrypted. 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. 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. 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. A single tier Hierarchy consists of one CA. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy.

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. In some ways it is a compromise between the One and Three Tier hierarchies. 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.

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. The placement of this CA can be for a couple different reasons. 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.

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. One of the key aspects of designing a PKI solution is to make sure the proper controls are in place.

Clients and application verify the signature so that they can be assured that a certificate was issued by a particular CA. 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.

Windows Server TechCenter. Sign in. United States English. Ask a question. Quick access. Search related threads. Remove From My Forums. Showing results for. Show only Search instead for.

Did you mean:. Sign In. Windows PKI documentation reference. Carsten Kinder. Published Jan 24 PM 4, Views. Certificate Creation Tool Makecert. Tags: PKI. Version history. 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. 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:. 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. 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.