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.