Certificate Lifecycle Management
Best Practices for Certificate Authority (CA) Certificates Renewal

Certificate Lifecycle Management
In the Public Key Infrastructure (PKI) environment, Certificate Authorities (CAs) are the most important components that act as the source of security and integrity of digital communications. Renewal of Root and Issuing Certificate Authorities (CAs) is a critical process that ensures continuity and security in digital identity management.
In this blog, we will learn the best practices for renewing Root and Issuing CAs, including considerations for CA lifetimes, Certificate Revocation List (CRL) publication timelines, and other key considerations.
Before diving into the renewal process, let’s have a quick look at the roles of Root and Issuing CAs:
Before deep diving into the CA renewal strategy, let’s understand what Certificate Revocation List (CRL), Distribution point (CDP), and Authority Information Access (AIA)
In simple language, Certificate Authority (CA) Certificate Renewal involves generating a new CA certificate before the existing certificate expires. This process is necessary for a seamless transition and continuity of trust. While renewing a certificate, it is always recommended that a new key pair be generated for the new certificate.
When you design your PKI Hierarchy, it is also important that you define the CA lifetime. The lifetime determines how long a CA can issue certificates before they need to be renewed. Below are some best practices for determining CA lifetimes:
Ensure the renewed Root CA and Issuing CA certificates use strong cryptographic algorithms such as (RSA 4096 or Post Quantum Cryptographic (PQC) algorithms as recommended by NIST).
Validate compliance with Industry standards and best practices such as NIST SP 800 57 and FIPS 140-2/ 140-3.
The table below is an example, which lists the key lengths, lifetimes, and renewal strategies for the CA certificates for a two-tier PKI hierarchy.
CA Name | Algorithms/Key Length | Certificate Validity | Renewal Strategy |
Root CA | SHA256, RSA/4096 bit | 10 years | Renewal after 5 years to issue certificates to the Issuing CAs. |
Issuing CA 1 | SHA256, RSA/4096 bit | 5 years | Renewal after 2 years to issue end-entity certificates. |
Issuing CA 2 | SHA256, RSA/4096 bit | 5 years | Renewal after 2 years to issue end-entity certificates. |
Each certificate has a defined validity period, after which the certificate is no longer considered valid. In some cases, the organization may need to invalidate (revoke) certificates prior to the end of their validity period. This need may be due to the key being lost or compromised, the relationship with the subject end, or simply the certificate being superseded with a new one before the expiration date.
CRLs are files signed by a CA that contain a list of certificate serial numbers that have been revoked. Clients download CRLs to check the validity of a certificate. The Microsoft Crypto API caches retrieved CRLs until the next CRL update time. Therefore, clients may not recognize out-of-band updates of CRLs that are published before the next CRL update time.
In this situation, Delta CRLs are recommended. Delta CRLs are issued between publications of the full (or base) CRLs and contain only the certificates that have been revoked since the last CRL publication. A client computer can thus combine the base CRL and the latest delta CRL to determine the revocation status of the certificate, thereby reducing the impact on the network infrastructure.
Certificate Revocation Lists (CRLs) are used to inform users about certificates that have been revoked before their expiration date. Proper management of CRLs is important for maintaining the security of the PKI.
The CRL publication interval must be determined by considering the certificate trust requirements and the impact created across the network infrastructure. A more frequent CRL publication schedule allows short-term certificate revocation, which can be beneficial for authentication certificates. However, this also increases network traffic and administrative overhead, affecting system uptime and recovery timeframes.
In addition to the publication interval, another parameter that affects the validity period of a CRL is the overlap period. The overlap period is the time interval between the next scheduled publication time and the actual expiration of the CRL. The total CRL validity period is equal to the sum of the CRL publication interval and the overlap period. The same concept applies to delta CRLs.
The below figure illustrates the relationship between the CRL publication interval and the overlap period. Having a publication interval of 5 days (B) and an overlap period is set to 3 days, giving a total validity period of 8 days (C).
The total CRL validity period is equal to the sum of the CRL publication interval and the overlap period. The same concept applies to delta CRLs.
CA Name | Certificates Issued By CA | CRL Publication Interval | CRL Overlap Period |
Root CA | Issuing CA certificates | 1 Year | 1 month |
Issuing CA1 | Issuing machine certificates | 5 days | 3 days |
Issuing CA2 | Issuing user certificates | 5 days | 3 days |
Certificate revocation information needs to be reachable by any client computer that relies on the certificates for trust. This information should be readily available whenever a certificate status needs to be verified. To meet these requirements, multiple Certificate Distribution Points (CDPs) are usually defined to distribute the CRLs. These CDPs use internal and external (internet) URLs and, often, different access protocols such as http://and LDAP.
The AIA extension is a pointer to CA’s most currently published CA certificate. The AIA extension helps client computers find CA certificates dynamically during chain building. The Windows PKI implementation uses this extension to assist in the building of trust chains to validate certificates. The major advantage is that only the root CA needs to be trusted; all the sub-CA certificates are retrieved from the AIA locator to build the certificate chain.
Proper documentation and communication are essential for a smooth CA renewal process. It is recommended that the entire CA renewal process be documented, including key generation, certificate issuance, CRL publication, and end-entity certificate re-issuance. This documentation should be detailed and include step-by-step instructions. Communicate the renewal plan with all stakeholders, including IT teams, security teams, and relying parties. Ensure that everyone is aware of the timeline and any potential impact on services. Before executing the renewal process in production, test it in a staging environment. This testing helps identify any issues and ensures that the process runs smoothly in production.
Continuous monitoring of the publication of CRLs to ensure that CRLs are being published on time and that clients can access them. Any delays or failures in CRL publication should be investigated and resolved promptly.
With Regular audits, the PKI ensures that it complies with security policies and industry standards. The audit should cover key management, certificate issuance, CRL publication, and other aspects of PKI operations.
It is also recommended and essential to log all activities related to the CA, including certificate issuance, revocation, and renewal. Regularly review these logs to detect any suspicious activities or potential security incidents.
Encryption Consulting LLC (EC) can help you automate the certificate lifecycle management process by deploying CertSecure Manager – a certificate lifecycle management solution in your environment to track and automate the CA renewals. CertSecure Manager can be integrated with ITSM tools like ServiceNow for automated alerts and renewal workflows.
The renewal of Root and Issuing CAs is a critical process in PKI management. By following the best practices outlined in this blog, organizations can ensure that their PKI remains secure, compliant, and resilient against evolving threats. Proper planning, automation, and communication are key to a successful CA renewal process. Additionally, staying up-to-date with cryptographic advancements and continuously monitoring the PKI will help maintain the trust and integrity of digital communications.
February 6, 2025
December 24, 2024