-
Notifications
You must be signed in to change notification settings - Fork 3.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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
3928efb
to
19c67d3
Compare
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 that optionally passing ACME challenge for unknown virtual host might be a nice to have feature, but not to make it default. |
@buchdag Do you think it makes sense to add another option to |
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
to
0d195b1
Compare
@buchdag I've updated the PR to use separate This PR should be good to go. |
0d195b1
to
48df2c7
Compare
@buchdag Just a friendly ping.. :) |
test/test_acme-http-challenge-location/test_acme-http-challenge-location-accept-unknown.yml
Outdated
Show resolved
Hide resolved
@p12tic this look good to me save maybe for the name of the environment variable :
What do you think ? |
48df2c7
to
4319a56
Compare
@buchdag Thanks for review. I agree with all your comments and have applied fixes. |
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. Accordingly, it's worthwhile supporting unknown virtual hosts for the purposes of passing ACME challenges. This is done by introducing a global ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN_HOST variable to control this.
4319a56
to
4c8f22e
Compare
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.