Skip to content

47-Day Certificates Are Coming. Are You Ready?

Act Now →

Management of Digital Certificates and Keys in DevOps

Management of Digital Certificates & Keys in DevOps
Table Of Contents

Certificate and key management in DevOps is the practice of issuing, storing, rotating, and revoking digital certificates and cryptographic keys automatically across CI/CD pipelines, containers, and cloud infrastructure. Done well, it gives every workload a trusted identity without slowing delivery.

Managing digital certificates and keys in DevOps means automating how TLS certificates, code signing keys, SSH keys, and secrets are issued, stored, rotated, and revoked across CI/CD pipelines and cloud workloads. Automation through the ACME protocol (Automatic Certificate Management Environment), certificate lifecycle management platforms, and secrets managers keeps delivery fast while preventing expired certificates and leaked private keys.

Key Takeaways

  • Certificates and keys authenticate every machine in a pipeline: TLS for client connections, mutual TLS between services, code signing for build artifacts, and SSH for repository and server access.
  • CA/Browser Forum ballot SC-081v3 cuts maximum public TLS certificate validity to 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Renewal becomes a monthly event that only automation can keep up with.
  • ACME, standardized as IETF RFC 8555 in March 2019, automates validation, issuance, and renewal. cert-manager, whose CNCF graduation was announced in November 2024, applies the same automation inside Kubernetes.
  • The 2017 Equifax breach exposed data on about 147 million people, and the exfiltration ran undetected for 76 days because a certificate on a traffic monitoring device had expired.
  • Private keys belong in a secrets manager or a hardware security module (HSM), never in source repositories. The 2016 Uber breach, which exposed 57 million records, started with credentials found in a private GitHub repository.

What Certificates and Keys Do in a DevOps Pipeline

Certificates and keys give a trusted identity to every machine, service, and artifact a DevOps pipeline touches. Digital certificates secure client traffic over HTTPS, and mutual TLS certificates authenticate microservices to each other inside the cluster. Code signing keys prove that a build artifact or container image came from your pipeline and was not altered afterward. SSH keys control access to repositories and servers, and API tokens authenticate every automated call in between.

The result is that machine identities in a pipeline far outnumber the humans who run it. Every build server, container, and ephemeral test environment needs credentials, and each credential has a lifecycle: it is created, used, rotated, and retired. Certificate and key management is the discipline of running that lifecycle deliberately instead of letting it happen by accident.

Why DevOps Breaks Manual Certificate Management

Manual certificate processes fail in DevOps because infrastructure now changes faster than a ticket queue can respond. A traditional certificate request took days of validation and approval, which was tolerable when servers lived for years. A container that lives for twenty minutes cannot open a ticket.

When issuance is slow, engineers route around it. They generate self-signed certificates, reuse one wildcard certificate across dozens of services, or commit keys to a repository so the pipeline can find them. Each workaround creates cryptography that no inventory tracks and no renewal process covers. Every certificate a pipeline creates outside the inventory is an outage or a breach waiting for a date.

What Failure Looks Like: Equifax and Uber

Two well-documented incidents show what happens when certificate and key hygiene lags behind delivery speed.

In 2017, Equifax was breached through an unpatched Apache Struts vulnerability (CVE-2017-5638), exposing personal data on about 147 million people. The certificate lesson sits in the detection failure: the U.S. Government Accountability Office review found that a certificate on the device Equifax used to inspect network traffic had expired, so the exfiltration ran for 76 days before anyone saw it. An expired certificate did not cause the breach, but it blinded the tools that should have caught it.

In 2016, attackers obtained Uber credentials from a private GitHub repository and used them to reach cloud storage holding data on 57 million riders and drivers, a breach Uber disclosed in 2017. Keys and credentials committed to source control are secrets in the one place every attacker checks first. Uber responded with stricter access controls and multi-factor authentication on code access; the cheaper fix is never storing key material in a repository at all.

The 47-Day Validity Schedule Raises the Stakes

Public TLS certificate lifetimes shrink to 47 days by March 2029 under CA/Browser Forum ballot SC-081v3, approved in April 2025. The reduction arrives in stages:

Effective dateMaximum TLS certificate validity
Until March 14, 2026398 days
March 15, 2026200 days
March 15, 2027100 days
March 15, 202947 days

At 47 days, every public-facing service renews certificates roughly monthly, and any team still renewing by hand will spend more time on renewals than the renewals are worth. For DevOps teams this settles the automation question: the pipeline that deploys the service must also be able to renew its certificate. Organizations can assess their exposure now through a 47-day certificate readiness review rather than waiting for the 100-day phase in March 2027 to force the issue.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Six Practices for Managing Certificates and Keys in DevOps

Six practices cover most of the risk in DevOps certificate and key management, and each one can be introduced without stopping delivery.

  1. Build and maintain a certificate and key inventory: Record every certificate and key in the environment: type, owner, expiry date, location, and issuing authority. The inventory is the foundation for everything else, because you cannot renew, rotate, or revoke what you cannot see. Discovery must be continuous; a one-time audit is stale the day the next pipeline runs.
  2. Automate issuance and renewal: Use the ACME protocol (IETF RFC 8555, March 2019) or a certificate lifecycle management platform so certificates issue and renew without tickets. In Kubernetes, cert-manager automates TLS and mutual TLS issuance and renewal, and its CNCF graduation, announced in November 2024, reflects how standard this automation has become.
  3. Protect private keys in an HSM or secrets manager: Keys never belong in source repositories, container images, or plain pipeline variables. Store them in a hardware security module or a secrets manager, and let workloads fetch them at runtime through short-lived, audited access.
  4. Enforce least-privilege access: Restrict who and what can request certificates, read keys, or change issuance policy, and log every access. Role-based controls on the certificate authority and the secrets store limit the blast radius when a single credential leaks.
  5. Monitor expiry and alert early; Track every certificate against its expiry date and alert well before renewal is due, including certificates on security tooling itself. Equifax shows why: monitoring you cannot decrypt is monitoring that does not exist.
  6. Prefer short-lived credentials: Short-lived certificates and tokens shrink the window an attacker can use a stolen credential and reduce dependence on revocation. The industry is moving this direction anyway; adopting short lifetimes early makes the 47-day schedule a non-event.

Integrating Certificate Security into CI/CD

Certificate security holds up in DevOps when it is expressed the same way the rest of the infrastructure is: as code. Issuance policies, certificate profiles, and trust configuration belong in version control, where they are reviewed and rolled back like application code. Secret scanning in the pipeline should fail any build that embeds a private key or hard-coded credential, which turns the Uber failure mode into a blocked merge instead of a breach. Continuous monitoring then closes the loop, feeding certificate expiry and anomalous issuance events into the same alerting that watches the application.

How Encryption Consulting Helps

CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform. It discovers and inventories certificates across your environment and automates issuance, renewal, and revocation, so pipeline certificates renew on schedule instead of by ticket. For teams building out their pipeline security more broadly, the Securing DevOps practice covers the surrounding key management and PKI architecture. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Frequently Asked Questions

Why is certificate management harder in DevOps than in traditional IT?

DevOps infrastructure is ephemeral. Containers and cloud instances are created and destroyed in minutes, and each one needs a trusted identity, so certificate volume grows far beyond what a ticket-based issuance process can serve. Traditional IT renewed a known set of certificates once a year; a pipeline can request hundreds of certificates a day and cannot wait days for each one.

What is ACME and how does it help DevOps teams?

ACME (Automatic Certificate Management Environment) is the protocol standardized in IETF RFC 8555 in March 2019. It automates domain validation, certificate issuance, and renewal between a client and a certificate authority, with no human in the loop. Tools such as cert-manager use ACME to issue and renew certificates for Kubernetes workloads automatically, which is how public CAs like Let’s Encrypt operate at scale.

How does the 47-day certificate validity rule affect DevOps pipelines?

CA/Browser Forum ballot SC-081v3 reduces maximum public TLS certificate validity in stages: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. At 47 days, every public-facing service renews certificates roughly monthly. Manual renewal cannot keep that pace, so automated issuance and renewal inside the pipeline becomes a requirement rather than an optimization.

Where should private keys be stored in a CI/CD pipeline?

Private keys belong in a secrets manager or a hardware security module (HSM), never in source repositories, container images, or plain pipeline variables. The 2016 Uber breach began with credentials found in a private GitHub repository. Pipelines should fetch keys at runtime through short-lived, audited access, and secret scanning should fail any build that embeds key material in code.

What is the difference between a secrets manager and a certificate lifecycle management platform?

A secrets manager stores and rotates sensitive values such as private keys, API tokens, and passwords, and serves them to workloads at runtime. A certificate lifecycle management (CLM) platform governs the certificate itself: discovery, inventory, issuance through a certificate authority, renewal, and revocation. The two are complementary. The CLM platform decides when and how a certificate exists; the secrets manager protects the key material it depends on.

Automate Certificate Lifecycles Before the Clock Shortens

The 200-day limit took effect on March 15, 2026, and the pace only quickens from here. See CertSecure Manager in action to automate discovery, issuance, and renewal across your pipelines, or generate a test request with the free CSR Generator to check your current issuance flow.