Conversation
get_validated_le_mail() called EE::error(), which exits the process. During `ee site create --ssl=le` this bypassed the create try/catch, so an empty or invalid email at the prompt left an orphaned site (containers, webroot and proxy config, but no DB entry; re-create fails with "Webroot directory ... already exists"). Before the helper, the bad email made register() throw and the site was rolled back. Throw an exception instead so create and `ee site update --ssl` handle it through their existing catch blocks, and convert it to EE::error() in the direct ssl-verify and ssl-renew entry points. init_le() also reuses an already resolved le_mail, so a renewal no longer prompts twice.
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
The Let's Encrypt account email (
le-mail) was resolved with a??fallback that only guards null/unset — an empty string passed straight through to ACMEregister()/request(), producing a generic, confusing ACME failure. This affectedinit_le,ssl_verify, andssl_renew.Fix
Add a shared
get_validated_le_mail()helper: resolve from config (or prompt interactively), validate non-empty +filter_var( …, FILTER_VALIDATE_EMAIL ), and hard-error with a clear message (Set it with \ee config set le-mail `.`) when it can't be resolved (e.g. non-interactive cron with no le-mail set). All three sites route through it.If no valid email can be resolved during
ee site create --ssl=leoree site update --ssl=le, the helper throws, so site creation goes through the normal clean-up (no orphaned containers, webroot or proxy config).ssl-verifyandssl-renewprint the same "A valid Let's Encrypt email is required…" error and exit 1. Whenssl-renewhas already resolved the email,init_le()doesn't prompt a second time.In the renewal path the email is resolved after the
'le'/'inherit'site-type guard inrenew_ssl_cert(), so a non-LE single-sitessl-renewstill gets the accurate "Only Letsencrypt certificate renewal is supported." error rather than an email error.Note
Behaviour change: hosts with an empty or invalid
le-mailnow stop at renewal with the le-mail error, including the nightlyssl-renew --allcron (which stops at the first LE site). Such renewals may previously have gone through against an already-registered account. Set a validle-mail(ee config set le-mail <email>) before upgrading.Testing
Manual: with
le-mailunset/garbage, a non-interactive LE issuance/renew now exits cleanly with the "valid email required" message instead of an opaque ACME error; a validle-mailproceeds as before; a non-LEssl-renewstill reports the site-type error.Tested on Ubuntu 26.04 with EasyEngine 4.12.0:
create --ssl=lewith no le-mail and with a garbage le-mail plus an invalid answer at the prompt (clean rollback, config unchanged),ssl-renew/ssl-verifyon an LE site with no le-mail,ssl-renewon a non-LE site (site-type error, no prompt), and a create with a valid le-mail (no prompt).