Lesson 2: Managing Certification Authorities

When designing your CA hierarchy structure, consider designing the individual tasks that are performed at a CA. Plan all tasks involved during the lifetime of the certificate, including issuing certificates, revoking certificates, and renewing certificates.

After this lesson, you will be able to

  • Design the management of certification authorities for the issuance, revocation, and renewal of certificates

Estimated lesson time: 45 minutes

Once you've established your optimal CA structure, plan the deployment, revocation, and renewal of certificates issued by the CA that you are managing.

Planning Certificate Issuance

The first step in managing certificates is issuing certificates to the necessary users, computers, and network devices. Issuing certificates involves either configuring permissions to establish which security principals have Enroll permissions for specific templates (in the case of Enterprise CAs) or appointing a certificate administrator who will review each certificate request and issue or deny the request based on the information provided.

Designing Automatic Issuance

You can design your PKI to perform certificate requests for computer accounts automatically. Within Group Policy, you can define which certificate templates will be requested automatically by computer accounts within the site, domain, or organizational unit (OU) where the Group Policy object is defined, as shown in Figure 10.17.

click to view at full size.

Figure 10.17 Issuing computer certificates by configuring automatic certificate requests in Group Policy

In addition to defining which certificate templates are automatically requested by computers in Group Policy, you must assign the required computers the correct permissions to acquire the certificate templates. The computers must have Read and Enroll permissions for each certificate template they require. Finally, you must configure at least one Enterprise CA in the forest to issue the required certificate templates.

Designing Manual Issuance

All user certificates, and some computer certificates, must be requested manually from a CA. If the issuing CA is an Enterprise CA, the request can be performed either from the Certificates MMC snap-in or from the Certificate Services Web registration page. If the issuing CA is a Standalone CA, you can use only the Certificate Services Web registration page.

You can't automatically assign user certificates. Users must be trained to perform the certificate request themselves. In most cases the certificate administrators need to create documentation that walks the user through the process of acquiring the certificate.

As with automatically assigned computer certificates, you must set permissions for each certificate template to ensure that only authorized security principals have Read and Enroll permissions for all manually registered certificates. In addition, you must designate a CA to issue the required certificate templates.

Making the Decision

Use the decision matrix shown in Table 10.7 when planning the issuing of certificates.

Table 10.7 Planning Certificate Issuance

To Do the Following
Restrict access to specific templates Configure the Discretionary Access Control List (DACL) for each template in Active Directory Sites And Services so that only the required security principals have the Enroll and Read permissions for the desired template.
Restrict which CA issues a specific certificate template Configure the list of certificate templates that a CA issues. You configure the list of certificate templates in the Certification Authority console in the Policy Settings container.
Automate the deployment of computer certificates Configure Group Policy to automatically assign the necessary computer certificates by adding the certificate template to the Automatic Certificate Request Settings option in Group Policy.
Issue certificates to users Configure documentation on how to request a user certificate using the Web-based interface. This requires connecting to the CA server using the following URL: http://CAName/certsrv/.

You can use the URL to request certificates from both Enterprise and Standalone CAs.

Configure documentation on how to request a user certificate using the Certificates MMC console. You can use the MMC console only to request certificates from an Enterprise CA.

Configure documentation on how to request a certificate using the Web-based interface. This requires connecting to the CA server using the following URL: http://CAName/certsrv/.

Configure documentation on how to request a certificate using the Certificates MMC console.

Require a certificate administrator to approve or reject each certificate request Use a Standalone CA with the issuance policy configured to require a certificate administrator to approve or reject each certificate request.

Applying the Decision

Blue Yonder Airlines must develop an issuance policy for all internal certificates required on the network. Separate strategies are required for Computer certificates and User certificates.

For Computer certificates, Blue Yonder Airlines can take advantage of Group Policy. The computers require either IPSec-specific certificates, or they can use the multipurpose Computer certificates for IPSec authentication. To provide these certificates to all computers in the domain, configure the Default Domain Policy to issue both IPSec and Computer certificates by defining the Automatic Certificate Request Settings policy.

There's no way to issue certificates to internal users automatically. Blue Yonder Airlines must decide how to issue User certificates for internal users. The company can choose to use either the Web-based forms or the Certificates MMC console.

For external customers, Jenny Sax will make all certificate requests. Planning to request the necessary smart card certificates is discussed in Lesson 3, "Using Certificates for Authentication."

Planning Certificate Revocation

Sometimes you have to revoke a certificate before its expiration date. Reasons for the revocation may include termination of the employee, a compromise of the issuing CA, or dissolution of a partnership between organizations.

Your PKI deployment design must include considerations for certificate deployment. Just because a certificate has been revoked doesn't mean that the certificate is instantly unusable. When you revoke a certificate, the certificate's serial number is added to the Certificate Revocation List, as shown in Figure 10.18.

click to view at full size.

Figure 10.18 A certificate revocation list

When an application needs to verify a certificate, the application downloads the CRL referenced in the certificate to the client's local cache. The CRL won't be downloaded again until the lifetime of the downloaded CRL expires. This fact is an important design point. If you foresee frequent certificate revocations, you should shorten the publication period to minimize the time in which clients may have outdated CRLs in their cache. You can minimize the time by reducing the interval for publication of the CRL to a distribution point. Don't reduce the interval too much or the updated CRL will generate excess traffic. Consider implementing shorter duration CRL publication intervals only for CRLs that are frequently modified. If there's little modification, you can use longer publication intervals.

Another issue you must include in your CRL design is the CRL's availability. If the server hosting the CRL is unavailable, a client won't be able to access the CRL. In this case the client application will treat the certificate as if its status is set to be revoked. The client will be unable to use the certificate for authentication purposes until the CRL is available. When designing offline CAs, configure CRL distribution points that are always available on the network.

Making the Decision

Consider the following factors when planning CRL availability for the CAs in your organization:

  • Create a central location for offline CA CRLs. Due to the removal of the CA from the network, the default locations for the CRLs won't be available. Use both the Capolicy.inf file (for root CAs) and the CDP configuration for subordinate CAs to change the publication point to an area of the network that's always available.
  • Determine the optimal publication schedule for the CRL associated with a CA. If the CA has issued several certificates and the revocation process occurs frequently, publish the CRL on a more frequent schedule than the default of one week. For example, it may be more secure to publish the CRL every four hours. Likewise, for a root CA that only has two subordinate CAs, it may be better to publish the CRL every three months. You only have to worry about clients using an out-of-date cached version of the CRL when the CRL is actually changing.
  • Ensure availability of the CRL. If you have Active Directory available on the network, ensure that each CRL includes an LDAP publication point. The CRL then is available from any domain controller in the forest. CRLs are stored in the configuration naming context, which is replicated to all domain controllers in the forest. Also be sure to include additional URLs for the CRL. You can define both HTTP and FTP URLs.
  • Ensure that CRLs are available to external clients if they receive certificates from the internal network. If clients are to authenticate by using certificates issued by an internal CA, ensure that the CRL is published to an externally available resource. Consider using either HTTP or FTP publication points for the CRL to ensure external availability. Remember that if the CRL is unavailable, the application may treat the certificate as if it's revoked.
  • Ensure that all necessary CRLs are available. Not only must the CRL for the CA that issued the certificate be available, but the CRL for each CA in the chain back to the root CA must be available to ensure that none of the CA's certificates are revoked. If any part of the CA chain doesn't have its CRL available, the certificate may be rejected.

Applying the Decision

Blue Yonder Airlines must ensure that the CRLs for all CAs related to the Enrollment CA are available. For smart card users, this requires the CRL for the Blue Yonder Root CA, the Customers CA, and the Smartcards CA to be available at the public Web site to ensure that CRL checking proceeds as required, as illustrated in Figure 10.19.

click to view at full size.

Figure 10.19 Designing CRL availability for Blue Yonder Airlines

Because the CRLs are published to a public location, some of the CRLs may have to be copied manually to the CRL distribution point (http://ww.blueyonder.tld/Certificates/).

For the root CA, the publication interval should be infrequent. A range of three to four months may be sufficient. There are only two subordinate CAs below the root CA, and the chances of these certificates being revoked is minimal. Likewise, the publication schedule for the Customers CA doesn't have to be updated frequently—every two to three months would be sufficient.

The Smartcards CA requires more frequent publication. According to the scenario, the CRL must be updated every four hours to ensure that a revoked certificate is recognized quickly. Permissions must be defined on the external Web server to ensure that the CA can update the CRL stored on the Web server.

Planning Certificate Renewal

All certificates have a finite lifetime defined by the issuing CA. For Windows 2000 CAs, this lifetime value is defined by editing the registry. Two registry values define the lifetime for all issued certificates:

  HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\CAName\ ValidityPeriod: REG_SZ (values include Years, Days, Hours) ValidityPeriodUnits: REG_DWORD (numeric value) 

When a User certificate or Computer certificate is nearing the end of its lifetime, you must have a strategy for renewing it. In the case of User and Computer certificates, you can renew the certificate from the Certificates MMC console, as shown in Figure 10.20.

click to view at full size.

Figure 10.20 Renewing user and computer certificates with the same keys or with new keys

When you renew the certificate, you can either reuse the same private and public key or generate new private and public keys. For the highest security, you should always generate new private and public keys. Reuse the existing private and public key only if you're rebuilding a CA and don't wish to invalidate all issued certificates by changing the private key used to sign each issued certificate.

For CAs, you renew the CA certificate in the Certification Authority console, as illustrated in Figure 10.21.

click to view at full size.

Figure 10.21 Renewing CA certificates in the Certification Authority console

The process varies depending on whether the CA that issued the certificate is online or offline. If the issuing CA is online, you can send the certificate renewal request directly to the issuing CA. If the issuing CA is offline, you must save the certificate request to a certificate request file and manually transport it to the offline CA.


You should set the lifetime for CA and SubCA certificates significantly longer than the lifetime of other certificate templates. An issuing CA can't issue certificates with a lifetime that exceeds the remaining lifetime of the CA's certificate. You must include this factor in the certificate renewal design for your organization's CAs. You may wish to renew CA certificates earlier than user or computer certificates to ensure that the CA certificate lifetime doesn't affect the lifetime of any issued certificates.

Making the Decision

Consider the following design decisions when designing a renewal policy for certificates issued within your organization:

  • Define certificate lifetimes based on renewal requirements. CA certificates generally have a longer lifetime than the certificates they issue. In general, CAs located closer to the root CA require longer lifetimes. You define the certificate lifetimes either during the installation of the root CA, in the Capolicy.inf for root CA renewal, or in the individual CA's registry settings.
  • Define a process that users and computers will use to renew their certificates. User and computer certificates must be renewed in the Certificates MMC. Develop a plan for training users how to renew the certificates.
  • Ensure that the CA certificate's remaining lifetime is never shorter than the lifetime for issued certificates. You can't issue certificates with a lifetime greater than the remaining lifetime of the issuing CA's certificate. If the CA's certificate were to expire, you couldn't verify the digital signature on the issued certificates, and this would invalidate all issued certificates.
  • Plan for renewal dates far in the future. A well-planned PKI deployment defines how certificates will be renewed to avoid confusion as the renewal date approaches. By being proactive in the design of certificate renewal, you can ensure that the process takes place with little or no effect on the users and computers involved.

Applying the Decision

Blue Yonder Airlines must perform a few tasks involved with certificate renewal. The first is defining the certificate lifetimes for each issuing CA.

Install the root CA with the longest lifetime to ensure that the root CA doesn't limit the lifetime of any certificates issued by CAs lower in the CA hierarchy. For example, you could configure the root CA with a 10-year validity period and configure the subordinate CAs, the Internal, and Customers CA (as shown in Figure 10.16) with a 5-year validity period.

If you use this design, the root CAs certificate should be renewed before the initial five years. This ensures that the remaining certificate validity period on the root CAs doesn't affect the validity period for certificates issued by the subordinate CAs.

The issuing CAs for Blue Yonder Airlines require varying validity periods. The Smartcards CA probably requires the shortest period, which forces the customers to stay in touch with Blue Yonder Airlines and renew their Smart Card certificates frequently.

For the internal network, develop a plan for when certificates must be renewed. The plan should also include a defined process that details how the renewal takes place and sets the renewed validity period for the renewed certificate.

Lesson Summary

To ensure that security is maintained for the enrollment, revocation, and renewal processes, you must carefully define the management functions associated with a CA. All three processes make up the lifetime of a digital certificate. Your plan must ensure that only authorized security principals can acquire certificates from your CAs. If you revoke a certificate, make sure that the delay between the revocation process and the publication of the CRL is acceptable in your business operations. Finally, avoid allowing issued certificates to expire when the validity period ends. By planning a process for certificate renewal, you can ensure that newly established PKIs will continue to be used.

Microsoft Corporation - MCSE Training Kit (Exam 70-220. Designing Microsoft Windows 2000 Network Security)
MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)
ISBN: 0735611343
EAN: 2147483647
Year: 2001
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net