The Shift To Short-Lived Certificates
Managing Public Key Infrastructure (PKI) is transitioning from a periodic maintenance task to a continuous operational requirement.
The Google Chrome team introduced a proposal titled "Moving Forward on the Web's PKI" which outlines a strategy to reduce the maximum validity period of TLS certificates.
The roadmap suggests a reduction from the current 398-day limit to 90 days, with a subsequent target of approximately 47 days.
This change follows a historical trend; in 2017, certificates were valid for three years, which was reduced to two years, and then to the current 398-day limit following CA/Browser Forum discussions and Apple's 2020 policy change.
WARNING
Manual certificate management is no longer a viable strategy. Attempting to manage a 47-day lifecycle using spreadsheets and manual CSR generation will lead to frequent service disruptions.
Drivers For Shorter Validity Periods
The primary motivation for this shift is the enhancement of the "window of exposure" security model.
If a private key is compromised or a Certificate Authority (CA) issues a certificate in error, the duration for which that certificate is valid determines the maximum time an attacker can exploit it.
Shorter lifespans limit this window significantly. According to the Google Trust Services roadmap (2023), the objective is to promote cryptographic agility.
Cryptographic agility is the ability of an organization to rapidly rotate keys and update encryption standards across the entire environment.
If a vulnerability is discovered in a specific algorithm, such as RSA or ECC, organizations must be able to migrate to new standards without waiting over a year for existing certificates to expire.
Furthermore, shorter lifespans encourage the adoption of automation.
When certificates expire every 47 days, the operational overhead of manual renewal becomes unsustainable for even small environments.
The industry is effectively using policy to mandate the adoption of the ACME protocol (RFC 8555).
The Limitations Of Manual Tracking
Many organizations rely on a "Spreadsheet of Truth" to track certificate expirations.
This method is inherently flawed because it relies on human input and periodic audits.
In a dynamic environment where developers frequently spin up new cloud instances or Kubernetes clusters, manual inventories quickly become outdated.
A certificate might be provisioned for a temporary development environment that eventually matures into a production dependency without being added to the central registry.
IMPORTANT
Automation moves the point of failure from the expiration date to the renewal date. This allows teams to troubleshoot renewal issues while the service is still functional.
When a 90-day certificate fails to renew at the 60-day mark, the IAM team has 30 days to resolve the issue before an outage occurs.
In a manual system, the team often only discovers the issue once the certificate has already expired and the site is down.
Understanding The ACME Workflow
The Automated Certificate Management Environment (ACME), defined in RFC 8555, is the standard for automating issuance and renewal.
It uses a challenge-response mechanism to prove domain ownership.
The two most common challenge types are HTTP-01 and DNS-01.
HTTP-01 requires the ACME client to place a specific file on the web server, which the CA then fetches over port 80.
DNS-01 requires the client to create a specific TXT record in the domain's DNS zone.
DNS-01 is generally preferred for internal environments or for issuing wildcard certificates, as it does not require the server to be reachable from the public internet.
graph TD A["Application Server"] -->|"1. Initiate ACME Request"| B["ACME Client"] subgraph VALIDATION_PROCESS ["Validation Process"] B -->|"2. Create DNS TXT Record"| C["DNS Provider"] C -->|"3. Query TXT Record"| D["Certificate Authority"] end D -->|"4. Issue Certificate"| B B -->|"5. Install Cert & Reload"| E["Web Service"] subgraph MONITORING ["Monitoring"] E -->|"6. Heartbeat Check"| F["Observability Tool"] end
Technical Failure Modes In Automation
Automation is not a "fire and forget" solution; it introduces its own set of failure modes that practitioners must manage.
One common failure mode is DNS propagation delay.
If an ACME client attempts to trigger a CA validation before the DNS TXT record has propagated across all global nameservers, the validation will fail.
Another failure mode is rate limiting.
Public CAs like Let's Encrypt enforce rate limits on certificate issuance to prevent abuse.
If an automated script enters a failure loop and repeatedly requests certificates, it may be blocked, preventing legitimate renewals for other services.
TIP
Always implement a "graceful reload" in your automation scripts. Simply replacing the certificate file on disk is insufficient; the service (Nginx, HAProxy, IIS) must be notified to load the new certificate into memory.
Organizational Preparation
Transitioning to a 47-day lifecycle requires a shift in how IAM and Network teams collaborate.
The first step is a comprehensive discovery phase.
You must identify every certificate in use, including those on load balancers, firewalls, IoT devices, and internal microservices.
Tools like Nmap or specialized PKI scanners can help locate certificates by scanning common ports (443, 8443, 636).
Once discovered, certificates should be categorized by their ability to support automation.
Modern web servers and cloud-native applications are easy to automate using ACME.
Legacy appliances or proprietary hardware may require custom scripts or the use of a centralized Certificate Management System (CMS) that interacts with the device's API.
Vendor Solutions For Certificate Lifecycle Management
Different environments require different tooling approaches.
The following tools are directly relevant to managing the transition to shorter certificate lifespans.
Cert-manager
Strengths
Cert-manager is the industry standard for Kubernetes environments. It natively supports ACME and integrates with a wide variety of CAs and DNS providers. It treats certificates as standard Kubernetes resources, allowing developers to request them via YAML manifests.
Limitations
Troubleshooting cert-manager requires a deep understanding of Kubernetes controller logic. If the underlying custom resource definitions (CRDs) are misconfigured, it can be difficult to determine why a renewal is stuck without digging through controller logs.
Venafi Control Plane
Strengths
Venafi is designed for large-scale enterprise environments that need to manage thousands of certificates across hybrid cloud and on-premises infrastructure. It provides strong policy enforcement, ensuring that all issued certificates meet corporate standards for key length and algorithm type. It offers extensive reporting capabilities that are useful for compliance audits (ISO/IEC 27001:2022).
Limitations
The platform is complex and requires significant initial investment in both licensing and configuration. It may be over-engineered for smaller organizations that only have a few dozen certificates to manage.
Smallstep
Strengths
Smallstep is an excellent choice for internal PKI and dev-to-dev communication. It allows organizations to run their own private CA that supports the ACME protocol. This makes it possible to use the same automation workflows for internal services as you do for public-facing websites.
Limitations
Managing a private CA carries significant responsibility. If the root private key for your Smallstep instance is compromised, the entire internal trust chain is invalidated. It requires a solid understanding of PKI fundamentals to operate securely.
Key Takeaways For Practitioners
The shift to 90-day and 47-day certificates is an operational reality driven by the need for higher security standards.
Organizations must move away from reactive, manual processes toward proactive, automated lifecycles.
- Standardize on ACME: Use RFC 8555 compliant tools whenever possible to ensure interoperability.
- Implement Centralized Monitoring: Use tools to monitor the actual expiration date of certificates from the outside-in, rather than relying on a database.
- Automate the Reload: Ensure that your automation pipeline includes the necessary steps to restart or reload services after a certificate is updated.
- Shorten TTLs Early: Begin reducing the validity period of your internal certificates now to identify which systems are unable to handle frequent changes.
By treating certificates as ephemeral credentials rather than long-term assets, organizations can significantly reduce their attack surface and improve their overall security posture.
The transition will be difficult for those with technical debt, but it is a necessary step for modern identity and access management.
Focus on building a resilient automation pipeline that can handle renewals every few weeks without human intervention.
This approach not only satisfies upcoming industry requirements but also eliminates the single most common cause of TLS-related outages: human error.