we have a shared macro/include used for letsencrypt verification, which proxies
requests to the `./well-known` directory onto an upstream provider.
the macro uses an old flag/semaphore based technique to toggle if the route is
enabled or not, so we can disable it when not needed. it works great.
location /.well-known/acme-challenge {
if (!-f /etc/nginx/_flags/letsencrypt-public) {
rewrite ^.*$ @ letsencrypt_public_503 last;
}
include /path/to/proxy_config;
}
location = @letsencrypt_public_503 {
internal;
return 503;
}
recently, letsencrypt dropped support for TLS authentication and now requires
port80. this has created a problem, because we run multiple ACME clients and
were able to segment the ones that hit our catchall/default servers based on
the protocol.
while many of our configs can use the existing files, a few need to support
both systems in a failover situation:
the current working version works around nginx config syntax to get around this…
location /.well-known/acme-challenge {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
set $acme_options "";
if (-f /etc/nginx/_flags/client_a) {
set $acme_options "client_a";
}
if (-f /etc/nginx/_flags/client_b) {
set $acme_options "${acme_options}.client_b";
}
if ($acme_options = "client_a") {
proxy_pass http://127.0.0.1:81;
break;
}
if ($acme_options = "client_a.client_b") {
proxy_pass http://127.0.0.1:81;
break;
}
if ($acme_options = ".client_b") {
proxy_pass http://127.0.0.1:6501;
break;
}
rewrite ^.*$ @acme_503 last;
}
i have some problems with this approach that I’d like to avoid, and wonder if
anyone has suggestions:
1. i’m lucky that proxy_set_header has shared info, it’s not allowed within an
“if” block.
2. i repeat the proxy_pass info much here, and it also exists in some other
macros which are shared often. there are many places to update.
there were other things I didn’t like, but I forgot. does anyone have a better
suggestion than my current implementation? it works for now, but it’s not
modular or clean.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
