Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Certificates

In Diffie-Hellman and DSS key exchanges, a brand new cipher key is created for each session. This makes sense in applications like IPSec where a secure network communication link is established pretty much on an ad hoc basis. But what if you want to retain the key for later use, such as digital signatures? You need a way to transport the key securely and, just as importantly, you want to make sure that the key comes from an authorized issuer and has not been tampered with along the way.

The data structure used to transport and validate keys is called a

certificate . A certificate acts as a strongbox that protects the key while guaranteeing the identity of the issuer, the identity of the owner, and the purposes for which the key can be used. The certificate also contains additional information called

extensions that streamline the validation process.

A certificate cannot be forged because the issuing authority digitally signs it. The signature is applied to a hash of the certificate. This enables clients to validate the issuer's identity and check for tampering at the same time. The client decrypts the hash using the issuer's public key and then compares the result to a separate hash it performs on the certificate. If the results match, the certificate is valid.

In Windows Server 2003, Windows XP, and Windows 2000, certificates are handled by the Data Protection API. Certificates issued to a client are stored in the Registry and Active Directory. The keys are stored on disk. Certificates can also be stored in smart cards. This eliminates the vulnerability of on-disk key storage. You can view the certificates issued to you as a PKI client with the Certificates snap-in. There is no pre-built console for this snap-in, so you must load it into an empty console using the F

ILE | A

DD/ R

EMOVE S

NAP-IN option in the MMC menu. Figure 18.3 shows the general details of a certificate.

A certificate contains the following items (some are optional):

• Issued By .
  The Certification Authority (CA) that issued the certificate. By default, a copy of the public-key certificate is stored in the CA database. A Windows Server 2003 CA can also retain private key certificates.




• Issued To .
  The entity that obtained the certificate. In a Windows Server 2003 PKI, computer names can be formatted with the computer's flat name or its fully qualified domain name. If the recipient is a user, the name can be the user's logon ID, User Principal Name (UPN), or Distinguished Name (DN).




• Intended Uses (OID) .
  A certificate has one or more uses. You cannot issue a

  carte blanche certificate for every purpose. The issuing CA stipulates the purposes based on an

  Object ID , or OID. An OID uses a dotted-decimal notation to show a hierarchy. For example, the OID 1.3.6.1.4.1.311.20.2.1 refers to the Enrollment Agent function. The OID is rooted at the ISO in Geneva (1), issued to an ISO recognized organization, the U.S. Department of Defense (1.3.6), and controlled by the Internet Assigned Naming Authority (1.3.6.1).




• Version .
  The certificate version. Windows CA servers issue X.509 Version 3 certificates.




• Serial Number .
  This is a sequential number assigned by the CA to the certificate. The number is unique and acts as a validity check.




• Signature Algorithm .
  The hashing algorithm used to do the digital signature for the certificate. This is typically either SHA-1 or MD5 (RSA).




• Issuer .
  This is the X.500 distinguished name of the issuing serverfor example, cn = ca-1, o = company, l = phoenix, s = az, c = us, e = administrator@company.com.




• Valid From .
  This is the issue date of the certificate.




• Valid To .
  This important field defines the expiry date of the certificate. The CA determines how long to issue a certificate. Shorter intervals are more secure but require more work on the part of the clients.




• Subject .
  This is the X.500 distinguished name of the certificate's owner.




• Public Key .
  This data structure holds the public key itself.




• CA Version .
  This is the number of times the authorization certificate for a particular issuing server has been renewed.




• Subject Key Identifier .
  This important field contains an SHA-1 hash of the Public Key field used to uniquely identify the contents. This prevents tampering with the public key.




• Certificate Template .
  This is a unique Microsoft extension that contains name of the template used by the CA to generate this certificate.




• Key Usage .
  This field contains the OIDs of the purposes for the certificate.




• Authority Key Identifier .
  Contains an SHA-1 hash of the public key of the issuing CA along with the distinguished name of the CA.




• CRL Distribution Points (CDPs) .
  Contains the identity of the CDPs listed by LDAP path, URL, and file share name.




• Authority Information Access .
  Tells a client where to find the certificate of the issuing CA.




• Thumbprint .
  A hash of the certificate used for positive identification.




• Thumbprint Algorithm .
  The algorithm used to obtain the certificate hash.

Certificate Documentation

The contents and structure of a standard PKI certificate is defined by the ITU (International Telecommunications Union) in the X.509 standard. The most current standard, Version 3, was defined in 1995.

The ITU works closely with the IETF (Internet Engineering Task Force) to make sure the standards match the current utilization. See RFC 2549, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," for IETF documentation of the certificate contents and structure.

Public key technology as it is used today was originally developed by RSA, and you can get documentation at its web site, www.rsalabs.com. The standard certificate structure is documented in PKCS#7 (P7B), "Cryptographic Message Syntax." RSA also documents certificate-handling mechanisms, including the following:

• PKCS#10, Certification Request Syntax.
  This is not a certificate, as such, but a way of obtaining a certificate from a Certification Authority.




• PKCS#11, Cryptographic Token Interface Syntax.
  This standard defines how to securely store certificates in hardware such as smart cards.




• PKCS#12, Personal Information Exchange Syntax.
  This certificate type is designed to securely store and transfer private keys.

Local Certificate Stores

The certificates and keys obtained by a PKI client are stored in various places at the local client depending on their function. Windows abstracts the physical locations behind a logical store that can be viewed with the Certificates snap-in (see Figure 18.4). The logical stores are as follows:

• Personal .
  This store holds certificates issued to the user, computer, and any services running on the computer. You can view computer and service certificates if you log on with administrator rights. The physical store is the Registry in HKLM | Software | Microsoft | SystemCertificates.




• Trusted Root Certification Authorities .
  Contains certificates for root CAs and third-party root CAs that have been preloaded or downloaded by Windows Update. The physical store is the Registry and in Group Policies.




• Intermediate Certification Authorities .
  Contains subordinate CA (and third-party subordinates) along with any Certificate Revocation Lists (CRLs).




• Active Directory User Object .
  Contains certificates that have been copied to Active Directory.




• Request.
  Shows submittals for certificates sent to a CA. Copies of the PKCS#10 requests are stored in the Registry.




• Software Publishing Certificate (SPC) .
  Computer clients use this store to hold certificates from Authenticode and other digital signing software. The physical store for SPC is the Registry.