Managing the private CA lifecycle

CA certificates have a fixed lifetime, or validity period. When a CA certificate expires, all of the certificates issued directly or indirectly by subordinate CAs below it in the CA hierarchy become invalid. You can avoid CA certificate expiration by planning in advance.

Choosing validity periods

The validity period of an X.509 certificate is a required basic certificate field. It determines the time-range during which the issuing CA certifies that the certificate can be trusted, barring revocation. (A root certificate, being self-signed, certifies its own validity period.)

AWS Private CA and AWS Certificate Manager assist with the configuration of certificate validity periods subject to the following constraints:

• A certificate managed by AWS Private CA must have a validity period shorter than or equal to the validity period of the CA that issued it. In other words, child CAs and end-entity certificates cannot outlive their parent certificates. Attempting to use the IssueCertificate API to issue a CA certificate with a validity period greater than or equal to the parent's CA fails.

• Certificates issued and managed by AWS Certificate Manager (those for which ACM generates the private key) have a validity period of 13 months (395 days). ACM manages the renewal process for these certificates. If you use AWS Private CA to issue certificates directly, you can choose any validity period.

The following diagram shows a typical configuration of nested validity periods. The root certificate is the most long-lived; end-entity certificates are relatively short-lived; and subordinate CAs range between these extremes.

When you plan your CA hierarchy, determine the optimal lifetime for your CA certificates. Work backwards from the desired lifetime of the end-entity certificates that you want to issue.

End-entity certificates

End-entity certificates should have a validity period appropriate to the use case. A short lifetime minimizes the exposure of a certificate in the event that its private key is lost or stolen. However, short lifetimes mean frequent renewals. Failure to renew an expiring certificate can result in downtime.

The distributed use of end-entity certificates can also present logistical problems if there is a security breach. Your planning should account for renewal and distribution certificates, revocation of compromised certificates, and how quickly revocations propagate to clients that rely on the certificates.

The default validity period for an end-entity certificate issued through ACM is 13 months (395 days). In AWS Private CA, you can use the IssueCertificate API to apply any validity period so long as it is less than that of the issuing CA.

Subordinate CA Certificates

Subordinate CA certificates should have significantly longer validity periods than the certificates they issue. A good range for a CA certificate's validity is two to five times the period of any child CA certificate or end-entity certificate it issues. For example, assume you have a two-level CA hierarchy (root CA and one subordinate CA). If you want to issue end-entity certificates with a one-year lifetime, you could configure the subordinate issuing CA lifetime to be three years. This is the default validity period for a subordinate CA certificate in AWS Private CA. Subordinate CA certificates can be changed without replacing the root CA certificate.

Root Certificates

Changes to a root CA certificate affect the entire PKI (public key infrastructure) and require you to update all the dependent client operating system and browser trust stores. To minimize operational impact, you should choose a long validity period for the root certificate. The AWS Private CA default for root certificates is ten years.

Managing CA succession

You have two ways to manage CA succession: Replace the old CA, or reissue the CA with a new validity period.

Replacing an old CA

To replace an old CA, you create a new CA and chain it to the same parent CA. Afterward, you issue certificates from the new CA.

Certificates issued from the new CA have a new CA chain. Once the new CA is established, you can disable the old CA to prevent it from issuing new certificates. While disabled, the old CA supports revocation for old certificates issued from the CA, and, if configured to do so, it continues to validate certificates by means of OCSP and/or certificate revocation lists (CRLs). When the last certificate issued from the old CA expires, you can delete the old CA. You can generate an audit report for all of the certificates issued from the CA to confirm that all of the certificates issued have expired. If the old CA has subordinate CAs, you must also replace them, because subordinate CAs expire at the same time or before their parent CA. Start by replacing the highest CA in the hierarchy that needs to be replaced. Then create new replacement subordinate CAs at each subsequent lower level.

AWS recommends that you include a CA generation identifier in the names of CAs as needed. For example, assume that you name the first generation CA “Corporate Root CA." When you create the second generation CA, name it “Corporate Root CA G2." This simple naming convention can help avoid confusion when both CAs are unexpired.

This method of CA succession is preferred because it rotates the private key of the CA. Rotating the private key is a best practice for CA keys. The frequency of rotation should be proportional to the frequency of key use: CAs that issue more certificates should be rotated more frequently.

Note

Private certificates issued through ACM cannot be renewed if you replace the CA. If you use ACM for issuance and renewal, you must re-issue the CA certificate to extend the lifetime of the CA.

Reissuing an old CA

When a CA nears expiration, an alternative method of extending its life is to reissue the CA certificate with a new expiration date. Reissuance leaves all of the CA metadata in place and preserves the existing private and public keys. In this scenario, the existing certificate chain and unexpired end-entity certificates issued by the CA remain valid until they expire. New certificate issuance can also continue without interruption. To update a CA with a reissued certificate, follow the usual installation procedures described in Creating and installing the CA certificate.

Note

We recommend replacing an expiring CA rather than reissuing its certificate because of the security advantages gained by rotating to a new key pair.

Revoking a CA

You revoke a CA by revoking its underlying certificate. This also effectively revokes all of the certificates issued by the CA. Revocation information is distributed to clients by means of OCSP or a CRL. You should revoke a CA certificate only if you want to revoke all of its issued end-entity and subordinate CA certificates.