[ENHANCEMENTS] [ACME] Stale DNS credentials/metadata after cert delete + no UI to rotate credentials of existing cert

[BadCoder1337]

Is your feature request related to a problem? Please describe.

Two related pain points I hit while migrating a wildcard certificate from one DNS provider (reg.ru) to another (Cloudflare):

1. Cert deletion leaves stale ACME data behind. HandleCertRemove only removes <name>.pem and <name>.key. The <name>.json metadata file in conf/certs/ and the acme/<name>_dns_provider | _dns_credentials | _dns_servers keys in sys.db are left untouched. If I then try to re-issue a cert with the same filename, ObtainCert picks up the leftover .json, overrides the user-chosen challenge type with useDNS = certInfo.UseDNS and tries the stale credentials from the old provider. Even falling back to HTTP-01 was impossible until I wiped the buckets manually with a custom bbolt tool. Code refs:

• tlscert.RemoveCert removes only .pem/.key: src/mod/tlscert/tlscert.go:293
• ObtainCert overrides useDNS from disk: src/mod/acme/acme.go:178-186

2. No UI/API to rotate DNS credentials of an existing cert. If I rotate the API token at dash.cloudflare.com, the only documented way to update the stored value in acme/<name>_dns_credentials is to re-issue the certificate — which burns CA quota for what should be a single field edit. HandleSetDNS in mod/acme/autorenew.go is the underlying writer but it is only invoked as part of the obtain flow, not exposed as a standalone editor.

Describe the solution you'd like

a) Full cleanup on cert delete. Extend RemoveCert (or its caller HandleCertRemove) to also:

• delete <name>.json in conf/certs/
• delete every key in the acme bucket prefixed with <name>_ (_dns_provider, _dns_credentials, _dns_servers)

b) UI action: "Edit DNS credentials". A dedicated form (and /api/cert/dns/edit-style endpoint) for updating _dns_provider / _dns_credentials / _dns_servers of an existing certificate without re-issuance. Internally just wraps the existing HandleSetDNS logic outside of the obtain flow.

c) Bonus: "Reset all ACME state". A button in ACME Settings that wipes the acme + acmepref buckets and all <name>.json files. Useful when switching providers globally or after restoring from an old backup. I wrote a one-off Go utility against bbolt to do exactly this — happy to share if it would help shape the implementation.

Describe alternatives you've considered

• Manually editing sys.db with a custom bbolt tool (what I had to do — requires stopping Zoraxy and writing/running Go code; high friction).
• Re-issuing the cert just to rotate a credential (wasteful, hits CA rate limits).

Additional context

• Zoraxy v3.3.3, bare-metal install, BoltDB backend.
• Migrating from reg.ru wildcard certs to Cloudflare triggered all three pain points in one session.

[tobychui]

Hi @zen8841 , you got any idea about this?

I am thinking maybe we just need to do proper cleanup for the json file and left over metadata in the database and this issue will be resolved?

[zen8841]

a) I will fix this soon.

b) This feature seems great, but it seems to involve a lot of complicated things. I will implement it when I have time. I'll temporarily shelve this issue after updating to legov5.

c) This function seems scary; I'm a little worried about accidental activation. The chances of using it are also very low. You can directly use boltborwser to delete key-value pairs in the database, and then directly rm conf/acme/*.json, etc. Of course, if you are willing to share the script you use, others will thank you if they need it.

By the way, the issue of issuing a large number of certificate triggering the CA's rate limit has been fixed in v3.3.4. Now it will reuse the ACME account. As for cert, Let's Encrypt allows 300 certs/3 hours. As long as the number of credentials does not exceed 300, the rate limit will not be triggered.