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
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.
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.
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.
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.
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.
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. |
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."
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.
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.
Consider the following factors when planning CRL availability for the CAs in your organization:
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.
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.
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.
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.
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.
IMPORTANT
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.
Consider the following design decisions when designing a renewal policy for certificates issued within your organization:
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.
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.