Design PKI Certificate Services – Part 2

Pls check Part 1 to get more information about those posts. We are about to design the CRL publication for Contoso PKI Deployment project.

Determining Publication Points /Intervals

 

CRL Publication

When any application, user, or process validates a certificate, it makes sure that the certificate chains to a root that is trusted on that system, is time-valid, and contains the specific functional capabilities for which it is being presented. If all of these checks pass, the certificate is considered valid.

The CRL is checked to make sure that certificates that otherwise would be considered valid have not been revoked. The CRL itself is a file, signed by the CA, which contains a list of revoked certificates. The list defines the revoked certificates by serial number, and it includes the revocation date in addition to the reason for revocation. The application that is performing the certificate validation determines whether or not it checks for revoked certificates as part of the validation process. When an application checks for revoked certificates, it retrieves the current CRL from one of the URLs specified in the CDP extension of the certificate being validated. After the CRL is retrieved, it is typically cached until its expiration. After a CRL is cached, the application performs further revocation checks against this cached copy, eliminating the need to retrieve the CRL for each revocation check. When expired, the CRL itself becomes invalid, forcing the download of a new CRL

The following protocols can be used when defining publication points:

  • LDAP URLs
  • HTTPS URLs
  • FTP URLs
  • File URLs

The decision as to which protocols to implement for CRL or CA certificate publication depends on the frequency at which URLs are published, the protocols allowed to traverse network firewalls, and the network’s operating systems. To ensure maximum availability, the URLs should be ordered so that the most common protocol used for CRL or CA certificate retrieval is listed first in the CDP extension. Other protocols are then listed in their order of usage. Usually the certificate-chaining engine will try to access the first URL in the list and will time out after 30 seconds, and then will move to the next URL in the list. So the ordering is very important.

Since the PKI solution to be implementing is aimed to serve the internal network, LDAP URL will be listed first and then an HTTP URL..External Accessible HTTP URL should be implemented to meet possible external (partners) needs

 

Notes:

  • CRLs should not be published to Active Directory when the CRL publication period is shorter than the replication convergence time for the Active Directory forest. Because of this, CRLs publication period should be longer than one day.
  • ldap:///CN=,CN= means the closest domain controller.

CRL Lifetime

For Issuing CAs ,it is a recommendation to have different CRL life time depending on the recipient of the certificate. For example, Microsoft IT configured the CRL lifetime to be 24 hours for the user CAs, and one week for the e-mail and computer CAs. The purpose of the differential was to balance the need for timely CRL updates if a certificate needed to be revoked, while minimizing the performance impacts of frequent CRL retrieval and directory replication. With the revocation of a user authentication certificate, Microsoft IT wanted the revocation status to take effect as quickly as possible. Because a CRL is cached until it expires, short expiration would ensure timely CRL updates that would reflect current revocation status more quickly.

This works fine if there is a separate issuing CA for users and other certificate recipient. But in Contoso Network, the same CA will issue certificates for all Certificate Recipients. Because of this, the lifetime for CRL will be a week for the issuing CA. To solve the issue of the recommendation of having low value CRL lifetime for user certificates, the user account will be disabled instead of depending on the revocation of his certificate.

CRL publishing for the offline CAs is a manual process. The CRL lifetime for the offline CAs at Microsoft is 90 days .In Contoso Network it will be 6 months.

Delta CRLs will be disabled on RootCA as a best practice and will be enabled on the issuing CA servers to avoid downloading the whole Base CRL and to have more recent revocation information. The client will start by downloading a Base CRL and then will download delta CRLs when published until the next Base CRL is published.

Delta CRL publication period will be every two days on Issuing CAs and disabled for the root CA. Thus, two Delta CRLs will be available between two Base CRL publications.

CRL Lifetime overlap 

A CRL has an established lifetime, and a new CRL must be published before the old CRL expires. There is a buffer included in the CRL publication interval to define a specific amount of time for which existing CRLs will remain valid after the next scheduled CRL publication. The purpose of this overlap period is to provide time for manual publication and replication of the newly created CRL prior to the expiration of the original CRL, and to avoid leaving a gap in the availability of a valid CRL. The default overlap period is 10 percent of the CRL lifetime period, with a maximum of 12 hours.

When Microsoft IT decided to publish a new CRL every 24 hours, the default overlap period was reduced to just 2.4 hours. Because this period did not provide sufficient time for replication of the new CRL throughout Microsoft IT‘s worldwide enterprise, before the previous CRL expired, Microsoft IT needed to manually configure the CRL overlap to extend the validity period. The extended period ensured that the old CRL would remain valid while the new CRL was being replicated throughout the network.

Three values define the CRL publication:

  • CRL Period
  • CRL Overlap
  • ClockSkewMinutes

 

The CRL lifetime and publication interval are, though closely related, not the same. The CRL lifetime is deducted from the publication interval and is by default 10 percent longer than its publication schedule. This enables Windows clients to deal with the replication delay of CRLs that are published in Active Directory. The CRL overlap can be set in the registry by using the CRLOverlapPeriod, CRLOverlapUnits, and Clockskewminutes parameters, which are located in the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \CertSvc \Configuration<CA Name>\ registry hive.

For example, imagine you have to deal with a replication delay of four hours. In this case, it would be wise to set the overlap period to five hours. The CRL lifetime resulting from the registry settings (in the list that follows) would be one week, five hours, and 10 minutes, because it is the sum of CRLPeriod, CRLOverlapPeriod, and Clockskewminutes.

CRLPeriod

REG_SZ = Weeks

CRLPeriodUnits

REG_DWORD = 1

CRLOverlapPeriod

REG_SZ = Hours

CRLOverlapUnits

REG_DWORD = 5

ClockSkewMinutes

REG_DWORD = a

Setting the CRLOverlapUnits parameter in the registry to 0 activates the default algorithm for the calculation of the CRL overlap, mentioned previously (10% of publication schedule).

In Contoso Network, the default CRL overlap will do the needful since the whole active directory domain controller will get the new published CRL before the 12 max hours are over.

 Determining Certificates Key Length

Normally, a key size of 4096 would be recommended for security reasons, especially for the root CA. However this may create all sorts of incompatibility problems with for example Cisco based network products (depending on what version of Cisco IOS is being used). This is due to the fact that many 3rd party products have problems handling key sizes larger than 2048. And since network equipment can be integrated in solutions such as 802.1x for validation and compliance, key size will matter.

For this reason the Key length will be as follow:

  • RootCA :  4096
  • Issuing /Policy : 2048

Revocation Policy

Before certificates are enrolled, the PKI management team should know how to revoke certificates. Any X.509 V3 certificate (except the root CA certificate itself) should have a pointer to a valid CRL. The CRL distribution point is included in the certificate’s extension and cannot be modified after a certificate is enrolled.

Certificates cannot be revoked for signing or encryption operations anymore. However, they can be used for decryption operations, because the revoked certificates are required for decryption.

If an application is going to verify a certificate against the CRL and no valid CRL is available, the revocation check does not work and the certificate cannot be used for the transaction. If the application has properly implemented CRL checking, no authentication, encryption, or signing is allowed with this certificate until a valid CRL is available again.

The following Points should be verified:

  • CDPs (CRL Distribution Points) should be modified on an offline CAs. It is a common mistake to not modify the default CRL distribution point of an isolated stand-alone CA. Because a root or intermediate CA is typically disconnected from the network, PKI-enabled clients cannot validate the issued certificates against the default CRL distribution point on the CA server. To make a CRL of an offline stand-alone CA publicly available, CRL should be manually published. An online CA on a computer that is joined to an Active Directory domain or forest automatically publishes the CRL to Active Directory so that it can be accessible through LDAP. Alternatively, the CRL can be made available through an HTTP URL that points to a location on a Web server.
  • Relative LDAP CDPs are to be used instead of Fully Qualified LDAP CDPs. Depending on the certificate types that are issued with a CA, the order of the CRL distribution points is important. For authentication certificates, it is beneficial to have a CRL or fully-qualified LDAP CRL distribution point as the first entry in the list of distribution points. If a relative LDAP CRL distribution point is specified, a client contacts the domain controller that is closest, according to the Active Directory site structure, to get the CRL. Fully-qualified LDAP CRL distribution points eliminate latency issue that may occur until the CRL has been replicated in Active Directory. For non-authentication certificates, you may want to use LDAP because LDAP is more fault-tolerant in an Active Directory environment compared to tolerance in a single-instance HTTP server. Because of the nature of Contoso Network and Firewall rules applied, relative LDAP CDPs are to be used.
  • HTTP CRLs are to be used next. It is also an option to set both an LDAP and HTTP CRL distribution point URL to support clients that are Active Directory-aware, as well as clients that are not running Windows and that are not Active Directory-aware. This is also important in situation of mutual project with a partner that need to access a PKI enabled application at our side.
  • CA Root Certificate Revocation. Since a root CA certificate has no parent CA that could maintain the CRL, there is no need to specify a CRL distribution point for the root CA certificate itself. To revoke a root CA, all certificates that have been issued by the root CA must be revoked instead. The following Points should be noticed :
    • Offline CAs must continue to publish CRLs
    • A root CA certificate should have an empty CRL distribution point
  • Publishing CRLs. If certificates are exchanged with external entities, the CRLs must be available at a location that is accessible for all internal and external entities. To satisfy this requirement, in this case the CRL is usually published in the organization’s perimeter network.

 

Security Measures

Different approaches may be applied through physical or technical protection techniques as described below:

  • Keeping the Root CA disconnected from the network. RootCA will be hosted in Microsoft Virtual server .The virtual machine image will kept on secure protected place in the Contoso main data center with a copy in the disaster recovery data center.
  • Disable any un-needed services hosted on the Root CA server.
  • Use a dedicated server to host the offline RootCA.

Enrollment Strategy

Different enrollment strategy is to be implemented depending on the certificate template and purpose of the certificate to be issued. To reduce the total cost of ownership, automatic enrollment for active directory users is the method to be used for user certificates. This means that the issuing policy is depending on the user active directory credential to identify the subject of the certificate requester. This is the initial design measure to be implemented for enrollment strategy.

3 comments on “Design PKI Certificate Services – Part 2

  1. Pingback: Design PKI Certificate Services – Part 1 | Ammar Hasayen - Blog

  2. Pingback: Deploy Offline Root CA in Windows 2012 R2 – SHA-2 Ready | Ammar Hasayen - Blog

  3. Pingback: Design PKI Certificate Services – Part 1 – Azure Mechanics

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s