nginx-proxy / acme-companion

Automated ACME SSL certificate generation for nginx-proxy
MIT License
7.42k stars 824 forks source link

Can't access acme-challenge 404 #506

Closed ribsies closed 5 years ago

ribsies commented 5 years ago

Alright so I have hit the end of my capabilities to fix this issue.

I am getting the ERROR:simp_le:1446: CA marked some of the authorizations as invalid error when attempting to create certs for my proxies.

I believe I have narrowed it down to not being able to have access to the acme-challenge path.

I am using the basic 2 container setup with no changes. My full docker-config looks like this

version: '2'

services:
    nginx-proxy:
        image: jwilder/nginx-proxy:alpine
        container_name: nginx-proxy
        ports:
            - "80:80"
            - "443:443"
        volumes:
            - /share/nginx/conf.d:/etc/nginx/conf.d
            - /share/nginx/vhost.d:/etc/nginx/vhost.d
            - /share/nginx/html:/usr/share/nginx/html
            - /share/nginx/dhparam:/etc/nginx/dhparam
            - /share/nginx/certs:/etc/nginx/certs:ro
            - /var/run/docker.sock:/tmp/docker.sock:ro
        network_mode: bridge

    letsencrypt:
        image: jrcs/letsencrypt-nginx-proxy-companion:latest
        container_name: nginx-proxy-le
        environment:
            - NGINX_PROXY_CONTAINER=nginx-proxy
            - ACME_CA_URI=https://acme-staging.api.letsencrypt.org/directory
            - DEBUG=true
        volumes_from:
            - nginx-proxy
        volumes:
            - /share/nginx/certs:/etc/nginx/certs:rw
            - /var/run/docker.sock:/var/run/docker.sock:ro
        network_mode: bridge
    tautulli:
        image: linuxserver/tautulli:latest
        container_name: tautulli
        depends_on:
            - letsencrypt
        volumes:
            - /share/Plex/Tautulli:/config
            - /share/CACHEDEV1_DATA/.qpkg/PlexMediaServer/Library/Plex\ Media\ Server/Logs:/logs:ro
        restart: unless-stopped
        environment:
            - TZ=America/Los_Angeles
            - PGID=100
            - PUID=1000
            - VIRTUAL_HOST=sub.domain.com
            - LETSENCRYPT_HOST=sub.domain.com
            - LETSENCRYPT_EMAIL=my.email@email.com
        ports:
            - 8181:8181

I have gone through the troubleshooting here multiple times and as far as I can tell, everything is good.

The only part that is failing is at the end with the test acme-challenge.

When I curl http://yourdomain.tld/.well-known/acme-challenge/hello-world I get a 404.

I have absolutely no idea how to fix this. I've been at it a few days.

Any ideas?

Here is my error log

{
  "identifier": {
    "type": "dns",
    "value": "sub.domain.com"
  },
  "status": "invalid",
  "expires": "2019-02-16T03:20:10Z",
  "challenges": [
    {
      "type": "tls-alpn-01",
      "status": "invalid",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/Qpmiiukv-6QdoH71-G53A5mcQZRK0wzRiLXo4lkn9MM/242149060",
      "token": "fWBBq7xn2SgNbGUZMATIEm-AozODFje00rz68_B7CNk"
    },
    {
      "type": "dns-01",
      "status": "invalid",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/Qpmiiukv-6QdoH71-G53A5mcQZRK0wzRiLXo4lkn9MM/242149061",
      "token": "89vfl5rPwXVGRcnCQWcdQsEQ0Tvd_n_8CB8yfmq4Bq8"
    },
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:unauthorized",
        "detail": "Invalid response from http://sub.domain.com/.well-known/acme-challenge/M4biEYs39AESm-JEQr7rdPWdQs4trIvd01_OMLJszGY: \"\u003chtml\u003e\\r\\n\u003chead\u003e\u003ctitle\u003e404 Not Found\u003c/title\u003e\u003c/head\u003e\\r\\n\u003cbody bgcolor=\\\"white\\\"\u003e\\r\\n\u003ccenter\u003e\u003ch1\u003e404 Not Found\u003c/h1\u003e\u003c/center\u003e\\r\\n\u003chr\u003e\u003ccenter\u003e\"",
        "status": 403
      },
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/Qpmiiukv-6QdoH71-G53A5mcQZRK0wzRiLXo4lkn9MM/242149062",
      "token": "M4biEYs39AESm-JEQr7rdPWdQs4trIvd01_OMLJszGY",
      "validationRecord": [
        {
          "url": "http://sub.domain.com/.well-known/acme-challenge/M4biEYs39AESm-JEQr7rdPWdQs4trIvd01_OMLJszGY",
          "hostname": "sub.domain.com",
          "port": "80",
          "addressesResolved": [
            "24.4.185.205"
          ],
          "addressUsed": "24.4.185.205"
        }
      ]
    }
  ],
  "combinations": [
    [
      0
    ],
    [
      2
    ],
    [
      1
    ]
  ]
}
ribsies commented 5 years ago

I have since been led to believe that it is related to permissions. My nginx container seems to not have access to anything.

Not sure how to fix that.

I'm using these containers on a QNAP NAS.

buchdag commented 5 years ago

My nginx container seems to not have access to anything.

By this do you mean that the volumes are correctly mounted inside the container but with no read permission, or are the volume not even correctly mounted ?

ribsies commented 5 years ago

Sorry I misspoke. What I meant was it can't read anything in the html through the sub domain. Meaning I get this error when trying to access the test item in acme-challenge

2019/02/11 00:59:32 [crit] 38#38: *85 stat() "/usr/share/nginx/html/.well-known/acme-challenge/hello-world" failed (13: Permission denied), client: 76.103.132.118, server: sub.mydomain.com, request: "GET /.well-known/acme-challenge/hello-world HTTP/1.1", host: "sub.mydomain.com" 

As far as I can tell, all of the volumes are mounting fine.

buchdag commented 5 years ago

Your /share/nginx/html host folder might have permissions that prevents the container's nginx process from reading files inside it. Try using a docker named volume instead of a bind mount.

I'd personally advise to avoid bind mount whenever possible as they more often than not lead to permission issues.

buchdag commented 5 years ago

No update from issue's creator for > 4 months, closing.

RubberDuck2000 commented 3 years ago

I know this is closed, but I could imagine, that I had the same Problem like ribsies. It cost me some time, but I find out that there is a problem with permissions on QNAP Container Station if you have the "Windows ACL Support" Option enabled. If you disable this option everything works like it should.