A local PKI client generates its own public/private key pairs. It is free to send the public key to other entities, but there is no reason why the other entities should trust it because nothing validates the source of the certificate.
Turning self-generated public keys into something trustworthy requires the intervention of a Certification Authority, or CA. A CA acts like a notary public. It affixes its own signature to a client's public key, thereby proclaiming the key to be valid, at least to anyone who trusts the CA.
A CA is the ultimate entrepreneur. Anyone with administrative rights on a server running Windows Server 2003 or UNIX/Linux server can install the certificate services and go into the certificate issuance business. A new CA has no other CA to vouch for it, so it signs its own CA certificate and becomes a root CA.
Like any entrepreneurial concern, a CA can only survive if clients know where to find it and trust its integrity. Microsoft differentiates between CAs based on where they place their CA certificates:
An Enterprise CA stores a copy of its CA certificate in Active Directory where clients can download it and place it in their local certificate store.
A Standalone CA stores a copy of its CA certificate in a shared folder that can also be accessed via a web URL. Clients must be told the name of the CA so they can send it their certification requests and pick up their certificates at the designated location. (An Enterprise CA also uses fixed storage for clients that are not able to search Active Directory.)
An Enterprise Windows Server 2003 CA adds value to the certificate issuance process by using Kerberos or NTLM to validate the identity of an end-entity prior to issuing it a certificate. This provides additional assurance for PKI clients when they receive digital signatures from the entity.
By using a mixture of Enterprise and Standalone CAs, you can achieve a PKI that is both highly secure and highly scalable. As you plan your CA deployment, keep in mind that the name of the CA server and its distinguished name in Active Directory are incorporated into the X.509 certificates it issues, so a CA cannot be renamed or removed from a domain. Also, the Certificate service is not cluster-aware, so it cannot be run as a fail-over resource on a Windows Server 2003 Enterprise or Datacenter Edition cluster. It can, however, run on a single node of the cluster, if you desire.
Certificates issued by a CA are stored in a Jet database called <server_name>.edb under \Windows\System32\ CertLog. This database contains the CA private key. Protect the database as carefully as you protect Active Directory. If you should lose the CA database, you lose the ability to audit certificates issued by the CA. The database is backed up as part of System State.
Enterprise CAs also place certificates in Active Directory in the Public Key Services container located under cn=Services, cn=Configuration, dc=<domain>, dc=<root>. This container holds the following subcontainers:
This container holds PkiEnrollmentService objects representing CAs that are configured to issue certificates. These objects have a copy of the CA certificate, the DN (distinguished name) of the certificate, and the certificate templates advertised by the CA.
This container holds PKICertificateTemplate objects. Attributes of these objects define the name, content, OID, and purpose of the certificate type the template was designed to produce. You must have a Windows Server 2003 domain to have Version 2 certificate templates in this container.
CRL Distribution Points (CDP).
These containers hold CRLDistributionPoint objects for each CA. Attributes of these objects hold the base CRL certificate and any Delta CRL certificates issued by the associated CA. Clients download these certificates and use them to perform local validation.
Authority Information Access (AIA).
This container holds copies of the CertificationAuthority objects also contained in the main Certification Authority container. Clients reference the AIA container when they need to retrieve the certificate of a CA in a trust chain.
Key Recovery Agent (KRA).
This container holds MsPKI-PrivateKeyRecoveryAgent objects for each CA. These objects have a UserCertificate attribute that lists the private keys stored by a CA that is configured as a Registration Authority.
Object Identification (OID).
This container holds MsPKI-Enterprise-Oid objects that define the name and OID of certificates issued by the CAs in the enterprise. OIDs are unique identifiers assigned to a certificate type by an issuing authority.
A Windows Server 2003 Enterprise CA uses certificate templates stored in Active Directory to generate certificates for users, computers, and other CAs. Standalone CAs do not use templates.
Certificate templates are managed via the Certificate Templates snap-in. The simplest way to access this snap-in is through the Certification Authority console. Right-click the Certificate Templates folder and select MANAGE from the flyout menu (see Figure 18.5).
Figure 18.5. Certificate Templates snap-in showing the Version 1 and Version 2 templates available for distribution by a Windows Server 2003 CA.
Double-click a template to open its Properties window, which shows the purpose of the certificates issued with the help of the template and the extensions that will be included in the certificate (see Figure 18.6).
Figure 18.6. Certificate template properties showing the included extensions.
The snap-in displays two template types. The first type, shown in a dimmed color, is Version 1 templates. These templates contain fixed information that cannot be modified by an administrator. Windows 2000 uses Version 1 templates and they are included for backward compatibility. The second type, shown in full color in the console, is Version 2 templates. These templates contain configurable fields that provide much more flexibility in PKI design and deployment.
Armed with the new Version 2 templates, a Windows Server 2003 CA provides the following additional features compared to a Windows 2000 CA:
Key archive and recovery.
The CA can save copies of key pairs that can be recovered and re-issued to users who lose their keys. A CA providing this service is called a Registration Authority. Up until Windows Server 2003, the only Windows product that provided registration services was the Exchange Key Management Service (KMS). The next version of Exchange will hand KMS duties over to a Windows Server 2003 CA. If you currently use KMS in Exchange 5.5 or Exchange 2000, you can export the private keys to a Windows Server 2003 CA using the CERTUTIL utility in Windows Server 2003.
In Windows 2000, computers could be configured to auto-enroll for a Computer certificate. In Windows Server 2003, users can be configured to auto-enroll for a User certificate. The User certificate template supports the Encrypting File System, digital signatures, and client authentication for IPSec, SSL, and smart cards. User auto-enrollment is only available when logging on at an XP desktop or server running Windows Server 2003.
This feature permits a CA to limit the type of certificates that can be issued by a subordinate CA.
A large production PKI can have a very long Certificate Revocation List. This degrades performance because every client must check the CRL each time it is presented with a new certificate. Using a Delta CRL, the client only need download the changes to the base CRL, a significant savings in bandwidth.
Common Criteria requirements.
ISO standard 15408 defines an IT security evaluation checklist. The National Institute of Standards and Technology (NIST) refers to the 15408 standard the as the Common Criteria, or CC. The most current CC version is 2.1, which you can download from csrc.nist.gov/cc/ccv20/ccv2list.htm#CCV21. A properly implemented Windows Server 2003 CA hierarchy meets the Common Criteria requirements.
These are all great features and are welcome additions to Windows CA services, but the bad news is they are only available on Windows Server 2003, Enterprise Edition and Datacenter Edition. Windows Server 2003, Standard Edition, can only use legacy Version 1 templates and does not meet the Common Criteria standards due to lack of role-based management features. Also, you must have a Windows Server 2003 domain to use Version 2 templates because they require schema components that are not available in Windows 2000.
A CA has another job that is equally as important as issuing certificates. It stands ready to revoke those certificates, if necessary. For instance, if a bad guy is able to compromise the private key of a user, you can revoke the user's public key certificate so that other users no longer trust it.
The CA maintains a Certificate Revocation List (CRL) containing the serial number of any revoked certificates. The serial number is a sequential integer assigned to a certificate by the issuing CA.
Use the Certification Authority console to revoke a certificate. Right-click the certificate and select ALL TASKS | REVOKE CERTIFICATE from the flyout menu. This places the certificate in the Revoked Certificates container.
Use caution when revoking a certificate. There is no "un-revoke" feature. All digital signatures, encrypted messages, encrypted files, and other cryptographic applications that rely on the certificate become inoperable when the certificate is revoked. If you revoke the certificate of a subordinate CA, all certificates issued by that CA become invalid.
Certificate Revocation List
Certificates are like credit cards. A bank can revoke a card but it is nearly impossible to recall it. Instead, the bank adds the card to a revocation list. In a credit card infrastructure, each merchant is responsible for validating a card by dialing up a central clearinghouse and checking the revocation list. In a PKI, each CA issues a Certificate Revocation List (CRL) that identifies revoked certificates. Each PKI entity is responsible for checking the CRL when it validates a certificate.
When a CA creates a CRL, it places copies in strategic locations where clients can download it. These are called CRL Distribution Points, or CDPs. A CA certificate specifies the CDP locations. Figure 18.7 shows an example. If a client is unable to find the CRL at the specified CDP, it assumes that any certificate issued by the CA has been revoked.
Figure 18.7. CDP listing in a CA certificate issued by an Enterprise Windows Server 2003 CA.
An Enterprise Windows Server 2003 CA publishes its CRL in Active Directory in a CRLDistributionPoint object under cn=<server_name>, cn=CDP, cn=Public Key Services, cn=Services, cn=Configuration, dc=<domain>, dc=<root>. A Standalone CA places the CRL on disk in %systemroot%\system32\certsrv\CertEnroll. This folder is also forms the root of a virtual web directory by the same name.
You can view the contents of a CRL from the Certification Authority console. Right-click the Revoked Certificates container, select PROPERTIES, and then click View CRLs (see Figure 18.8).
Figure 18.8. CRL certificate showing the revocation list.
To prevent constant traffic to the CA, clients cache the CRL for a publication period. When the period expires, the client returns to the CDP to download an updated CRL. If one is not available, the client will assume that all certificates issued by the CA have been revoked.
A PKI client must be coded to do CRL checking when it receives a certificate. This is not a requirement. For example, Outlook does not perform automatic CRL checking because the client can function in offline mode. CRL checking must be done manually.
Clients learn the CDPs for a particular CA because the locations are included in a CDP extension entry in the CA certificate.
You can modify the CDP values in a CA certificate using the Properties window for the Certification Authority. Select the X.509 Extensions tab. Figure 18.9 shows an example.
Figure 18.9. Certification Authority properties showing the CDP values used by the CA when storing CRLs.
A CA publishes a CRL to make the list of revoked certificates available to clients. This consists of putting a copy of the CRL in the CDPs where clients can download it. Each CRL has a publication interval. Clients cache a CRL for its publication interval. This minimizes traffic to the CA.
You can manually publish a CRL in Windows Server 2003. This is done from the Certification Authority console. Right-click the Revoked Certificates container and select ALL TASKS | PUBLISH from the flyout menu. Figure 18.10 shows an example of the Publish CRL window.
Figure 18.10. Publish CRL window showing full or Delta CRL options.
A CRL can grow very large if you assign long expiration intervals on the issuing CAs. The most current PKIX RFCs allow for publishing Delta CRLs. These contain changes to the base CRL. Servers running Windows Server 2003, Windows Enterprise and Datacenter Editions support publishing Delta CRLs.
The default publication interval for base CRLs is one week. The interval for delta CRLs is one day. You can change the intervals using the Properties window of the Revoked Certificates folder. Figure 18.11 shows an example.
Figure 18.11. Revoked Certificates properties showing publication intervals for CRL and Delta CRL.
After a CRL expires, clients will refuse to honor any certificates issued by the CA until a new CRL is published. You should issue base CRLs infrequently with long publication intervals and then issue Delta CRLs as often as necessary to assure quick revocation of a certificate. For example, a small organization might get away with issuing the base CRL every quarter and Deltas every week. A large organization with thousands or tens of thousands of certificates might issue the base CRL every week and the Delta every day while manually publishing Deltas whenever a new certificate is revoked.
Obtaining CRLs via Windows Update
Microsoft accepts third-party CRLs at the Windows Update site, windowsupdate.microsoft.com. This permits PKI vendors to distribute their CRLs when they do not list their CDPs in their CA certificates. Figure 18.12 shows the Windows Update site with selections for software and driver updates.
Figure 18.12. Windows Update web site showing various update options.
If a user receives a certificate and the associated CA certificate is not in the client's trusted root store, the crypto system will go to the Windows Update site to check for a copy of the certificate and a copy of the CRL.
All downloads from the Windows Update site are digitally signed by Microsoft to validate their origin. This prevents a third party from redirecting clients to a bogus Windows Update server and fooling them into downloading malicious files.
When two PKI entities exchange a piece of protected data, such as a digitally signed email message or an encrypted TCP datagram, the entities must have a copy of each other's public keys to decrypt the data or signature. The clients could simply exchange public key certificates, but how could they be sure that the certificate from the other entity is trustworthy?
For instance, picture me at a checkout line in an upscale menswear store. I give the clerk a document, signed by me, attesting to the fact I am shopping for the President of the United States and instructing anyone reading the document to accept my check. The clerk would laugh and call Security.
PKI entities do not implicitly trust certificates issued by end entities, or even by CAs. They must first trust the issuing CA. A PKI client trusts a CA if it has a copy of the CA's public key certificate in its local certificate store. It uses the public key in this certificate to verify the digital signature on the certificate offered by end entities.
There is no formal procedure in Windows Server 2003 or XP for obtaining the CA certificate from a trusted CA. Microsoft preloads certificates from quite a few third-party PKI vendors. Certificates can be downloaded via Windows Update. The certificates can be installed using the Signature Wizard when downloading an ActiveX control or installing some other form of digitally signed software. In an Active Directory domain, they can be obtained via group policy.
You can see the trusted certificates stored at a client by using the Certificates snap-in. The logical store is under Trusted Root Certification Authorities | Certificates. Figure 18.13 shows an example.
Figure 18.13. Trusted CAs shown in the Certificates snap-in.
Because of the ad hoc nature of trusting CAs, it is important that users use caution when accepting certificates. For instance, when downloading an ActiveX or Java control, a Security Warning window appears to notify the user that the code has been signed and gives the user the opportunity to view the certificate before installing the control. If the user elects the Always Trust Content From... option, the CA certificate for the source is added to the trusted certificate store.
Just because code is digitally signed does not necessarily make it safe to install. For example, you may recall an incident in January 2001, when an untrusted party pretending to be a Microsoft engineer obtained two digital signing certificates from Verisign with the name "Microsoft Corporation" as the identifier.
The error was recognized quickly and the certificates were added to Verisign's CRL but unfortunately Verisign does not include a CDP in its certificates. Without a CDP, clients were unable to ascertain the contents of the CRL and would not block acceptance of the fraudulent certificates. Microsoft was forced to use other means to distribute a CRL containing the identifiers for the fraudulent certificates.
By the time you read this, the fraudulent certificates will have expired, but this is just one example of a larger lesson. Digital security requires procedural security, as well. Windows Update provides a way for vendors to distribute Certificate Revocation Lists, and it is important to make these available to your clients, either by placing copies in Active Directory or permitting clients to contact the Update site directly.
After a root CA is installed, it can issue CA certificates to other certificate servers, making them subordinate CAs. Subordinate CAs can issue CA certificates to other CAs, forming a hierarchy. Another term for this is a chain of trust.
The trust chain is included in every certificate issued by any of the CAs. You can view this hierarchy by selecting the Certification Path tab in the Certificate properties window (see Figure 18.14).
Figure 18.14. Certificates snap-in showing Certification Path of a subordinate CA.
A strict hierarchy like that shown in the figure is satisfactory for a single organization with a single PKI. To support interaction with outside organizations, you need a way to include the root and subordinate CAs from that organization into your trust hierarchy so that your clients can validate the outside certificates.
This can be done by creating a cross-trust. In this configuration, a CA from one hierarchy issues a CA certificate to a CA in another hierarchy. In essence, it designates the outside CA as a subordinate in its own trust chain. Figure 18.15 shows an example of a cross-trust hierarchy.
Figure 18.15. Cross-trust hierarchy.
Creating cross-trusts can turn into a complex affair. Any subordinate CA in one organization can create a cross-trust with any subordinate CA in another organization, forming a complex web of trusts and opening the possibility of circularities in the trust chain.
Microsoft and Entrust (Microsoft adopted its PKI from Entrust) once sought to simplify the trust process by the use of Cross-Trust Lists, or CTLs. A CTL is a signed set of CA certificate hashes that essentially acts like an electronic good old boy's club. "You can go ahead and trust this other CA," the CTL says. "I've checked him out. He knows the score." Clients who trust a CA would automatically trust a CTL issued by the CA.
Cross-trusts and CTLs share a common deficiency, though. Too much trust is placed on the CAs in the other organization. Any certificates issued by any subordinate CA below the point of the cross-trust would be trusted by entities in your organization.
To address this problem, Microsoft packages together constraints and policy usage extensions in the X.509 standard and uses them to support a feature called Qualified Subordination, or QS. Using QS, an administrator can limit the purpose of certificates that will be accepted from subordinate CAs in a cross-trust relationship and also limit the length of the trust chain so that no additional subordinate CAs would be trusted.
Designing a Trust Hierarchy
Figure 18.16 shows a diagram of a typical CA trust hierarchy. When designing a secure CA hierarchy, the first root CA should be an offline Standalone Root. By keeping the root CA off the network, you eliminate the possibility of someone compromising the PKI by obtaining the private key of the root CA. The offline root is used solely to issue CA certificates to subordinate CAs.
Figure 18.16. CA trust hierarchy.
The offline root CA cannot be a domain controller, because domain controllers cannot be taken off the wire indefinitely, and it must not be an Enterprise Root because it has no way to communicate to Active Directory. It should be a member server so that it can validate the identity of servers selected to be subordinate CAs.
When you create a Standalone Root CA, elect to do a custom installation and set the key to a full 4096 bits. This takes a while to generate but it makes sure that the CA certificates issued by the root CA are as secure as possible. You won't be using this CA to do production signing, so the long key won't slow performance.
You must also be sure to store the CRL at a location that is not on the root CA itself. Remember that you will be taking the CA offline. Clients must be able to find the CDP to check for CRLs. Select a central location for the CDP and change the path in the Certification Authority properties. The same is true for AIA paths that point at fixed locations rather than Active Directory. Put the certificates in an accessible location and set the AIA paths before issuing any subordinate CA certificates.
The CA just under the offline root should be an Enterprise Subordinate. The subordinate is an Enterprise CA so it can publish its CA public key certificate in Active Directory. To enable this subordinate, you must either put the root CA on the network temporarily or save a PKCS #10 Certificate Request to a file, transport the file to the offline root, generate the CA certificate, and then transport the certificate to the subordinate.
When selecting key size for a subordinate, or issuing, CA, you should use a minimum of a 2048-bit key. A series of white papers published starting in 2002 have demonstrated possible crypto-analytic attacks on RSA keys that could make 1024-bit keys vulnerable over the next few years. Refer to Bruce Schneier's commentary at www.counterpane.com/crypto-gram-0203.shtml#6.
Because the standalone root does not publish its CA certificates in Active Directory, when you install a subordinate CA, you must request certificates from the standalone root via the Web Enrollment tools. For this reason, the standalone root must be running IIS and have a web share that holds the ActiveX controls that handle web enrollment. This web share, called CertSrv, is installed by default when you install Certificate Services.
At this point, you have a two-level hierarchy with root CA kept offline and one or more second-tier CAs. These are called Issuing CAs. Large organizations should consider using the second tier of CAs strictly to control policies and installing a third tier for the Issuing CAs. The Policy CAs can be kept offline, as well, for additional security.
If you install an Enterprise Subordinate CA in a domain other than the root domain in the forest, you must either be a member of the Enterprise Admins group for the forest or you must have domain administrator privileges in the forest root domain.
If you have not logged on with forest administrator privileges, you will only get the option to create a Standalone Root or Standalone Subordinate CA, even though you are at the console of a domain controller in the child domain.
Each CA must be carefully backed up so that a server crash will not result in a loss of the CA. Remember that a CA's name and domain affiliation cannot change.
Installing a Certification Authority
When you've designed your PKI and determined where you want to locate your CA servers, it is time to install the Certificate service on the server that will be your Standalone Root CA. Follow Procedure 18.1.
Procedure 18.1 Installing a Standalone Root CA
Launch the Add/Remove Programs applet from the Control Panel.
Click Add/Remove Windows Components.
Select Certificate Services. You're prompted with a warning that the computer name and domain affiliation cannot change. Click Yes.
Click Next. The CA Type window opens. Select the Standalone Root CA radio button (see Figure 18.17).
Figure 18.17. CA Type window showing selection of Standalone Root CA.
Click Next. The CA Identifying Information window opens (see Figure 18.18).
Figure 18.18. CA Identifying Information window.
Click Next. The Cryptographic Key window opens. The system generates a key and shows a progress bar.
After the key has finished generating, the Certificate Database Settings window opens. Ensure that the database and log files are stored on a drive that you can either remove from the machine to keep them offline or on the operating system partition if you will take that drive or the entire server offline.
Click Next. The system stops IIS temporarily and then installs the service, initializes the CA database, and restarts IIS.
After installing the service, you can use the Certification Authority console to manage the certificates it issues.
Clients perform validity checks on certificates offered by other PKI entities. The validity checks consist of the following actions:
The client verifies that the certificate is formatted in accordance with X.509 requirements.
The client checks the expiration date of the certificate to ensure that it is still in force.
Each certificate contains a hash of the certificate contents encrypted with the CA's private key. The X.509 standard calls this a signature; Microsoft (and Entrust) calls this a thumbprint. The terms are synonymous. The client performs an integrity check by decrypting the signature using the CA's public key obtained from the trusted CA certificate. The client then hashes the certificate using the same algorithm as the CA and, if the results match, the certificate's integrity is verified.
CA hierarchy check.
If the CA that signed a certificate is not directly trusted by the client, the client checks the chain of authority in each CA in the trust hierarchy.
The client refers to Active Directory or a web site or a network share point to determine if an administrator has revoked the certificate of the root CA or any subordinate CAs in the trust list or of the end entity itself.
Of these checks, the most complex is the hierarchy check. This check requires the client to build a chain of trust leading up to the root CA. The simplest way for the client to build this chain is to reference two certificate elements, the Authority Key Identifier, or AKI, and the Subject Key Identifier, or SKI.
The AKI contains three important pieces of information about the certificate issuer:
This is the X.500 distinguished name or the UPN of the issuing CA.
This is a SHA-1 hash of the CA's public key. It acts as a cross-reference that uniquely identifies the certificate among any others that may have been issued by the same CA to the same end entity.
Certificate serial number.
This is a sequence number (usually a sequential integer) assigned by the issuing CA to the certificate.
The SKI designates the end entity to which the certificate was issued. Typically, this extension holds only the KeyID of the public key in the certificate, although it could hold other identifying information.
Authority Information Access (AIA)
When clients do their validity checks, they must be able to locate a copy of the certificate for each CA in the trust chain so they can check the digital signatures. Windows clients first check their local certificate store. If the certificate is not in the local store, they refer to an extension in the certificate called the Authority Information Access, or AIA. Figure 18.19 shows an example.
Figure 18.19. AIA contents for an Enterprise CA.
An AIA takes the form of an HTTP URL, ftp site, LDAP (Lightweight Directory Access Protocol) container, or file share where the CA certificate can be obtained. Here is an example entry:
Authority Info Access
Access Method=Certification Authority Issuer(18.104.22.168.22.214.171.124.2)
Authority Info Access
Access Method=Certification Authority Issuer(126.96.36.199.188.8.131.52.2)
By default, an Enterprise CA puts copies of its CA certificate in a shared CertEnroll folder and in Active Directory under cn=AIA,cn=Public Key Services, cn=Services, cn=Configuration, dc=<domain_name>, dc=<root>. The CertEnroll folder forms a virtual web folder, as well, so clients can use HTTP to get a copy of the certificate.
When a CA is kept offline, the AIA must point at an URL on another server. For PKIs that involve users outside a domain, an AIA typically includes a location on a web server in the DMZ.
Online Certificate Status Protocol
One of the problems with a classic certificate validity check is that every client must hold copies of the certificates for all trusted CAs and intermediate CAs along with their CRLs and Delta CRLs.
You can simplify a PKI by offloading the validation process to a central server. A PKI client would ask this server to validate a certificate and the server would return a thumbs-up or thumbs-down (digitally signed, of course).
This server-based validation mechanism is one of the services provided by the Online Certificate Status Protocol, or OCSP. This protocol is documented in Internet Draft draft-ietf-pkix-ocspv2-02.txt, "Online Certificate Status Protocol, version 2." OCSP defines three services:
Online Revocation Status.
This check replaces a CRL lookup with a query to the OCSP server. The server must have a copy of the CRL, so this protocol does not eliminate the need for CDPs that are listed in the certificate extensions. It simply offloads the work to a limited number of servers.
Delegated Path Validation.
One of the more complex tasks now handled by a PKI client is to validate the path of a certificate. In a fully meshed PKI, it can take a long time to chase down all the potential chaining paths to determine if they are valid. The server performs this once and then stores the result, speeding up query responses to clients.
Delegated Path Discovery.
This is a subset of Delegated Path Validation in which the server simply returns the path and the client does the validation.
As you can tell by the lack of an RFC, OCSP is a relatively new protocol. Windows Server 2003 supports it in draft form.