A certificate is a data structure that contains a key, either public or private, along with information about the key and validation data for the key's issuer. If you build a mental picture of a valuable diamond accompanied by a gemologist's report and a certified pedigree with embossed signatures, you have a good idea of how a certificate is used.
The International Telecommunications Union (ITU) has promulgated a standard, X.509, that defines the content and structure of PKCS certificates. Figure 17.6 shows an example X.509 certificate.
There are other certificate types that enjoy wide acceptance in the marketplace but have not been incorporated into the ITU standard. RSA maintains a list of certificate types and documentation of their content and structure. Visit the RSA web site at www.rsasecurity.com.
Certificates are stored in various locations depending on their use and whether they contain public or private keys. Windows has a "logical" certificate store that abstracts the physical locations. An MMC snap-in called Certificates permits you to view the contents of the logical store. Figure 17.7 shows the contents of the Certificates snap-in. You can view your own certificates and, if you have administrator privileges on the computer, you can view certificates issued either to the computer or to services running on the computer. You cannot view the contents of another user's certificate store.
There is no formal console that hosts the Certificates snap-in. You must load it into an MMC console manually. Use Procedure 17.1.
Procedure 17.1 Viewing Personal Certificates via the Certificates Snap-In
Open an empty MMC console using S
TART | R
UN | MMC.
From the console menu, select C
ONSOLE | A
DD/ R
EMOVE S
NAP-IN . The Add/Remove Snap-in window opens.
Click Add. The Add Standalone Snap-in window opens.
Double-click Certificates to load the snap-in. If you are logged on with an account that does not have administrator privileges, the only option is to load the your own personal certificates. Otherwise, you get additional choices of computer and service certificates.
With the snap-in loaded, save the console with a descriptive name, such as Cert.msc. You may want to save it in \WINNT\System32 along with the rest of the console files so that another administrator can use it. The console does not point at your specific certificate. It loads the certificates of the user who launches the console.
Expand the tree to CertificatesCurrent User | Personal | Certificates. Certificates issued to you are listed in the right pane. The Intended Purposes column lists the certificate's function. If you have ever encrypted a file, you will have at least one EFS certificate. The domain Administrator account will have two certificates, one for EFS and one for File Recovery (FR).
Double-click a certificate to view the contents.
You can use the Certificates snap-in to obtain new certificates. This is not generally necessary for EFS certificates because the EFS service obtains the certificate automatically when you encrypt a file. If you want to designate more Data Recovery Agents, though, you'll need to obtain File Recovery (FR) certificates for them. You can request them using the Certificates snap-in.
EFS only issues one self-signed FR certificate. In a domain, it is issued to the domain Administrator account. For a local machine, it is issued to the first user who logs on to the machine following Setup. You'll need a Certification Authority (CA) to issue any further FR certificates.
The keys stored in a user's profile are not in a transportable format. If you need to transfer a user's keys to another machine, the simplest way to do this is to configure a roaming profile for the user and then log on at the target desktop. This places a copy of the user's profile on the new machine with the EFS keys inside.
The FR public key is distributed via an X.509 certificate in group policies. Its security is not an issue. However, you should remove the certificate from group policies to disable file encryption on Windows 2000 clients until you are ready to deploy EFS in production.
The FR private key is another matter altogether. You most definitely do not want copies of the FR private key bandied about your network. One of the first steps you should take when deploying EFS is to copy the FR private key to a certificate, then remove it from any machines.
The Certificates snap-in is used to save keys in a certificate. Windows supports several certificate formats for this purpose:
X.509 certificates (.CER) using Distinguished Encoding Rules (DER)
X.509 certificates (.CER) using Base-64 encoding
PKCS #7 Cryptographic Message Syntax Standard (.P7B)
PKCS #12 Personal Information Exchange (PFX)
Of these four types, the first three are used to distribute public keys. Only the last type, the PFX certificate, can store a private key. The PFX format uses strong encryption to store the key without compromising it. For details about the PKCS #12 format, download the technical documentation from