DEV Community

Luke
Luke

Posted on • Originally published at krakenkey.io

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-----"}'
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (4)

Collapse
 
klement_gunndu profile image
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.

Collapse
 
oceansach profile image
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.

Collapse
 
krakenhavoc profile image
Luke

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

Some comments may only be visible to logged-in visitors. Sign in to view all comments.