PKI Elements (MSDN)

发布时间：2011-2-28 15:42
分类名称：PKI

Certification Authorities

A certification authority (CA) is responsible for attesting to the identity of users, computers, and organizations. The CA authenticates an entity and vouches for that identity by issuing a digitally signed certificate. The CA can also manage, revoke, and renew certificates.

A CA can be public or private. A public CA provides certification services, typically for a fee, to the public over the Internet. A private CA provides this service to the members of a delimited population such as the employees of a business or members of some other private group.

The means by which a CA authenticates an end user are varied and beyond the scope of this documentation. Clearly, however, methods of authentication vary by type of provider. For example, a private CA can establish the identity of end users by referring to a group roster such as an employee database or Active Directory. The authentication methods performed by a public CA are generally more complex and depend partly on the level of assurance being promised by the certificate.

As the population of a public key infrastructure (PKI) grows, it can become difficult for a single CA to effectively manage all of the certificates it has issued. The CA can compensate by authorizing other CAs in the PKI to issue certificates. The initial CA is called the root, and the CAs it authorizes are called subordinates. Subordinate CAs can also designate their own subsidiaries within the limits set by the root. The resulting structure is called a certificate hierarchy. The certificates issued to CAs lower in the hierarchy contain enough certificates to trace a path back to the root. This is called a certificate chain.

The term certification authority can refer to both the organization that vouches for the identity of an end user and the server used by the organization to issue and manage certificates. A Windows server can be configured to act as a CA server, and this documentation usually refers to the server when using the term CA.

The Certificate Enrollment API interacts with a CA mainly by using the IX509Enrollment object. The Enroll method on this object can automatically encode a certificate request, submit it to the CA, and install the issued certificate. You can also use an initialized IX509Enrollment object for out-of-band enrollment or for delayed enrollment. In addition, you can use the IX509EnrollmentStatus object to monitor enrollment status.

Certificate Directory

A Windows public key infrastructure (PKI) saves certificates on the server that hosts the certification authority (CA) and on the local computer or device. CA storage is typically referred to as the certificate database, and local storage is known as the certificate store.

Certificate Database

When you add Certificate Services on a Windows server and configure a CA, a certificate database is created. By default, the database is contained in the %SystemRoot%\System32\Certlog folder, and the name is based on the CA name with an .edb extension. The database can contain:

·         Issued certificates

·         Revoked certificates

·         Archived private keys

·         Certificate requests

You cannot use the Certificate Enrollment API to manipulate the database. The enrollment process automatically creates the necessary entries.

Certificate Stores

Microsoft Certificate Services copies issued certificates and pending or rejected requests to local computers and devices. The storage location is called the certificate store and consists of the following logical stores.

You cannot use the Certificate Enrollment API to specify or retrieve store properties or copy certificates to specific stores.

Key Recovery Server

A Microsoft certification authority (CA) can be configured to archive and recover the private key associated with the public key submitted in the certificate request. Recovery is useful if a key is lost. By default, only encryption keys can be archived. It is not necessary to archive keys intended only for signing because only the public key is needed to verify a signature if the private signing key is lost.

To archive a key, the CA must be configured to issue key recovery agent (KRA) certificates and to have already issued at least one. A key recovery agent is an administrator authorized by an organization to decrypt private keys. To enhance security, we recommend that the key recovery agent and the certificate manager roles be assigned to different individuals, that the certificate manager be permitted to retrieve but not decrypt archived keys, and that the key recovery agent be permitted to decrypt keys but not retrieve them.

Key Archival

A client typically requests a certificate by using a template. If the template requires that the private key be archived, the following steps are performed by the client and the CA:

1. The client retrieves and validates the CA exchange certificate to determine whether it has been signed by the same key that was used to sign the CA signing certificate. This ensures that the only CA that can decrypt the private key is the CA from which a certificate is being requested.
2. The public key in the CA exchange certificate is used to encrypt the private key associated with the certificate request, and the request is sent to the CA.
3. The CA uses the private key associated with its exchange certificate to decrypt the private key sent by the client and verifies that the public and private keys in the request are related.
4. The CA encrypts the private key by using the public key in the KRA certificate. If the CA has issued multiple KRA certificates, it encrypts the private key once with each available public key so that any authorized key recovery agent can recover a key. The encrypted private keys are stored in the certificate database.
5. The CA releases all references to the private key and securely frees and zeroes all memory that contained the key. This ensures that the CA has no further access to the key in clear text format.

Note Only a CMC request can be used for key archival. CMC requests are represented by the IX509CertificateRequestCmc interface.

Key Recovery

Key recovery is not directly supported by Active Directory Certificate Services or the Certificate Enrollment API. Microsoft does, however, provide the following applications to help with the process:

• Certutil.exe is a command line program that can be used to retrieve CA configuration information, verify certificates, key pairs, and certificate chains, and back up and restore keys. It is included in server operating systems beginning with Windows Server 2003.
• Krecover.exe is a dialog box–based program that enables key recovery. It is included with the Resource Kit beginning with Windows Server 2003.

The following steps are performed to recover a private key:

1. The certificate manager locates potential candidates for key recovery in the certificate database by using the name of the certificate, requester, or user. The Certutil -getkey command can be used for this purpose.
2. Once the certificate manager has a list of certificates, the -getkey command is called again with a specific certificate serial number or thumb print to retrieve a PKCS #7 file that contains the KRA certificate, user certificate chain, and the private key that was encrypted during archival by using the KRA public key.
3. The certificate manager passes control of the process to the key recovery agent whose private key matches the public key contained in the KRA certificate.
4. The key recovery agent decrypts the archived private key returned in the PKCS #7 file by using the KRA private key. This can be done by using the Certutil -recoverkey command which places the key in a password-protected PKCS #12 file. The client must be given the password through a secure out-of-band mechanism.
5. The client imports the PKCS #12 file and uses the password to retrieve the key.