Redondant config about acme-companion

[buchdag]

@azlux the issue here is we have no reliable way (or more accurately I haven't found one yet, despite trying) to tell that someone is using acme-companion with an nginx-proxy template that already include the .well-known/acme-challenge config, so the companion has to dynamically insert it just in case.

I agree that it's not ideal and that the redundant config does not look good, but since it should not have much of an impact, getting rid of it has been a low priority.

[buchdag]

@azlux I'm reopening this issue because it's going to be fixed in both nginx-proxy and acme-companion soon.

[Montana]

What are the actual results of nginx -T?

[azlux]

Something like that :

# cloud.azlux.fr/
upstream cloud.azlux.fr {
    # Container: nextcloud
    #     networks:
    #         infra_backend (reachable)
    #         infra_backend_av (unreachable)
    #         infra_database_postgres (unreachable)
    #         infra_database_redis (unreachable)
    #         infra_mail (unreachable)
    #     IP address: 172.20.0.16
    #     exposed ports: 80/tcp
    #     default port: 80
    #     using port: 80
    server 172.20.0.16:80;
}
server {
    server_name cloud.azlux.fr;
    access_log /var/log/nginx/access.log vhost;
    listen 80 ;
    listen [::]:80 ;
    # Do not HTTPS redirect Let's Encrypt ACME challenge
    location ^~ /.well-known/acme-challenge/ {
        auth_basic off;
        auth_request off;
        allow all;
        root /usr/share/nginx/html;
        try_files $uri =404;
        break;
    }
    location / {
        return 301 https://$host$request_uri;
    }
}
server {
    server_name cloud.azlux.fr;
    access_log /var/log/nginx/access.log vhost;
    http2 on;
    listen 443 ssl ;
    listen [::]:443 ssl ;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_certificate /etc/nginx/certs/cloud.azlux.fr.crt;
    ssl_certificate_key /etc/nginx/certs/cloud.azlux.fr.key;
    ssl_dhparam /etc/nginx/certs/cloud.azlux.fr.dhparam.pem;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/certs/cloud.azlux.fr.chain.pem;
    set $sts_header "";
    if ($https) {
        set $sts_header "max-age=31536000";
    }
    add_header Strict-Transport-Security $sts_header always;
    include /etc/nginx/vhost.d/cloud.azlux.fr;
    location / {
        proxy_pass http://cloud.azlux.fr;
        set $upstream_keepalive false;
    }
}

[...]
# configuration file /etc/nginx/vhost.d/default:
## Start of configuration add by letsencrypt container
location ^~ /.well-known/acme-challenge/ {
    auth_basic off;
    auth_request off;
    allow all;
    root /usr/share/nginx/html;
    try_files $uri =404;
    break;
}
## End of configuration add by letsencrypt container

# configuration file /etc/nginx/vhost.d/cloud.azlux.fr:
## Start of configuration add by letsencrypt container
location ^~ /.well-known/acme-challenge/ {
    auth_basic off;
    auth_request off;
    allow all;
    root /usr/share/nginx/html;
    try_files $uri =404;
    break;
}
## End of configuration add by letsencrypt container
client_max_body_size 1024m;

[azlux]

@buchdag because you don't consider nginx-proxy and acme-companion as a stack ? Do you really need to check the acme .well-know location existancec since both member of the stack is running for a working SSL nginx.

[buchdag]

Wether anyone consider it a stack or not isn't really the question here, the issue comes from the fact that people might unexpectedly combine new version of acme-companion with older versions of nginx-proxy (or the nginx-proxy template when running in three containers configuration). If .well-known automatic configuration is removed from acme-companion, this combination will result in failed certificate creation.

Again I know this isn't ideal, I know the versions of nginx-proxy incompatible with the removal of the automatic .well-known configuration are really old (0.7.0 and below, so ~5 years old), I'll come to this eventually but right now this, to the best of my knowledge, does not cause any issue beside the full configuration looking bad and redundant, so it's a low priority (my current priority is this feature).