Public TLS certificates now last 200 days at most, and 47 is on the calendar.
The outage that starts with an expired certificate on a load balancer nobody remembered is getting more likely, because lifetimes keep shrinking. We inventory certificates and secrets, automate renewal with ACME, move secrets into a vault with rotation, and get them out of source code for good.
HashiCorp VaultCyberArkTerraformMicrosoft Entra ID
in short·20-second read
Secrets and certificate lifecycle management covers the passwords, API keys, tokens and TLS certificates your applications depend on.
It deals with where they're stored, who can read them, and how they get rotated or renewed. Cohash finds secrets in code and CI and moves them into HashiCorp Vault or a cloud secret store. We set up rotation and dynamic credentials, and automate certificate renewal ahead of the CA/Browser Forum's shrinking validity limits.
you probably need this if
A certificate expired on a load balancer nobody remembered and took an app down.
A handful of public certificates still get renewed by hand, because the appliances they sit on don't speak ACME.
Secret scanning keeps finding API keys in repositories and CI logs.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Secrets & Certificate Lifecycle, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · secrets & certificate lifecycle3 open
openA certificate expired on a load balancer nobody remembered and took an app down.
recurringA handful of public certificates still get renewed by hand, because the appliances they sit on don't speak ACME.
blockedSecret scanning keeps finding API keys in repositories and CI logs.
exposure
Certificate inventoryACME renewal automationSecrets discovery in code and CIVault design and rolloutDynamic and rotated secretsPrivate PKI
startrehearsehandover
Find
Fix exposures
Automate
Monitor
we are here
ready to hand over
Every public certificate now has an owner and either renews by itself or has a written…
Database credentials are leased or rotated on a schedule, no password sits in source…
Certificate and secret inventory with owner and expiry
Exposed-secret remediation log
chapter 01 · where it hurts
Why teams reach out
A certificate expired on a load balancer nobody remembered and took an app down.
A handful of public certificates still get renewed by hand, because the appliances they sit on don't speak ACME.
Secret scanning keeps finding API keys in repositories and CI logs.
chapter 02 · what we change
How we solve it
Certificate inventory
ACME renewal automation
Secrets discovery in code and CI
Vault design and rollout
Dynamic and rotated secrets
Private PKI
chapter 03 · how it runs
Our approach
Find
Fix exposures
Automate
Monitor
chapter 04 · where you end up
What changes
Every public certificate now has an owner and either renews by itself or has a written exception.
Database credentials are leased or rotated on a schedule, no password sits in source control, and each login maps to exactly one application.
Certificate and secret inventory with owner and expiry
Exposed-secret remediation log
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Discovery across load balancers, web servers, Kubernetes ingress, Certificate Transparency logs and internal CAs, so you know every certificate, its issuer, its owner and its expiry date.
Public TLS certificates issued since 15 March 2026 can last no more than 200 days. The limit falls to 100 days in March 2027 and to 47 days in March 2029. Renewal runs through cert-manager, an ACME client or your CA's agent, and the new certificate is deployed to every endpoint that needs it.
Scans of repositories, build logs and CI variables for exposed keys. Every finding is rotated or revoked. Deleting it from the latest commit fixes nothing.
We set up HashiCorp Vault with namespaces, auth methods tied to workload identity, and per-application policies. Where a cloud-native store fits better, we use AWS Secrets Manager or Azure Key Vault instead.
We have Vault's database secrets engine hand out database credentials on demand and revoke them once their lease ends. For secrets that must stay static, we set rotation schedules.
Internal CA hierarchy, certificate templates and revocation for device, mTLS and internal service certificates. They aren't bound by public TLS limits but benefit from the same automation.
capability 01 / 06in production
Certificate inventory
Discovery across load balancers, web servers, Kubernetes ingress, Certificate Transparency logs and internal CAs, so you know every certificate, its issuer, its owner and its expiry date.
Public TLS certificates issued since 15 March 2026 can last no more than 200 days. The limit falls to 100 days in March 2027 and to 47 days in March 2029. Renewal runs through cert-manager, an ACME client or your CA's agent, and the new certificate is deployed to every endpoint that needs it.
Scans of repositories, build logs and CI variables for exposed keys. Every finding is rotated or revoked. Deleting it from the latest commit fixes nothing.
We set up HashiCorp Vault with namespaces, auth methods tied to workload identity, and per-application policies. Where a cloud-native store fits better, we use AWS Secrets Manager or Azure Key Vault instead.
We have Vault's database secrets engine hand out database credentials on demand and revoke them once their lease ends. For secrets that must stay static, we set rotation schedules.
Internal CA hierarchy, certificate templates and revocation for device, mTLS and internal service certificates. They aren't bound by public TLS limits but benefit from the same automation.
We pieced these together from Secrets & Certificate Lifecycle situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Load balancer certificates renewed by hand, with 100-day lifetimes coming
composite · not a client story
Beforethe situation
Public certificates on F5 BIG-IP and older appliances are renewed through a CA portal and uploaded by hand from a spreadsheet of expiry dates. That works at 200-day lifetimes. At 100 days in March 2027 it won't.
What we dothe work
We build the inventory from Certificate Transparency logs and appliance APIs, and match each certificate to an owner. Renewal is automated through ACME where the device or a proxy in front of it supports it. Elsewhere we use the CA's automation agent or a scripted API push. Alerts fire at 30 days left.
Afterwhere you end up
Every public certificate now has an owner and either renews by itself or has a written exception. The spreadsheet is gone. When something gets close to expiry, the team running that endpoint hears about it.
case file 02
Database passwords in committed config files since launch
composite · not a client story
Beforethe situation
Internal .NET and Java apps connect to SQL Server and PostgreSQL with passwords in config files checked into the repository. The DBAs won't rotate them because nobody knows which app instances share each login.
What we dothe work
Scan repositories and config stores to map every login to its apps. Move apps to Vault's database secrets engine with short leases where they can handle dynamic credentials, and to rotated static roles where they can't. Disable each old login after its last instance moves.
Afterwhere you end up
Database credentials are leased or rotated on a schedule, no password sits in source control, and each login maps to exactly one application.
Where certificates and secrets get issued, renewed and rotated
Certificates come from public and private CAs through ACME clients, which push them to each endpoint. Apps get leased database credentials and rotated secrets from the vault. Anything exposed or close to expiry shows up in scanning and the certificate inventory.
01 · Issuers
Public CAACME · 200-day maximum → ACME clients · ACME order
Database secrets engine → Applications: short lease
Secret scanning → Applications: leak findings
Load balancers and ingress → Certificate inventory: expiry data
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Find
Certificate and secret discovery across infrastructure, code and CI.
step 02
Fix exposures
Leaked secrets rotated or revoked, and their owners told what happened.
step 03
Automate
Renewal and rotation built for each certificate and secret type, starting with whatever expires soonest.
step 04
Monitor
Expiry warnings and rotation failures go to the team that owns them, before users notice.
you keep
What you're left with
We write these for your Secrets & Certificate Lifecycle setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Certificate and secret inventory with owner and expiry
talent and delivery · secrets & certificate lifecycle
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Secrets & Certificate Lifecycle work. The ones who've done it answer differently from the ones who've read about it.
Q1
Not every certificate we have shows up in Certificate Transparency logs. How do you plan to find the others?
CT logs only show publicly trusted certificates. Internal CA certificates, self-signed ones on appliances and mTLS certificates inside Kubernetes need network scans and platform APIs.
Q2
What's your plan for devices that can't speak ACME?
Older appliances and some SaaS endpoints only accept uploads. They'll need a scripted API push, a fronting proxy or a managed service before the 100-day step.
Q3
When a secret leaks, who rotates it and how quickly?
Deleting the commit doesn't revoke anything. Each secret type needs a named owner and a rotation runbook that someone has actually run at least once.
Q4
What will running Vault ourselves cost in people, upgrades and on-call?
Self-managed Vault needs storage, unseal, upgrades, backups and monitoring. Weigh that honestly against a managed Vault service or a cloud-native store before committing.
01Do the 47-day limits apply to our internal certificates?
No. CA/Browser Forum Ballot SC-081 covers publicly trusted TLS certificates. Certificates from your own private CA follow whatever policy you set. Many teams shorten internal lifetimes anyway once renewal is automated, because a shorter life limits the damage from a stolen key.
02What should we do before the 100-day step in March 2027?
Find every public certificate and how it gets renewed. Anything renewed by hand, especially on appliances and load balancers without ACME support, needs automation or a managed service before then. At 100 days, a manual process means touching each certificate roughly every three months.
03Should we run HashiCorp Vault or use our cloud provider's secret store?
A cloud store is simpler if your workloads live mostly in one cloud. Vault fits multi-cloud and on-premises estates, dynamic database credentials and complex policy. Running Vault yourself carries real operating cost, and we'll size that honestly before you commit.
04Is scrubbing a leaked secret from Git history enough?
No. Assume anything committed has already been copied. Rotate or revoke the secret first, then clean history if you want to. We also add pre-commit and CI scanning so the same mistake gets caught next time.
05Which secrets should we rotate first?
Anything that has been exposed comes first. Then high-privilege credentials shared by several systems, then credentials nobody has touched since they were created. Exposure beats age every time. A secret that leaked last week is more dangerous than an old one nobody has seen.
related
Often paired with
Projects on Secrets & Certificate Lifecycle usually end up touching one of these, so they're worth a look.
