Certificate Lifecycle Automation: How We Build Automated PKI for Enterprise Environments

Our journey to automated certificate management

We started with peer-to-peer certificates. Then we thought a centralised authority would be cool, so we designed PKI. More recently, the industry started talking about certificate lifecycle management. At Axelspire, we believe even that definition is too narrow for long-term success. When we say long-term, that horizon is shortening fast — from over 10 years to 1–2 years — as browser rules tighten certificate validity periods. This post covers the current state of certificate lifecycle automation and how we implement it.

What Certificate Lifecycle Automation Actually Covers

We have built certificate management several times from scratch for different clients. Over time, we expanded what those implementations cover to include functions we hadn’t thought possible when we started over 20 years ago.

Our latest implementation is automated PKI — or certificate lifecycle automation — which includes a controlled release and automated updates of endpoint agents and integration scripts that allow servers and applications to obtain certificates. It covers the actual issuance of certificates, the downloading of trusted CA certificates (trust stores), and validation services: CRL (certificate revocation lists) and OCSP (online certificate status protocol — a real-time protocol with caching).

All of this runs as a serverless service using AWS Lambda functions, deployed automatically via CI/CD pipelines. There is zero need for human access to the AWS account where this runs. Certificate authorities can be external — your own internal CA, a hosted private CA from GlobalSign, DigiCert, Sectigo, or Entrust — or cloud-native options like AWS Private CA, or a public CA for automating management of public certificates.

The Enterprise Question You’ll Get Asked Immediately

One question you will get quickly once you deploy an automated certificate lifecycle management solution is: what is the criticality of this in the context of your company? Any mature enterprise will want to know the answer from a cybersecurity perspective and as part of vendor onboarding. Our experience is that modular design is the correct approach. We split functional parts into independent components with separate criticality levels.

Divide and Conquer: Structuring Criticality

Splitting certificate lifecycle automation into components not only simplifies enterprise onboarding — it has a long-term positive effect on operational costs.

Mission-critical: Certificate Validation (OCSP/CRL) The highest criticality component is OCSP, which is often managed alongside CRL. Depending on your risk posture, you may require OCSP validation to provide real-time validation for all certificate use. Recovery time is measured in minutes, particularly in regulated industries or sensitive applications.

Business support: Certificate Issuance Certificate issuance can be classified as business support. If it undergoes maintenance or goes down for a day, it will not impact your running business systems. The only consequence is a delayed renewal, which will likely fall within your predefined acceptable parameters — renewal configurations always allow several days for standard renewal runbooks.

Business support: Client Publishing Trust stores, client agents, and documentation updates sit at the same criticality level as issuance but are kept separate. From a change management perspective, you can update these quickly without impacting anything else. The separation is straightforward from a technology standpoint — file publishing runs via separate S3 buckets and Lambda functions.

Automated Key Lifecycle Management: The Security Case

If you design certificate lifecycle management thoughtfully, you achieve a strong level of resilience while aggressively limiting key exposure. For example, renewing certificates every month with a validity of 3–12 months lowers the risk of long-term key compromise, increases the run rate of the PKI and integrations, surfaces issues early, reduces costs, and lowers the risk of failed renewals in production.

The security logic is straightforward. Every new certificate generates a new key, rendering the old key useless. If you hold a certificate for a year and someone steals the private key in month two, the attacker has over ten months to exploit it. Renew that certificate every month and the same theft gives them two weeks. The exposure window shrinks proportionally with certificate validity — and that window is only going to get shorter as validity rules tighten further.

Certificate Validation as an Intelligence Source

Centralising validation services via DNS — having all validation requests served by your automated PKI — provides a valuable intelligence layer, and you can build powerful analytics on top of the traffic data.

Our design uses a single DNS domain for all client-facing services. This allows efficient CI/CD-based software lifecycle management while also providing detailed information about certificate clients. The OCSP service is particularly powerful here: validation requests contain an identifier for the certificate being validated. The traffic data maps your network — showing what relies on a particular server with a certificate issued by your service, and which clients are connecting to which servers.

CRL-based validation is less granular, but it supports operational tuning: you can split issuance across multiple CAs based on client type and use traffic patterns to understand your PKI footprint. This kind of intelligence is not common. Few organisations have reached the maturity required to implement it. At Axelspire it comes as part of the standard software package, available from day one.

Why Shortening the Certificate Lifecycle Matters Beyond Security

By shortening certificate validity, you reduce cybersecurity risk — but you also improve operational maturity and lower the risk of downtime for new applications. Certificate-related issues are identified much earlier in the application project lifecycle, while the project team is still available to address them quickly.

Internal Structure: How the Modules Work Together

Splitting the entire certificate management stack into modules is not difficult. The core of it is separate CI/CD pipelines that run independently. Running a “Client Publishing” pipeline only affects components related to that function. You can delegate management of that pipeline to a separate team — closely aligned with DevOps — focused on tuning client configurations to support your developers.

Certificate issuance is available for your PKI, cyber ops, or infosec team. Intelligence data can be pushed into separate dashboards for your cyber defence team. The PKI team uses client download data to identify PKI users and report on utilisation across the enterprise. Certificate issuance and renewal data provides generic reporting for managers. Certificate validation data goes to cyber defence teams, helping them focus on specific attack vectors and map which clients are connecting to which servers — an entirely independent data set from your generic traffic monitoring.

The bottom line: you can achieve fully-fledged certificate lifecycle automation almost immediately. Your team’s focus shifts to reporting, compliance, and operational monitoring — all the hallmarks of a cyber-mature organisation.