ACME requests are routed to container

[pchinery]

Bug description

I have two containers that do not get certificates. It is possible that they were not running properly at the beginning, which triggered a rate limit on letsencrypt at the beginning. At this point, they run flawlessly. If I expose their ports directly, I can access them via http. If I run a curl from the nginx container to the IP and port, I receive the correct content.

After some investigation, I found that (I think) the 'default.conf' is not being generated correctly. The section looks like this:

server {
    server_name wiki.mydomain.tld;
    http2 on;
    access_log /var/log/nginx/access.log vhost;
    listen 80 ;
    listen 443 ssl ;
    # No certificate found for this vhost, so use the default certificate and
    # return an error code if the user connects via https.
    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://wiki.mydomain.tld;
        set $upstream_keepalive false;
    }
}

There is no block to actually handle the acme request (location ^~ /.well-known/acme-challenge/) that is present in the working container configs. I can also confirm that the acme requests ends up with the container, where it of course can't be handled.

acme-companion image version

Info: running acme-companion version v2.6.0-4-g1fd6385

nginx-proxy's Docker configuration

I have a Dockerfile (below) for the proxy to set an upload limit.

version: '3'

services:
  nginx-proxy:
    build: ./proxy
    container_name: nginx-proxy
    environment:
      - RESOLVERS=8.8.8.8 8.8.4.4
    labels:
      com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: "true"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - conf:/etc/nginx/conf.d
      - vhost:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - certs:/etc/nginx/certs:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      - proxy-tier
    restart:
      unless-stopped

  acme-companion:
    image: nginxproxy/acme-companion
    container_name: nginx-proxy-acme
    environment:
      - DEFAULT_EMAIL=abc@mydomain.tld
    volumes_from:
      - nginx-proxy
    volumes:
      - certs:/etc/nginx/certs:rw
      - acme:/etc/acme.sh
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - proxy-tier
    restart:
      unless-stopped

volumes:
  conf:
  vhost:
  html:
  certs:
  acme:

Dockerfile:

FROM jwilder/nginx-proxy:alpine

COPY uploadsize.conf /etc/nginx/conf.d/uploadsize.conf

uploadsize.conf

client_max_body_size 10G;
proxy_request_buffering off;

Containers logs

acme-companion logs:

nginx-proxy-acme  | Creating/renewal wiki.mydomain.tld certificates... (wiki.mydomain.tld)
nginx-proxy-acme  | [Wed Jun 25 16:36:20 UTC 2025] Using CA: https://acme-v02.api.letsencrypt.org/directory
nginx-proxy-acme  | [Wed Jun 25 16:36:21 UTC 2025] Using pre-generated key: /etc/acme.sh/abc@mydomain.tld/wiki.mydomain.tld/wiki.mydomain.tld.key.next
nginx-proxy-acme  | [Wed Jun 25 16:36:21 UTC 2025] Generating next pre-generate key.
nginx-proxy-acme  | [Wed Jun 25 16:36:21 UTC 2025] Single domain='wiki.mydomain.tld'
nginx-proxy-acme  | [Wed Jun 25 16:36:24 UTC 2025] Getting webroot for domain='wiki.mydomain.tld'
nginx-proxy-acme  | [Wed Jun 25 16:36:25 UTC 2025] Verifying: wiki.mydomain.tld
nginx-proxy-acme  | [Wed Jun 25 16:36:25 UTC 2025] Pending. The CA is processing your order, please wait. (1/30)
nginx-proxy-acme  | [Wed Jun 25 16:36:28 UTC 2025] wiki.mydomain.tld: Invalid status. Verification error details: 167.235.198.252: Invalid response from http://wiki.mydomain.tld/.well-known/acme-challenge/2wJqun5pOUUW-meke3g-LIAaA_zMWLxSR-DXu2vVjCY:
nginx-proxy-acme  | [Wed Jun 25 16:36:28 UTC 2025] Please check log file for more details: /dev/null

This is to be expected as the request is routed to the container, where it can't be handled.

Docker host

• OS: Ubuntu 22.04.3 LTS
• Docker version: 24.0.7

[pchinery]

After investigating a bit further, I found a workaround: When I copy the certificates from another domain, the nginx template is created correctly and thus the validation can be completed and a real certificate can be generated. Still wondering how it could come to this situation. Is there a way to edit the template?

[BIzZmarCk]

I ve the same issues and lost all my old certificates is there another workaround?

[buchdag]

@BIzZmarCk could you please provide the version of nginx-proxy and acme-companion you're using ?

[BIzZmarCk]

nginxproxy/nginx-proxy latest sha256:b13711a177669f6cb99bbe394937298da329486f7f2690386d7b4ef221b519e7 429755be6df2 3 days ago 212MB
nginxproxy/acme-companion latest sha256:6707bfd09e11a3ffe1582260928518adf75be43c742a45f2ce14c998d3e494b2 f887c6b126bd 2 weeks ago 54.4MB

I also ve a custom.conf file to append to the default conf and i also ve the line inside (the only line): client_max_body_size 20G;

[TonyRogers]

After investigating a bit further, I found a workaround: When I copy the certificates from another domain, the nginx template is created correctly and thus the validation can be completed and a real certificate can be generated. Still wondering how it could come to this situation. Is there a way to edit the template?

Could you explain your workaround in more detail? I may be having similar issues.

Many thanks.

[TonyRogers]

After investigating a bit further, I found a workaround: When I copy the certificates from another domain, the nginx template is created correctly and thus the validation can be completed and a real certificate can be generated. Still wondering how it could come to this situation. Is there a way to edit the template?

Could you explain your workaround in more detail? I may be having similar issues.

Many thanks.

After trawling through the updates and comments, I seem to have resolved this, by following this: https://github.com/nginx-proxy/acme-companion/releases/tag/v2.4.0

Release info

Sorry, not sure how to link correctly!

[buchdag]

@TonyRogers that's what I suspected too because the symptoms should be very similar, but in @BIzZmarCk's case the mentioned versions should not be affected. 🤔

[pchinery]

Could you explain your workaround in more detail? I may be having similar issues.

I use this script to bring the certificates into a state where the ACME processing works:

#!/bin/bash

DOMAIN=$1

if [ "$#" -ne 1 ]; then
    echo "Usage: $0 domain"
    exit 1
fi

if [ -z "$DOMAIN" ]; then
    echo "Usage: $0 domain"
    exit 1
fi

docker compose exec acme-companion "ln -s /etc/nginx/certs/${DOMAIN}/chain.pem /etc/nginx/certs/${DOMAIN}.chain.pem"
docker compose exec acme-companion "ln -s /etc/nginx/certs/${DOMAIN}/fullchain.pem /etc/nginx/certs/${DOMAIN}.crt"
docker compose exec acme-companion "ln -s /etc/nginx/certs/${DOMAIN}/key.pem /etc/nginx/certs/${DOMAIN}.key"
docker compose exec acme-companion "ln -s /etc/nginx/certs/dhparam.pem /etc/nginx/certs/${DOMAIN}.dhparam.pem"

docker compose down && docker compose up -d