| Once your enterprise users have obtained certificates, there are a multitude of uses for them. Applications can use them to prove your identity, send encrypted information, and provide nonrepudiation of data. It is important to note that applications must be written specifically to take advantage of certificate-based security. Users cannot take advantage of all the benefits of certificates without supporting software. Users can, however, manage their certificates and certificate stores. As we'll see in later chapters, very little certificate management is done on the Windows Server 2003 family certification authority. This means that virtually all certificate management happens on or at the request of the user's computer. As we'll see, some of this management is done automatically with no user intervention or knowledge, and some requires user understanding and cooperation. 9.2.1 Distributing Certificates You have already read that certificates have numerous purposes, depending on the applications deployed. Most of those applications require that you have obtained someone else's certificate ”specifically, that of the user or computer you want to securely communicate with. Without that information, you cannot authenticate the recipient and do not have the public key with which to encrypt sensitive data. You must obtain this certificate to proceed with operations that require it. The most basic way to obtain another user's certificate is to ask her to send it to you. Although this is somewhat risky, if you trust her and the threat of bucket brigade attacks is low, it works just fine. This scenario works for any certificate used on Windows 2000, Windows XP, or Windows Server 2003, no matter what type of certification authority issued the certificate (if any). Although some certificates are sometimes specifically restricted in their uses, these restrictions are based on the application that uses them. You must test applications to ensure they support certificates obtained and used in this way. 9.2.1.1 Exporting a certificate without the private key To export a certificate for distribution to other parties or to copy it to multiple computers for distributed use, follow the steps in the later "Archiving a certificate and private key" section to run the Certificate Export Wizard. The only difference is that you must specify that you do not want to export the private key . Distribution of your private key defeats the security provided by PKI-based technology, because as mentioned earlier, the fundamental assumption with public key cryptography is that the private key always remains accessible to exactly one entity. Once the certificate is exported to a file, it can be distributed to anyone you intend to communicate with. This is most often done via email by sending the certificate as an attachment. Other techniques include publishing the certificate on a file share, posting it on a web page, or writing it to a CD-ROM and mailing it. Remember that these certificates are very small so they are easily distributed through virtually any mechanism you can think up. 9.2.1.2 Importing a received certificate Once the intended recipient receives the file, it can be easily imported for use by any application that uses the standard Microsoft certificate stores. To import the received file, you can take the following steps: -
Save the certificate file to the local hard disk or insert a disk that contains the file. -
Use Windows Explorer to locate the file. -
Right-click the file and then click Install Certificate. The Certificate Import Wizard will start. -
Select "Automatically select the certificate store based on the type of certificate" to allow the wizard to determine the correct store based on an analysis of the certificate. This ensures that certificates for CAs and subjects are kept in their proper places and are easily located by applications and the user. -
Click Next and then click Finish to import the certificate to the appropriate store. Once the certificate is imported, the file can be discarded. It contains no sensitive information, so no extensive care is required for its container or transportation. 9.2.1.3 Importing a certificate revocation list As mentioned earlier in this section, some applications behave differently, depending on the certificate issuance and the validation the application performs . Many newer applications require a check of the certificate's revocation status to ensure it has not been compromised. This is done in Windows by retrieving the certificate revocation list (CRL) for the CA that issued the certificate. I'll discuss certificate revocation and the CRL later in this chapter. If the computer that imports the certificate cannot retrieve the CRL from its public location, it will fail its revocation check and the certificate may not be usable. This happens most often with computers that are in an offline state, such as laptops or remote office computers. In this case, the CRL can be exported and imported in essentially the same way the certificate was exported and imported in the previous examples. The only difference is that the file is a CRL file instead of a certificate (CER) or PKCS #7 (P7B) file. The CRL is also normally a very small file, similar or slightly larger than the certificate export file. As a reminder, not all applications require a CRL to use the certificate. You must test the applications that use the certificate to determine whether these steps are necessary; there is no clear-cut way to determine CRL reliance other than extensive testing. Although performing these procedures for both the certificate and CRL will provide a more complete certificate transportation solution, it may not be necessary to transport the CRL. But either way, it won't hurt. If the possibility exists that the CRL will be needed in the future, it's a good idea to go ahead and transport it with the corresponding certificate.  | Both certificates and CRLs have expiration dates. Although certificates may be valid for several years , CRLs are usually valid for only days or weeks. This is because certificates are revoked with some frequency and the CRL must be updated to include those revoked certificates. Therefore, when the CRL must be transported in this manner, you will most likely be required to repeat the procedure periodically. The certificate does not need to be redistributed every time the CRL is; each has its own independent lifetime. | |
9.2.2 Backing Up the Certificate and Private Key After the certification hierarchy is set up and configured, the number-one issue that helpdesks encounter is users who have lost the private key associated with a certificate. Often this key has been used to encrypt data using the Encrypting File System (EFS), to send and receive encrypted email, or for some other long- term protected data storage use. The most common reasons for losing a private key are: -
Reinstallation of the operating system -
Deletion of the user's profile -
Hard disk failure and replacement resulting in data loss When the private key is permanently lost, there is no way to recover the data protected with that key . Many people are surprised to learn that. But if there were a way to recover the data without the private key, the entire public key security concept would be useless. However, as an administrator, you have some options to mitigate this situation. The only real solution to this problem is to archive the private key before it is lost. This can be done in two distinct ways. Both ways have advantages and drawbacks, so they must be weighed carefully before a decision is made. One option is to configure the certification authority to store the user's private key when accepting a certificate request. This allows the administrator to maintain the storage of these keys indefinitely and provide a replacement whenever a user loses it. The user does not need to take any additional steps to ensure this level of redundancy. Although archiving the private key on the CA presents some security concerns, there are huge recoverability benefits. This option is frequently referred to as key archival and must be supported on the issuing CA. The other option is for the user to archive his private key to an external drive, floppy disk, or CD. This is easily accomplished by the user through the Certificates MMC snap-in. A fairly straightforward wizard asks a few questions and then writes the private key to a file specified by the user. This file can be password-protected for an additional level of security. In any case, this file must be physically protected from others to avoid the possibility of this private key copy from falling into the wrong hands. Another drawback to this method is that it is not administrator controlled and cannot be enforced through technology-based policy. Users can simply forget to create the backup. 9.2.2.1 Archiving a certificate and private key To archive a private key to a floppy disk or CD, the user must follow these steps: -
Run the Certificates snap-in ( certmgr.msc ). This snap-in allows certificates and private keys to be displayed for the current user, the computer account of the local computer, or a service account. -
Identify the correct certificate. There is usually more than one certificate and private key available through the snap-in, as is shown by a typical certificate store in Figure 9-2. Care must be taken to ensure the proper key is archived. But because the certificates and keys are so small, many keys can be archived and stored. Backing up all certificates is recommended, but this cannot be accomplished in a single step. -
Right-click the certificate and click All Tasks, then click Export to run the Certificate Export Wizard. -
Specify that you want to export the private key with the certificate. This step is critical, as the private key is the unique data that is truly valuable and cannot be replaced by administrators or other users. -
Provide a password for the exported private key and certificate. This is used to prevent compromise of the private key if the storage medium is compromised. -
Export the file directly onto a floppy disk (or writeable CD drive). This ensures that a temporary copy is never stored on the local hard drive. -
Repeat as necessary for each certificate that has an associated private key. -
Separate the floppy disk (or CD) from the user to keep them both safe. Figure 9-2. Certificates MMC snap-in displaying several certificates 
Remember that the private key still exists as a part of the user's profile information on the computer. It has simply been backed up to the floppy disk. If the user's profile is damaged or lost (for example, if the computer's hard drive fails), the floppy disk has a copy of that private key. 9.2.2.2 Restoring an archived private key To restore a private key that has been lost, use the following simple procedure: -
Insert the floppy with the archived private key. -
Double-click the file on the floppy disk. -
The certificate and its private key are now imported into the user's private key store. | | The restore procedure does not remove the private key from the floppy disk or make the disk any less valuable. The disk should immediately be returned to its protected storage to ensure its security. If the disk is ever damaged or considered obsolete, it should be destroyed to ensure the unrecoverability of the private key it may still contain. | |
| 