feat: boolean variable ACME_HTTP_CHALLENGE_LOCATION #2468
Conversation
|
@pini-gh the variable should be set to The priority for now is to avoid breaking existing setups (even if they insist on using |
| @@ -750,6 +753,7 @@ server { | |||
| try_files $uri =404; | |||
| break; | |||
| } | |||
| {{- end }} | |||
There was a problem hiding this comment.
There are broken use cases with both defaults:
true
acme_companion configures an extraneous HTTP Challenge location block which is not valid.
false
Use cases where certificates are not generated with acme_companion loose HTTP Challenge configuration and may fail to renew their certificates.
Why not fixing acme_companion instead?
EDIT: The easiest way would be to keep the default as true and update acme_companion so it wouldn't generate the HTTP Challenge configuration by default (but for standalone certificates).
EDIT1: moving this comment with was on the wrong thread.
There was a problem hiding this comment.
How about having 3 possible values for ACME_HTTP_CHALLENGE?
legacy: previous incomplete behaviortrue: generate ACME HTTP Challenge location blocks whenHTTPS_METHODis in [redirect,noredirect] (current default behavior)false: do not generate ACME HTTP Challenge location blocks
And we set the new default to legacy.
There was a problem hiding this comment.
The legacy / true / false solution with legacy being the default (until we change acme-companion default behaviour, which I plan on doing soon) seems perfect to me, if it's not too much additional work for you.
Why not fixing acme_companion instead?
Because I'm a bit short in time this week 😬 but that's planned, yes.
(by the way regarding acme-companion and it's location tinkering, I tried to automatically skip location configuration when not required a few years ago, I could not come up with anything else than very hacky and fragile solutions that did not even work in the end. Manually enabling or disabling location configuration as you suggest seem to be the only realistic way).
There was a problem hiding this comment.
Minor request: could we use ACME_HTTP_CHALLENGE_LOCATION instead of ACME_HTTP_CHALLENGE ?
d8495d1 to
b5b1320
Compare
Values: * `legacy` (default): generate location blocks for ACME HTP Challenge excepted when `HTTPS_METHOD=noredirect` or there is no certificate for the domain * `true`: generate location blocks for ACME HTP Challenge in all cases * `false`: do not generate location blocks for ACME HTP Challenge This feature is currently needed because acme-companion may generate the HTTP Challenge configuration while it was done already by nginx-proxy (see nginx-proxy#2465#issuecomment-2136361373). Also sometimes a hardcoded ACME challenge location is not wanted because the challenge validation is not done with acme-companion / Let's Encrypt, and with a challenge location setup differently.
b5b1320 to
854427c
Compare
|
Hi @pini-gh, Just an idea here for the location block: Perhaps set So you would have a server {
server_name localhost.pwn.college;
access_log /var/log/nginx/access.log vhost;
http2 on;
listen 80 default_server;
{{ if eq (or (index $globals.Env "ACME_ENABLED") "false") "false" }}
] location /.well-known/acme-challenge/ {
auth_basic off;
allow all;
root /usr/share/nginx/html;
try_files $uri =404;
break;
}
{{ end }}
listen 443 ssl default_server;
ssl_certificate /etc/nginx/certs/default.crt;
ssl_certificate_key /etc/nginx/certs/default.key;
if ($https) {
return 500;
}
include /etc/nginx/vhost.d/default;
location / {
proxy_pass http://localhost.pwn.college;
set $upstream_keepalive false;
include /etc/nginx/vhost.d/default_location;
}
}Setting these environment variables, I'm obviously talking about Docker Compose: environment:
- ACME_ENABLED=false # set to true in productionThis is only an idea, maybe it helps or gets something stirring. Have a wonderful Thursday. |
All the uses cases are enabled by the current PR already:
|
Values: * `legacy` (default): generate location blocks for ACME HTP Challenge excepted when `HTTPS_METHOD=noredirect` or there is no certificate for the domain * `true`: generate location blocks for ACME HTP Challenge in all cases * `false`: do not generate location blocks for ACME HTP Challenge This feature is currently needed because acme-companion may generate the HTTP Challenge configuration while it was done already by nginx-proxy (see nginx-proxy#2465#issuecomment-2136361373). Also sometimes a hardcoded ACME challenge location is not wanted because the challenge validation is not done with acme-companion / Let's Encrypt, and with a challenge location setup differently.
Enable / disable ACME HTTP Challenge blocks generation by nginx-proxy.
Default: true.
This feature is currently needed because acme-companion may generate the HTTP Challenge configuration while it was done already by nginx-proxy (see #2465#issuecomment-2136361373).
Also sometimes a hardcoded ACME challenge location is not wanted because the challenge validation is not done with acme-companion / Let's Encrypt, and with a challenge location setup differently.