Summary

---

Certificates are used to identify users, computers, and services on the network. A certificate contains the public key and identifying information of the owner plus a digital signature of the certificate authority. There are three types of CAs: the root CA, policy CAs, and issuing CAs. Each of these CA roles can be installed on the same server or different servers. The root CA is the only CA that can assign and sign its own certificate. It is responsible for signing all other certificates in the PKI of the organization. The client trusts the signature of the root CA, which means that it trusts all the certificates issued by subordinate CAs. The policy CA is a subordinate CA that is responsible for approving or denying certificate requests. This can be automated or can be manually performed by a security administrator. The issuing CA is a subordinate CA that is responsible for issuing certificates to the client when the client enrolls or renews a certificate.

You need to decide who in your organization will have control over certificates that are being issued for users, computers, or applications. There may also be legal or company security policy issues that require certificates to be handled in differing fashions. You can choose from essentially four different designs for a certificate hierarchy: function, organization, department, or geography.

When you install a CA, you can decide to install it as a stand-alone CA or enterprise CA. The stand-alone CA does not integrate with Active Directory and therefore does not support integration with Group Policy to configure clients for certificates. A stand-alone server also does not use a certificate template, which means that the client will need to supply all the information necessary for a certificate. The enterprise CA is integrated with Active Directory and supports using Group Policy and certificate templates to deliver certificates to the clients. Stand-alone and enterprise CAs also differ in the means you can use to enroll and renew certificates.

You can enroll or renew certificates through a web interface, autoenrollment, the Certificate Request Wizard in the Certificates MMC, through the command line, or through script with certreq.exe. A stand-alone CA supports web-based enrollment only. The enterprise CA supports web-based enrollment, autoenrollment, and Certificate Request Wizard through certreq.exe. There are operating system limitations for using autoenrollment and the Certificate Request Wizard. Autoenrollment is only supported on the Windows Server 2003 and Windows XP operating systems for user and computer certificates (you can autoenroll computer certificate in Windows 2000). After you issue a certificate, you may need to revoke it at a later date.

You can revoke a certificate that has been issued by your CA hierarchy. When you revoke a certificate, you publish it to the certificate revocation list (CRL). The CRL is a certificate that clients can request to find out if a certificate that they are presented with is valid. The CRL will notify users or applications if a certificate is no longer valid. You will need to make sure the clients can request the CRL, which means that if you have clients that will access certificates over the Internet, they will need to be able to communicate with at least one CA to obtain the CRL.

You will also need to secure your CA infrastructure so that you and your clients can trust certificates in your organization. You must keep your root CA secure because if it is compromised, all other certificates in the PKI of your organization will be compromised. You should install the root CA on a stand-alone CA and keep it offline, off the network, and in a secure location. You would use subordinate CAs to issue certificates to other CAs and clients. You will also need to protect the private keys that are generated for the certificates. You can protect the keys by using a cryptographic service provider (CSP). There are three types of CSPs: software CSPs, hardware CSPs, and smart cards. These will provide a mechanism to securely store private keys for private keys. The mechanism that you choose will affect the lifetime that you choose for the public/private key pair. Hardware CSPs tend to be more difficult to crack than a software CSP, so you can have longer key lifetimes. This is generally because the hardware CSP keeps the keys out of memory so they are not accessible in dump files or on the hard drive.

No matter how much security you provide, you can never assume that your security precautions will not be broken. You will need to set up auditing on the servers to detect changes on the server as well as who did what. Auditing will provide information that can be vital in a legal case against the cracker and in determining what resources have been compromised.

---