TLS Certificates Are About to Expire Way More Often. Here's How I'm Handling It.

If you manage TLS certificates for anything beyond a single server, the next three years are going to get more and more painful.

What's changing

The CA/Browser Forum passed Ballot SC-081, which phases in shorter TLS certificate lifetimes starting March 15, 2026:

Date	Max Lifetime	Renewals/Year
Until March 15, 2026	398 days	~1
March 15, 2026	200 days	~2
March 15, 2027	100 days	~4
March 15, 2029	47 days	~8

By 2029, you're renewing certificates roughly every six weeks. Domain Control Validation reuse drops to 10 days, meaning CAs re-validate your domain almost continuously.

This isn't a proposal — it passed in April 2025 and is already on the books.

The gap I kept running into

I've been using Certbot for years. It's excellent at what it does: issue a cert on a single machine via Let's Encrypt. But once I had certificates across multiple services and domains, the problems stacked up:

• A cert expired on a staging server because the cron job silently failed after an OS update
• A teammate needed to issue a cert but didn't have SSH access to the cert server
• I had no single view of which certs were expiring across all my services
• A renewal failed and I didn't find out until a user reported a broken page

Certbot and cert-manager solve issuance. But there's been nothing lightweight for management — tracking what you have, knowing when things go wrong, and giving your team access without handing over keys.

What I built

KrakenKey is the management layer I wanted on top of ACME. Here's how it works:

1. Submit a CSR — no server access needed

Generate a CSR in the browser (WebCrypto API — your private key never leaves your device) or bring your own. Submit it via the dashboard or the REST API:

curl -X POST https://api.krakenkey.io/certs/tls \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"csrPem": "-----BEGIN CERTIFICATE REQUEST-----\n...\n-----END CERTIFICATE REQUEST-----"}'

KrakenKey handles DNS-01 validation via Let's Encrypt. Cert is ready in ~4 minutes.

2. Everything is tracked

Every cert, every domain, every renewal — visible in one dashboard. Filter by domain, check status, download in PEM or PKCS#12. No grepping logs on five servers.

3. Auto-renewal that actually works

Not "automatic unless the cron job timed out." KrakenKey monitors every cert and renews on schedule. You get email notifications when a cert is issued, renewed, or when something fails.

4. API-native

Every dashboard action is available via REST API. Issue certs from CI, check status in deployment scripts, scope API keys per application:

# Check certificate status
curl https://api.krakenkey.io/certs/tls/abc123 \
  -H "Authorization: Bearer $API_KEY"

# The certificate PEM is included in the response (crtPem field)
curl -s https://api.krakenkey.io/certs/tls/abc123 \
  -H "Authorization: Bearer $API_KEY" | jq -r '.crtPem' > cert.pem

What it costs

The free tier is genuinely free — no credit card, no trial expiry:

• 3 verified domains
• 10 active certificates
• 5 issuances + renewals per month
• Auto-renewal (5-day window)
• Email notifications
• Full API access

Paid plans ($29–199/mo) launch this month for teams that need higher limits, 30-day renewal windows, RBAC, and audit logs.

The stack

NestJS, React, PostgreSQL, BullMQ, Terraform, Let's Encrypt production ACME. Source is on GitHub:

github.com/krakenkey/krakenkey

What I'd love feedback on

I'm especially interested in hearing from anyone who:

• Manages certs across multiple services or environments
• Has opinions on the dashboard UX for cert lifecycle visibility
• Has hit edge cases with DNS-01 validation they'd want handled better

If you're dealing with shorter cert lifetimes or just tired of silent renewal failures, give it a try — I'd genuinely appreciate the feedback.

Comments

[Incident Copilot]

The operational point here is the important one: shorter cert lifetimes are only a net win if renewal becomes observable, testable, and boring.

A lot of teams still think of certificate work as an annual maintenance task, but with the 200-day change on March 15, 2026 that mindset stops being safe. Central visibility plus failure notification is exactly the layer most teams are missing between raw ACME automation and real production operations.

[Andrew Wang]

The six-week renewal horizon is the part most teams are still underestimating. Shorter cert lifetimes only improve security if renewal and validation are fully observable, otherwise people just trade one annual task for constant silent failures. Your point about domain re-validation matters even more than the raw expiry window, because it adds operational fragility outside the app stack itself. Teams should treat certificate automation like CI: tested, monitored, and boring.

[klement Gunndu]

SC-081 is going to catch a lot of teams off guard — we moved to ACME-based auto-renewal last year and the biggest gotcha was intermediate cert chains not updating along with the leaf cert.

[Sarwar]

Learned about this exact problem building my own cert tooling — the chain scanning/updating gap was an eye-opener. Most tools work on the leaf and stop there.

[Luke]

That's a great note, I'll have to look into that and add it to the roadmap.