Feb. 27, 2011, 4 a.m.
posted by vdv
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 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.
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).
Figure. 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).
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:
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 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.
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).
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 shows an example.
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 shows an example of the Publish CRL window.
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 shows an example.
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 shows the Windows Update site with selections for software and driver updates.
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 shows an example.
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).
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 shows an example of a 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 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.
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.html#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.
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.
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:
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 shows an example.
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(126.96.36.199.188.8.131.52.2) Alternative Name: URL=ldap:///CN=CA-1,CN=AIA,CN=Public%20Key%20Services, CN=Services,CN=Configuration,DC=company,DC=com DC=net?cACertificate?base?objectclass=certificationAuthority Authority Info Access Access Method=Certification Authority Issuer(184.108.40.206.220.127.116.11.2) Alternative Name:URL=http://server1.company.com/CertEnroll/ server1.company.com_CA-1.crt
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.
Online Certificate Status Protocol
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: