The file cert-manager wrote two years ago is now load-bearing
Somewhere in a Kubernetes Secret you haven't looked at since you set up the cluster, there's a private key. Not a certificate key. Your ACME account key. cert-manager generated it the first time an Issuer registered with Let's Encrypt, stashed it in the Secret named by privateKeySecretRef, and neither you nor anyone on your team has thought about it since. It just works.
That key was, until recently, one of the least interesting objects in your infrastructure. Lose it and you shrug, register a new account, move on. As of a working-group change merged on 20 September 2026, that's no longer true. The account key is quietly becoming the thing that proves you're allowed to get certificates at all, and most teams have no idea where theirs is, whether it's backed up, or what breaks if it's gone.
What the account key actually is
There are two completely different private keys in an ACME setup and people conflate them constantly.
The one you think about is the certificate key. It's the key in your TLS handshake, the one paired with the public key in the cert, the one that rotates every renewal under modern short lifetimes. You regenerate it all the time and nobody cares.
The account key is the other one. When your client first talks to a CA, it generates a key pair and registers the public half. That key pair is your identity at the CA from then on. Every ACME request your client makes gets signed with the account private key, so the CA knows the order, the renewal, the revocation all came from the same account. RFC 8555 calls the registered object your account, and it's addressed by an account URL that looks like https://acme-v02.api.letsencrypt.org/acme/acct/1234567890. The account key never touches a TLS handshake. It signs API requests, and that's it.
Because it's boring and invisible, it gets treated as disposable. That was fine for a while.
Where your client keeps it
You can't protect a key you can't find. Every client stashes it somewhere different, usually under a directory you never open.
certbot writes it as a JWK on disk under the accounts tree:
sudo cat /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/private_key.json
# or, less alarming:
sudo certbot show_account
acme.sh keeps a PEM per CA in its home directory:
cat ~/.acme.sh/ca/acme-v02.api.letsencrypt.org/account.key
lego stores account state under its data path, with the key in a keys subdirectory next to the account JSON. cert-manager is the one that bites people, because the key isn't a file at all. It's a Kubernetes Secret, referenced from the ACME Issuer spec:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-prod-account-key
Delete that Secret and cert-manager, by default, just generates a fresh key and registers a brand-new account on the next reconcile. Silent. No error. You now have a different account URL than the one every existing order was placed under, which most of the time is harmless and occasionally is very much not, as the next section explains. If you've ever debugged issuance that mysteriously reset itself, Debugging cert-manager: Why Your Certificates Are Stuck in a Loop covers the neighbouring failure modes.
Why today changed the stakes
The reason to care right now is dns-persist-01, the persistent DNS challenge that lets you validate a domain once and issue against a standing DNS record forever. The whole point is that you stop touching DNS on every renewal.
The working group just changed how that record is built. It used to contain your account URL in plaintext. As of the merged change it contains a hash computed over, among other things, the JWK thumbprint of your account key. The record is now cryptographically tied to the exact key your account holds. I wrote up the mechanics of that change in The dns-persist-01 Record Just Changed Shape. Your Account Key Is the Anchor Now., but the operational upshot lands here: your account key is no longer a throwaway. It's an input to the DNS record that authorizes every future certificate for the domain.
Lose it or rotate it without a plan, and the standing record you published stops matching. Issuance for that domain stops until you recompute and republish. The key you've been ignoring for two years is now on the critical path.
Rotating the key without breaking issuance
You can rotate an ACME account key. RFC 8555 has a dedicated key-change endpoint for exactly this: you sign a request with both the old key and the new one, the CA swaps them, and your account URL stays the same. certbot exposes it, though the flag has moved around between versions, so check certbot update_account --help on your build rather than trusting a blog. lego and acme.sh have their own key-rollover commands.
The rotation itself is a solved problem. The part people miss is the fallout for persistent DNS. Under the new record format, rotating the account key changes the thumbprint, which changes the digest, which invalidates every dns-persist-01 record you published. So the rotation runbook now has a second step: after the key-change call succeeds, walk every domain with a standing record, recompute the digest with the new key, and republish. Miss one and that domain quietly loses the ability to renew.
If you're not using persistent DNS yet, rotation is still cheap. If you are, treat account-key rotation like a certificate migration, not a one-liner.
Deactivation is a bigger hammer than you think
There's an endpoint most people never touch: account deactivation. You sign a request that tells the CA to mark your account as deactivated, and from that point the CA refuses everything signed with that key. Orders, renewals, revocations, all rejected.
Under the old world that was a footgun with a narrow blast radius. Under dns-persist-01 it's a feature. The draft requires a CA to reject any persistent record whose digest was computed from a deactivated account's keys, no matter what the CA's retention policy says. So deactivating the account is the clean kill switch for every standing authorization tied to it at once. Suspect your account key leaked? Deactivate, and every dns-persist record built on it dies immediately, retention or not.
That cuts both ways. Deactivate the wrong account, or the right account without realizing how many standing records depend on it, and you've revoked your own ability to issue across every domain that trusted it. Know what's downstream before you pull that lever.
What losing it costs you
Say the Secret gets deleted, the disk dies, the laptop with ~/.acme.sh on it goes in a skip. What actually happens?
With plain dns-01 or http-01, not much. Your client registers a new account, gets a new account URL and key, and carries on. The old account is orphaned but harmless. The main risk is tripping the CA's account-registration rate limits if your automation loops and registers repeatedly, which is its own category of bad Friday and something Let's Encrypt Rate Limits Will Ruin Your Friday Deploy gets into.
With dns-persist-01 the bill is higher. Every standing record you published was tied to the lost key. A new account means a new key, a new thumbprint, and a new digest, so all of those records are now dead weight. You have to republish every one of them with the new account before issuance resumes for those domains. If you're a CA that also required External Account Binding, add re-binding your new account to your external identifier before any of that works. The convenience of persistent validation is real, and so is the concentration of risk into a single key you now have to actually manage.
A ten-minute audit you can run today
Find it first. Grep your config management for privateKeySecretRef, look under /etc/letsencrypt/accounts, check ~/.acme.sh/ca and your lego data directory. Write down, per CA, where the account key lives and which account URL it maps to. certbot show_account and the equivalent in your client will print the URL.
Back it up next, to wherever you keep other break-glass secrets, and test that you can actually restore it, because an untested backup is a rumour. For cert-manager, that means the account-key Secret goes into your normal secret backup, not just etcd snapshots you've never restored from.
Then decide who owns rotation. Somebody should be able to answer, without paging through docs during an incident, how to rotate the account key and what else has to change when they do. Right now that answer is "we published the dns-persist records too, and here's the script that recomputes them." If you can't name that person or that script, you've found your gap.
The primary reference for all of this is RFC 8555, which defines accounts, the key-change endpoint and deactivation. The change that made the account key matter for persistent DNS is pull request #67 on the dns-persist draft, merged 20 September 2026. Let's Encrypt's DNS-PERSIST-01 announcement is the friendlier starting point if you're new to the whole idea.
Frequently asked questions
Is my ACME account key the same as my certificate private key? No, and mixing them up is where a lot of confusion starts. The certificate key lives in your TLS handshake and rotates every renewal. The account key signs your API requests to the CA and identifies your account. They're separate key pairs with separate lifecycles.
Do I need to rotate my ACME account key regularly? No. Unlike certificate keys, there's no routine rotation schedule for account keys, and rotating one is disruptive if you use dns-persist-01 because it invalidates your standing records. Rotate it when you have a reason, such as suspected compromise, not on a calendar.
What happens if I delete the cert-manager account key Secret? By default cert-manager generates a new key and registers a new account on the next reconcile, so basic dns-01 and http-01 issuance keeps working under a new account URL. If you use dns-persist-01, though, your standing records were tied to the old key and stop authorizing issuance until you republish them.
How do I roll my account key over without downtime? Use your client's key-change command, which calls the RFC 8555 key-change endpoint and keeps your account URL stable while swapping the underlying key. If you use persistent DNS validation, follow it immediately by recomputing and republishing every dns-persist-01 record, since the record digest depends on the key.
Should I back up my ACME account key? Yes, treat it like any other break-glass secret. For file-based clients that means the accounts directory, and for cert-manager it means the account-key Secret. The cost of a backup is near zero and the cost of losing the key climbs sharply once persistent DNS records depend on it.
