Skip to content

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

Merged
merged 2 commits into from
May 19, 2025

Conversation

p12tic
Copy link
Contributor

@p12tic p12tic commented Mar 14, 2025

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.

@p12tic p12tic force-pushed the acme-unknown-virtual-host branch from 3928efb to 19c67d3 Compare March 14, 2025 14:33
@buchdag
Copy link
Member

buchdag commented Mar 23, 2025

Hi @p12tic

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

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.

@p12tic
Copy link
Contributor Author

p12tic commented Mar 24, 2025

@buchdag Do you think it makes sense to add another option to ACME_HTTP_CHALLENGE_LOCATION or creating separate environment variable, like ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN? Former seems to be better because accepting unknown domains seems like a stronger true value.

@p12tic
Copy link
Contributor Author

p12tic commented Apr 8, 2025

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.

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.

@p12tic p12tic force-pushed the acme-unknown-virtual-host branch from 19c67d3 to 0d195b1 Compare April 9, 2025 00:30
@p12tic
Copy link
Contributor Author

p12tic commented Apr 9, 2025

@buchdag I've updated the PR to use separate ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN variable to control acceptance of unknown hosts. This made the logic way simpler and the PR better, thanks for the suggestion.

This PR should be good to go.

@p12tic p12tic force-pushed the acme-unknown-virtual-host branch from 0d195b1 to 48df2c7 Compare April 11, 2025 16:10
@p12tic
Copy link
Contributor Author

p12tic commented May 2, 2025

@buchdag Just a friendly ping.. :)

@buchdag
Copy link
Member

buchdag commented May 8, 2025

@p12tic this look good to me save maybe for the name of the environment variable :

ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN -> ACME_HTTP_CHALLENGE_ACCEPT_UNKNOWN_HOST

What do you think ?

@buchdag buchdag added the type/feat PR for a new feature label May 8, 2025
@p12tic p12tic force-pushed the acme-unknown-virtual-host branch from 48df2c7 to 4319a56 Compare May 18, 2025 21:54
@p12tic
Copy link
Contributor Author

p12tic commented May 18, 2025

@buchdag Thanks for review. I agree with all your comments and have applied fixes.

p12tic added 2 commits May 19, 2025 20:09
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.
@buchdag buchdag force-pushed the acme-unknown-virtual-host branch from 4319a56 to 4c8f22e Compare May 19, 2025 18:10
@buchdag buchdag changed the title Support ACME challenges for unknown virtual hosts feat: support ACME challenges for unknown virtual hosts May 19, 2025
@buchdag buchdag merged commit 554689c into nginx-proxy:main May 19, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feat PR for a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy