Learn PKI - Certificate Lifecycle & Automation

#Introduction

In episode 13 you protected private keys with HSM, KMS, and split knowledge. The keys are indeed safe, but the certificates in circulation still need to be managed throughout their lives. Episode 14 brings all previous lessons together into one complete discipline: the certificate lifecycle, from birth to retirement.

Certificates are assets that expire. Without systematic management, some certificates will definitely be missed, applications suddenly die, and the team is busy fighting fires in the middle of the night. Automation turns reactive work into a process that runs by itself.

This episode's roadmap: we trace each lifecycle stage, learn expiry monitoring, see the reasoning behind short-lived certificates, get to know SPIFFE and SPIRE for mTLS in a service mesh, then assemble observability with cert-monitor and cert-manager cainjector.

#The Five Stages of the Certificate Lifecycle

The certificate lifecycle can be broken into five recurring stages: enrollment, issuance, distribution, renewal, and revocation. Understanding this order helps you find automation points in each stage.

#Enrollment

Enrollment is the process of registering an entity so the CA recognizes it. The entity proves its identity, then gains the right to request certificates. In step-ca, enrollment happens through provisioners; in Vault, through roles and tokens; in Kubernetes, through service accounts.

#Issuance

Issuance produces a certificate from a submitted CSR. The CA verifies that the requester is entitled to the requested name, applies policies such as validity and usages, then signs. At this stage the profile policy you assembled in episodes 11 and 12 really does its work.

#Distribution

An issued certificate must reach its users securely. Distribution includes writing files to services, installing into trust stores, or delivering via mounts in Kubernetes. trust-manager from episode 10 is an example of distribution automation for CA bundles.

#Renewal

Before expiry, the certificate must be renewed. Renewal should ideally run automatically well before the deadline, with enough time to fix failures. cert-manager, step-ca, and Vault Agent all support this pattern.

#Revocation

When a key leaks or an entity is no longer trusted, the certificate is revoked. Revocation cuts trust earlier than expiry. The CRL and OCSP discussed in episode 12 are the mechanisms for announcing this status to users.

#Monitoring Expiry

An unnoticed expired certificate is the most common cause of TLS incidents. The solution is proactive monitoring: every certificate's end date must be known, and warnings must appear well in advance.

openssl x509 -in cert.pem -noout -enddate

openssl x509 -noout -enddate shows the certificate's validity period. For large scale, manual monitoring is not enough. step-ca provides cert-monitor, a tool that monitors certificates and sends notifications when the validity period nears its end.

cert-monitor --cert /etc/tls/cert.pem

cert-monitor can be configured with many certificates at once and various notification channels. It is also well suited to being combined with metrics so expiry shows up as an alarm on the team dashboard.

The simplest way to start: collect all certificates into one inventory, set a warning threshold, then install periodic checks. This step sounds trivial, but it saves many sleepless nights.

#Short-Lived Certificates

The shorter the validity period, the smaller the abuse window if a key leaks. Modern trends lower validity from one year to a matter of days.

Short-lived certificates generally range from 24 hours to 7 days. In this range, expiry monitoring becomes less relevant because certificates keep changing. What matters more is the reliability of renewal automation, because a momentary failure can immediately take down a service.

Both step-ca and Vault can issue short-lived certificates. The key is consistent policy: what is the longest allowed number of hours, and how quickly does renewal run after a certificate is issued.

step ca certificate api.internal cert.pem key.pem \
  --not-after 24h

With --not-after 24h, step-ca issues a certificate valid for only one day. Certificate replacement must be fully automated, for example with a renewal daemon or cert-manager in Kubernetes.

#SPIFFE and SPIRE

SPIFFE gives every workload a universal identity in the form of a spiffe ID, for example spiffe://example.org/workload/api. SPIRE issues SVIDs, which are short-lived certificates proving that identity, and injects them into pods or machines.

In a service mesh, SPIFFE identity becomes the basis of mTLS. Every workload proves its identity through an SVID before traffic is accepted, so services can decide access based on who is asking, not just a network address.

spire-server entry create \
  -spiffeID spiffe://example.org/workload/api \
  -parentID spiffe://example.org/agent \
  -selector k8s:pod-label:app:api

The entry above gives an identity to the pod labeled app:api. SPIRE verifies the pod's conditions through an attestor, then provides an SVID that is renewed automatically before expiry. This is lifecycle automation at the identity level.

#Observability and Supporting Tools

Automated certificates still need to be visible. Metrics must answer the questions: how many certificates are active, when does the next one expire, and are there any failed renewals.

In Kubernetes, cert-manager provides a component named cainjector. It writes the CA bundle into the ConfigMap or Secret used by applications, so every new issuance immediately updates the trust store.

kubectl get certificate web01-tls -o yaml

kubectl get certificate shows the resource's status and conditions. For cross-cluster monitoring, combine cert-manager metrics with Prometheus and alerting. This combination closes the gap between automated issuance and human awareness.

#Closing

Episode 14 assembles the entire series into one complete flow. You understood the five stages of the certificate lifecycle, monitored expiry with cert-monitor, used short-lived certificates of 24 hours to 7 days, got to know SPIFFE and SPIRE for mTLS in a service mesh, and built observability with cert-manager cainjector.

Key takeaways:

• The certificate lifecycle consists of enrollment, issuance, distribution, renewal, and revocation.
• Proactive expiry monitoring prevents the most common incidents.
• Short-lived certificates shrink the abuse window and shift priority to renewal automation.
• SPIFFE and SPIRE turn certificates into automatically rotated workload identity.
• cert-manager cainjector updates application trust stores automatically.
• Observability ensures running automation stays visible and trustworthy.

In episode 15 we raise everything to the architecture level. You will learn Zero Trust and service identity: mTLS as the foundation, workload identity versus machine identity, service mesh such as Linkerd, Istio, and Cilium, and SSH PKI with step-ca. See you there!