lukewilkinson.io
← Projects

product

KrakenKey

Open-source TLS certificate automation. One-time DNS setup, then certificates in about four minutes, and the platform never sees a private key.

Visit krakenkey.io ↗

Why

Public TLS certificate lifetimes are shrinking: 200 days now, 100 next, and 47 days by March 2029 under CA/Browser Forum ballot SC-081v3. Renewing by hand stops being an option at that cadence. Most tools that automate it either need credentials to your DNS provider or take custody of your private keys. I founded KrakenKey to do neither.

How issuance works

Your environment Browser, CLI, or GitHub Action private key (stays here) CSR (public key only) KrakenKey REST API, job queue, ACME client stores: CSR, certificate never: private key, your DNS credentials Let's Encrypt ACME, DNS-01 Challenge DNS zone run by KrakenKey 1 CSR 2 order 3 TXT 4 validate 5 signed certificate One-time setup in your DNS: a TXT record proving ownership, and _acme-challenge as a CNAME into the KrakenKey zone.
  1. One-time DNS setup per domain. A TXT record proves you own the domain. A CNAME delegates only _acme-challenge to a zone KrakenKey runs. KrakenKey never holds credentials for your DNS provider and cannot touch any other record.
  2. The key pair is created on your side. The dashboard generates it in the browser with the WebCrypto API. The CLI and the GitHub Action generate it locally, or you bring a CSR from openssl. Only the CSR, which carries the public key, is sent.
  3. The backend runs the ACME flow as a queued job. It creates the order with Let’s Encrypt, publishes the DNS-01 challenge in the delegated zone, waits for propagation, and finalizes.
  4. You get the signed certificate back, usually in about four minutes. Renewal repeats the same flow without anyone editing DNS again.

If the platform were fully compromised, the attacker would get certificates and CSRs, both of which are public material. There are no private keys to take.

In a pipeline

- name: Issue TLS certificate
  id: cert
  uses: krakenkey/cert-action@v1
  with:
    api-key: ${{ secrets.KRAKENKEY_API_KEY }}
    domain: api.example.com

The action writes the key and the full chain to the runner’s filesystem and uploads nothing. Where the key goes next is decided by the workflow that called it. The CLI does the same job from a terminal:

$ krakenkey cert issue --domain example.com --wait
$ krakenkey endpoint add api.example.com:443

What I built

  • Platform (krakenkey/app): NestJS 11 REST API, React 19 dashboard, PostgreSQL, BullMQ on Redis for the ACME jobs, OIDC sign-in plus scoped API keys, OpenAPI docs, Stripe billing, Prometheus metrics.
  • CLI (krakenkey/cli) in Go.
  • GitHub Action (krakenkey/cert-action) for issue, renew, and download.
  • Probe (krakenkey/probe) in Go: a TLS endpoint scanner that runs standalone, connected to the platform, or hosted, so expiry is caught on the endpoint and not only in the inventory.
  • The platform’s own build pipelines, secret management, and devcontainer-based local environment with TLS and Traefik.

Status

Live at krakenkey.io with a free tier. The source is public under AGPL-3.0 at github.com/krakenkey. A Terraform provider in Go and Entra ID application credential rotation through Microsoft Graph are in development.