- Notifications
You must be signed in to change notification settings - Fork3.1k
feat: support ACME challenges for unknown virtual hosts#2602
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
3928efb to19c67d3Comparebuchdag commentedMar 23, 2025
Hi@p12tic
This sounds like an issue with the ACME automation you're using rather than something caused by nginx-proxy itself. A properly designed automation should be able to re-use a previously issued certificate if the set of domains match and the certificate is still valid, instead of issuing a new one. That's what acme-companion does. Anyway I agree thatoptionally passing ACME challenge for unknown virtual host might be a nice to have feature, but not to make it default. |
p12tic commentedMar 24, 2025
@buchdag Do you think it makes sense to add another option to |
p12tic commentedApr 8, 2025
I agree, I used incorrect argument to make my point stronger. I did hit this limit in the past, but this was in a slightly different set of circumstances. The main issue is the requirement to refresh certificates each time a container is started because there exists possibility that the container was shut down while certificates were refreshed the last time. The perfect workflow would be to just give the list of all domains I could possible use to certbot and forget about it. It's not possible now, because validation may fail if a container is shut down. |
19c67d3 to0d195b1Comparep12tic commentedApr 9, 2025
@buchdag I've updated the PR to use separate This PR should be good to go. |
0d195b1 to48df2c7Comparep12tic commentedMay 2, 2025
@buchdag Just a friendly ping.. :) |
test/test_acme-http-challenge-location/test_acme-http-challenge-location-accept-unknown.yml OutdatedShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
buchdag commentedMay 8, 2025
@p12tic this look good to me save maybe for the name of the environment variable :
What do you think ? |
48df2c7 to4319a56Comparep12tic commentedMay 18, 2025
@buchdag Thanks for review. I agree with all your comments and have applied fixes. |
Currently any ACME challenge for unknown virtual host returns 503. Thisis inconvenient because if the user does not use wildcard certificates,then the user must match the configuration of certificate renewal scriptto what virtual hosts are enabled at the time.This must be done automatically, because due to short certificatelifetime the renewal script runs automatically. Additionally, enabling apreviously disabled virtual host forces certificate renewal.Accordingly, it's worthwhile supporting unknown virtual hosts for thepurposes of passing ACME challenges. This is done by introducing aglobal ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN_HOST variable to control this.
4319a56 to4c8f22eCompare554689c intonginx-proxy:mainUh oh!
There was an error while loading.Please reload this page.
Currently any ACME challenge for unknown virtual host returns 503. This is inconvenient because if the user does not use wildcard certificates, then the user must match the configuration of certificate renewal script to what virtual hosts are enabled at the time.
This must be done automatically, because due to short certificate lifetime the renewal script runs automatically. Additionally, enabling a previously disabled virtual host forces certificate renewal. Under certain circumstances this may lead to rate limiting from Let's Encrypt, because only 5 certificates for exact same set of domains can be issued per week.
Accordingly, it's worthwhile supporting unknown virtual hosts for the purposes of passing ACME challenges.