Automating Certificate Lifecycle Management

Managing the lifecycles of TLS certificates is critical to maintaining a healthy public key infrastructure (PKI), and automation will soon be the only practical way to do it at scale.

Ideally, a PKI admin’s relationship with certificates should be much like an end user’s: surfacing only for exceptions while remaining automatic for the routine. The only time end users even notice certificates is when something goes wrong: your page is replaced with an all-too-common security warning which declares the site untrusted. Perhaps your certificate expired, had missing subject alternative name (SAN) values, or was self-signed.

Just like a user’s browser checking for a valid certificate, the tedium of enrolling, validating, monitoring, renewing, and even offboarding certificates can and should be routine, automatic work performed in the background. In turn, this frees up PKI and system admins to worry about the critical or non-routine while reducing some human error.

Let’s dive into a few key benefits of automating your certificate lifecycle management.

More to do, less time to do it

Two forces in the PKI world continue to work against each other: the ever-growing quantity of certificates and the shrinking time allowed to manage them.

On one hand, the amount of certificates in use grows alongside trends like microservices, containerization, and Internet of Things (IoT). Certificate-supported public key encryption is the norm in today’s networking landscape, so it follows that each new machine needs a certificate for its identity.

On the other hand, validity periods for publicly-issued subscriber (server) certificates will only grow shorter. In an effort spearheaded by Apple, the CA/Browser forum has unanimously approved a timeline for reducing the maximum validity period for these certificates:

• 200 days maximum validity in March 2026
• 100 days in March 2027
• 47 days in March 2029

Previously, validity periods of over a year allowed manual renewals and installations on an annual basis. Soon, 47-day validities will warrant monthly renewals. And when we multiply the ever-growing quantity of certificates by this hastened renewal cadence, we reach management demand that is untenable and unscalable for manual PKI processes.

Unlocking security and agility through automation

So, does the CA/Browser forum simply want to give PKI admins more to do? To the contrary, the forum sees great security benefits in shorter validity periods and encouraging more automated certificate management.

If a certificate is valid for a shorter duration, the time period in which it could be inaccurate or misused (perhaps even maliciously by an attacker) also becomes shorter. In a perfect world, certificates would be momentary assurances of identity; 47 days is a practical step in that direction.

Automating your certificate lifecycle management also means the enablement of other best practices, such as reducing the usage of wildcards and extra SANs. Shortening the duration of the certificate’s validity reduces its temporal scope of vulnerability; removing excess reuse reduces the blast radius. A compromised certificate with wildcards or SANs gives an attacker the capability to impersonate a wider range of domains, requiring more time and effort to remedy incidents.

Beyond increased security, faster operating speeds and automation also yield a second key benefit in crypto agility, or the ability to quickly respond to cryptography trends and incidents. If you already have the automation in place to cycle certificates rapidly, changing CAs after a distrust or revocation in the issuing chain becomes more straightforward. Similarly, if encryption trends warrant increasing key strengths or changing to, for example, a post-quantum algorithm, making the pivot in your PKI environment is much more approachable. You already have the automation set up, now just some tweaks or input changes are needed.

What about private certificates?

The CA/Browser forum’s requirements will not directly affect internal PKIs like Microsoft AD CS or EJBCA. However, the same principles apply: long validity periods carry higher risk, and shorter ones improve trust and agility. Normalizing your PKI policies and management across public and private PKI can still improve your overall security posture even though the CA/B forum requirements won’t necessitate internal policy changes.

The path to automation

Automation often carries a shining connotation, but developers and infrastructure engineers are acutely aware of the messiness it can bring. The Internet Security Research Group, or the group behind Let’s Encrypts ubiquitously evident efforts to make HTTPS the web’s default, has certainly helped with their contribution of the ACME protocol, which has made automatic enrollment and renewal of certificates much easier to delegate to automated scripts and services. And with open-source ACME clients like certbot, bootstrapping an HTTPS-supporting site can require minimal effort. Keeping it all going while getting visibility, monitoring, and error resiliency while also resisting unmaintainable script sprawl in your environment? That’s another matter entirely.

Enrollment and renewal are only part of a certificate’s lifecycle. The application consuming it must then be correctly configured to use the new or renewed certificate. Whether that’s an IIS or Apache web server, a MySQL or MS SQL database, or an F5 or Citrix load balancer, getting the certificate into the right place, in the right format, and on the right schedule can be as tedious, time-consuming, and error-prone as the enrollment itself.

On top of that, you also want flexibility in how you deploy your certificates. Some teams may use Ansible to run playbooks that manage their machines. Others may use CloudFormation or Terraform within CI/CD pipelines to stand up and maintain cloud-native applications. And some critical infrastructure may need a little more manual oversight.

There isn’t a single method that will fit every use case, and you want your certificate lifecycle management to meet your applications where they are. In cases where orchestration tools or CI/CD pipelines are being used, pull provisioning is often the right fit. Pull provisioning involves a third party—whether that be the machine, a pipeline, or some orchestrator—reaching out and ‘pulling’ the certificate from a central store or certificate management tool. This can ensure certificates are tied to existing schedules, checks, and changes.

In other cases, you may want your certificate management tool to do the heavy lifting. With push provisioning, the platform which centrally manages and stores your certificates is also responsible for securely installing the certificate and its associated keypair to the device or application which needs it. This allows the provisioning process to instead stay more local to the certificate management itself, existing alongside enrollments, renewals, and approvals. Push provisioning also makes sense for machines which are already being managed with ad-hoc or manual processes.

Trusting the process

We’ve discussed key benefits and enablers for automating enrollment and provisioning processes, but the lifecycle of a certificate doesn’t end there. How do we receive continuous trust and assurance that these processes are performing as expected? How can we feel comfortable knowing that every server is kindly serving the certificate it’s supposed to?

After provisioning, monitoring and validation become prime targets for automation in order to provide a better risk and compliance posture. Without a single pane of glass to view certificates’ statuses and characteristics, it can be difficult to grasp your PKI as a whole. How compliant are all certificates to your PKI policy? What rogue, self-signed certificates have cropped up outside the purview of your PKI? And perhaps most importantly: How ready is your organization for 47 days?

To answer these questions, a robust and centralized PKI strategy is needed. Curious if your public-facing PKI is prepared for 47 days?

With 35 years of experience helping organizations secure and modernize their technology, we know the risks of letting certificates slip. That’s why we’ve partnered with CyberArk to provide a free Certificate Readiness Scan—so you can see where you stand today and build a clear roadmap to stay compliant when the mandate takes effect.