Windows Server 2008 - Certificate Key Recovery

Key recovery is compatible with the CryptoAPI architecture of Windows 2008, but it is not a necessary requirement. For key recovery, an entity’s private key must be stored permanently. The storage of private keys guarantees that critical information will always be accessible, even if the information should get corrupted or deleted. On the other hand, there is a security issue in the backup of the private keys. The archived private key should be used to impersonate the private key owner only if corruption occurs on your system.



Backup and Restore
Microsoft recommends that you back up your entire CA server. By backing up the system state data on your CA, you will automatically get a backup of the certificate store, the registry, system files, and Active Directory (if your CA is a domain controller). Sometimes, you may want to just back up the certificate services portion of your computer without doing a full backup of everything else. Your backups are only useful if you can restore them.



Assigning Roles
In a small network of one or two servers and just a handful of clients, administration is generally not a difficult task. When the size of the network increases, however, the complexity of administration seems to increase exponentially. Microsoft’s recommendations for a large network include dividing administrative tasks among the different administrative personnel. One administrator may be in charge of backups and restores, whereas another administrator may have complete control over a certain domain and so on. The role of each administrator is defined by the tasks that he or she is assigned to, and individual permissions are granted based on those tasks. PKI administration, which can be as daunting as general network administration, can be similarly divided. Microsoft defines five different roles that can be used within a PKI to facilitate administration:

• CA Administrator
• Certificate Manager
• Backup Operator
• Auditor
• Enrollee

At the top of the hierarchy is the CA administrator. The role is defined by the Manage CA permission and has the authority to assign other CA roles and to renew the CA’s certificate. Underneath the CA administrator is the certificate manager. The certificate manager role is defined by the Issue and Manage Certificates permission and has the authority to approve enrollment and revocation requests.

The Backup Operator and the Auditor roles are actually operating system roles, and not CA specific. The Backup Operator has the authority to backup the CA and the Auditor has the authority to configure and view audit logs of the CA. The fina role is that of the Enrollees. All authenticated users are placed in this role, and are able to request certificates from the CA.



Enrollments
In order for a PKI client to use a certificate, two basic things must happen. First, a CA has to make the certificate available and second, the client has to request the certificate. Only after these first steps can the CA issue the certificate or deny the request. Making the certificate available is done through the use of certificate templates and is a topic that we discuss in detail below.

Like Windows Server 2003, Windows Server 2008 PKI also supports autoenrollment for user certificates as well as for computer certificates. The request and issuance of these certificates may proceed without user intervention. Group policies are used in Active Directory to configure autoenrollment. In Computer Configuration | Windows Settings | Security Settings | Public Key Policies, there is a group policy entitled Automatic Certificate Request Settings. The Property sheet for this policy allows you to choose to either Enroll certificates automatically or not. Also, you will need to ensure that Enroll subject without requiring any user input option is selected on the Request Handling tab of the certificate template Property sheet. Finally, be aware that doing either of the following will cause autoenrollment to fail:

• Setting the This number of authorized signatures option on the
Issuance Requirements tab to higher than one.

• Selecting the Supply in the request option on the Subject Name tab.



Revocation
A CA’s primary duty is to issue certificates, either to subordinate CAs, or to PKI clients. However, each CA also has the ability to revoke those certificates when necessary. Certificates are revoked when the information contained in the certificate is no longer considered valid or trusted. This can happen when a company changes ISPs (Internet Service Providers), moves to a new physical address or when the contact listed on the certificate has changed. Essentially, a certificate should be revoked whenever there is a change that makes the certificate’s information “stale” and no longer reliable from that point forward.

In addition to the changes in circumstance that can cause a certification revocation, certain owners may have their certificate revoked upon terminating employment.
The most important reason to revoke a certificate is if the private key as been compromised in any way. If a key has been compromised, it should be revoked immediately.

Along with notifying the CA of the need to revoke a certificate, it is equally important to notify all certificate users of the date that the certificate will no longer be valid. After notifying users and the CA, the CA is responsible for changing the status of the certificate and notifying users that it has been revoked.

When a certificate revocation request is sent to a CA, the CA must be able to authenticate the request with the certificate owner. Once the CA has authenticated the request, the certificate is revoked and notification is sent out. CAs are not the only ones who can revoke a certificate. A PKI administrator can revoke a certificate, but without authenticating the request with the certificate owner. This allows for the revocation of certificates in cases where the owner is no longer accessible or available as in the case of termination.

The X.509 standard requires that CA’s publish certificate revocation lists (CRLs). In their simplest form, a CRL is a published form listing the revocation status of certification that the CA manages. There are several forms that revocation lists may take, but the two most noteworthy are simple CRLs and delta CRLs.

A simple CRL is a container that holds a list of revoked certificates with the name of the CA, the time the CRL was published, and when the next CRL will be published. It is a single file that continues to grow over time. The fact that only information about the certificates is included and not the certificate itself helps to manage the size of a simple CRL.

Delta CRLs can handle the issues that simple CRLs cannot- size and distribution. While simple CRLs contain only certain information about a revoked certificate, it can still become a large file. How, then, do you continually distribute a large file to all parties that need to see the CRL? The solution is in Delta CRLs. In an environment leveraging delta CRLs, a base CRL is sent to all end parties to initialize their copies of the CRL. Afterwards, updates know as deltas are sent out on a periodic basis to inform the end parties of any changes.

In practice within Windows Server 2008, the tool that the CA uses for revocation is the certificate revocation list, or CRL. The act of revoking a certificate is simple: from the Certification Authority console, simply highlight the Issued Certificates container, right-click the certificate and choose All | Revoke Certificate. The certificate will then be located in the Revoked Certificates container.

When a PKI entity verifies a certificate’s validity, that entity checks the CRL before giving approval. The question is: how does a client know where to check for the list? The answer is the CDPs, or CRL Distribution Points. CDPs are locations on the network to which a CA publishes the CRL; in the case of an enterprise CA under Windows Server 2008, Active Directory holds the CRL, and for a stand-alone, the CRL is located in the certsrv\ certenroll directory. Each certificate has a location listed for the CDP, and when the client views the certificate, it then understands where to go for the latest CRL.

In order for a CA to publish a CRL, use the Certificate Authority console to right-click the Revoked Certificates container and choose All Tasks | Publish. From there, you can choose to publish either a complete CRL, or a Delta CRL. Whether you select a New CRL or a Delta CRL, you are next prompted to enter a publication interval (the most frequent intervals chosen are one week for full CRLs and one day for Delta CRLs). Clients cache the CRL for this period of time, and then check the CDP again when the period expires. If an updated CDP does not exist or cannot be located, the client automatically assumes that all certificates are invalid.

Source of Information : Syngress The Best Damn Windows Server 2008 Book Period 2nd Edition