CREATE AN ARCHIVE TEMPLATE FOR THE CA.FIGURE 12.15 RECOVERY AGENTS...

6. Create an archive template for the CA.

Figure 12.15

Recovery Agents Tab of the CA Property SheetEach of these steps requires many substeps, but can be well worth the time and effort. Itis worth noting again that key recovery is not possible on a stand-alone CA, because a stan-dalone cannot use templates. It is also worth noting that only encryption keys can berecovered—private keys used for digital signatures cannot be.

T

EST

D

AY

T

IPKey archival and recovery rely on a version 2 template, which is only available inWindows Server 2003 Enterprise or datacenter Editions. If you’re using WindowsServer 2003 Standard Edition, the Recovery Agentstab won’t even be visiblebecause the Standard Edition only supports version 1 templates.

Planning CA Security

The two fundamentals of CA security are to guard the CA hierarchy from attackers and toconfigure the hierarchy for disaster recovery.The first of these requires a good deal of plan-ning. For starters, you need to know the physical and logical location of the root CA. Forextreme security, the CA can be physically located in a locked closet with a lights-out con-figuration (“lights out” refers to a server that has neither a monitor nor a keyboardattached). In most cases, however, lights out would be appropriate only after the entire PKIis set up. Remember that you will need to use the root CA every time a subordinate CAneeds to request a certificate.As we have already discussed, configuring the root CA as a standalone is probably themost important measure you can take to prevent accidental or intentional tampering.Withno network connectivity, attacks become virtually impossible, since a user would have tolog on while sitting at the physical location of the server. Other security considerations arereally more a function of general server security—things such as requiring complex pass-words and implementing file encryption.In guarding the hierarchy, you cannot solely concentrate on the root CA. After all, if asubordinate CA is tampered with, every entity below it in the PKI hierarchy becomes com-promised. Most subordinate CAs are attached to the network.This obviously increases theirvulnerability. Beyond securing the network itself (by using IPSec and group policies, forexample), there is another part of a standard PKI that helps maintain CA integrity.That partis certificate revocation, which we will go into in greater detail shortly. Certificate revocationenables an administrator to warn PKI clients about certificates that might not be authenticor that might have been issued by a rogue CA.Disaster recovery applies to every CA in the hierarchy, but especially at the root.Thatbeing said, the importance of performing proper backups cannot be overstated. A periodicfull backup (for example, weekly) with more frequent incremental backups (for example,daily) is recommended. For your organization, configuring the hierarchy for a disaster mayalso include installing additional CAs that are responsible for more narrow responsibilities.For example, you might want one CA to issue smart card certificates and nothing more.That way, if the CA is lost, it is not as difficult to replace. Finally, remember WindowsServer 2003’s capability to archive and recover keys.As mentioned above, the first concern of PKI security is keeping the root CA secure.Because Microsoft recommends that you configure the root CA as offline and stan-dalone, the machine should not be a domain controller. Domain controllers needto be available for replication and cannot be offline a majority of the time.

Certificate Revocation

A CA’s primary duty is to issue certificates, either to subordinate CAs or to PKI clients.However, each CA also has the capability to revoke those certificates when necessary.Thetool that the CA uses for revocation is the certificate revocation list, or CRL.The act ofrevoking a certificate is simple: from the Certification Authorityconsole, simply high-light the Issued Certificatescontainer, right-click the certificate and choose All |Revoke Certificate.The certificate will then be located in the Revoked Certificatescontainer.When a PKI entity verifies a certificate’s validity, that entity checks the CRL beforegiving approval.The question is: how does a client know where to check for the list? Theanswer is the CDPs, or CRL Distribution Points. CDPs are locations on the network towhich a CA publishes the CRL. In the case of an enterprise CA under Windows Server