Conversation
Every LE issuance and renewal goes through init_le(), which calls register() with the current key first, so a regenerated key just becomes a new account and renewals keep working. The old warning claimed existing certificates would not renew and that an account "will be registered", which is also wrong for commands that never register (site delete, alias update, ssl-verify). Only challenges still pending under the old account are affected. Also shorten the comments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
setAcmeClient()is binary: if the Let's Encrypt account key (acme-conf/account/key.private.pem) is present it loads it, otherwise it silently generates a new one. If that key is wiped while LE state still exists (host migration, snapshot restore, mis-fired cleanup), the next run silently mints a fresh account key. Renewals keep working (every issuance/renewal registers the current key first, so it just becomes a new account), but the old account is lost and any challenge still pending under it (e.g. anee site ssl-verifyfor a DNS-01 order) can no longer be completed, with no diagnostic.Fix
Detect the lost-key anomaly and warn loudly (a lost LE account key cannot be recovered, so this is detect-and-warn, not auto-recovery). When the account key is missing AND prior LE state exists on disk —
acme-conf/var/*(orders/challenges/DN) oracme-conf/certs/*(LE keypairs/certs), both written solely by AcmePhp —setAcmeClient()now emits clear warnings (the key appears lost and a new one is being generated; existing certificates stay valid and will be renewed under a new account, but challenges pending under the old account must be restarted; restoreacme-conf/account/from backup before the next SSL operation to keep the old account) before proceeding to generate.The signal deliberately uses LE-specific
acme-confstate, notservices/nginx-proxy/certs/(which also holds custom/self-signed certs), so it never false-positives on a non-LE host. On a genuine first run those dirs don't exist yet (AcmePhp creates them only after the account key), so issuance stays silent. The key-present load path and key generation are unchanged.Testing
Manual: with existing LE sites, remove
acme-conf/account/and run any SSL op → the warnings fire instead of a silent re-mint; a fresh host (noacme-conf) and a custom/self-signed-only host stay silent.Tested on Ubuntu 26.04 with EasyEngine 4.12.0: with LE state present and the account key moved away, the three warnings appear and a new key is generated; with the key present, or with no LE state, nothing is printed.