search

nginx-proxy / acme-companion

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

CA marked some of the authorizations as invalid #201

Closed ekkis closed 5 years ago

ekkis commented 7 years ago

I previously suggested having a docker-compose file (https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion/issues/200) and am in the process of creating and testing it, however I'm running into issues. apparently .well-known is inaccessible. I've documented the issue here: http://stackoverflow.com/questions/43641812/ca-marked-some-of-the-authorizations-as-invalid

I don't understand enough about this so I need help. I gather that when the challenge comes in from the CA (on port 80?) it gets received by nginx and somehow routed to this module. I see this in the nginx_location.conf:

location ^~ /.well-known/acme-challenge/ {
    allow all;
    root /usr/share/nginx/html;
    try_files $uri =404;
    break;
}

which suggests it is this module that makes that answers that call. a look at that directory shows:

# ls -alF /usr/share/nginx/html
total 20
drwxr-xr-x    3 root     root          4096 Apr 26 19:01 ./
drwxr-xr-x    3 root     root          4096 Apr 26 19:01 ../
drwxr-xr-x    3 root     root          4096 Apr 26 06:04 .well-known/
-rw-r--r--    1 root     root           537 Apr 25 11:30 50x.html
-rw-r--r--    1 root     root           612 Apr 25 11:30 index.html

so I see the requested directory there, yet from looking at the error message, I see the challenge: https://acme-staging.api.letsencrypt.org/acme/authz/iAD9-HSmyVGb_kHwt0aLDRQHycIJzT3JooxEOTiTp48 which indicates a 403 error with "Cannot GET /.well-known/"

what am I doing wrong? or what can I research further to solve this?

ekkis commented 7 years ago

ok, I shut down the services, removed the volumes and restarted clean. that solved the problem

lounagen commented 7 years ago

Here are some ways of investigations: 0- I think that your line "command: -notify-sighup nginx ..." should be "command: -notify-sighup nginx-proxy" because you called your nginx container "nginx-proxy". Disclaimer: if your reload wasnt effective at all you should get à 404 instead of 403, so I can mistake myself 1- can you see the nginx configuration reload signal from docker logs nginx-proxy container? 2- by the time the letsencrypt companion is calling the LE endpoint, could you check if the nginx location template is well written in the vhost.d volume (vhost conf file must exist, named 'default' if I remember well, and its content is not empty) 3- can you check your nginx-proxy container logs to see any error that could explain the 403 (like permissions or whatever, because if the nginx location wasn't working at all, the error should have been 404), you could either check any strange permission in the .well-known folder hierarchy and if the challenge file looks correct (small text file) 4- your business website is currently online (sandbox.graph.speakr.com) on port 80, so just to be sure: are you really launching your docker-compose on the same server, with any reverse proxy or loadbalancer before it in the call chain? (It sounds obvious of course, but may be it worths mentionning it for some other people: the url needs to be accessed from Internet (outside the firewall/loadbalancer), not only from local network)

By the way - no direct link with this matter - I dont understand why you need to add a (network) link to nginx-proxy in your nginx-letsencrypt and ngnix-gen defintions. And as you didn't mention your business website in your docker compose I assume you have added it from another docker compose with the nginxproxy envvars

lounagen commented 7 years ago

Comments crossed themselves, glad that you resolved your problem 'magically'. Anyway, the template nginx.tmpl should come and refresh automatically from nginx-gens container, so for the associated #202, check the reload command for the nginx-proxy container name in nginx-gen definition. (When you restarted all, nginx reload its configuration by itself).

ekkis commented 7 years ago

I've added a docker-compose file to the project (see PR). in that pull request I also added a retrieval of the template, which is now included in the container and thence shared with docker-gen. I didn't realise that it should automatically refresh. if it's supposed to, it wasn't working because I had to manually refresh the template... so do you want to accept the PR as it is or do you want me to take that out (I think it will require a change to the docker-compose as well).

I did also change the docs. see if they are acceptable as they are

ekkis commented 7 years ago

ah... reading your previous comments. you're right, the reference to the nginx container was wrong. I will refresh the PR then. stand by

ekkis commented 7 years ago

ok, I've fixed the docker-compose file but I don't know how to eliminate the changes to the Dockerfile from the PR. can you ignore them when you apply it?

ekkis commented 7 years ago

let me step back a bit. in your docs you indicate I should retrieve the template:

curl https://raw.githubusercontent.com/jwilder/nginx-proxy/master/nginx.tmpl > /path/to/nginx.tmpl

and then mount it for docker-gen to have access to it:

$ docker run -d \
    --name nginx-gen \
    --volumes-from nginx \
    -v /path/to/nginx.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro \

but if I understand you correctly, your objection to my including the template in this project's docker image (to be shared with docker-gen) is that it should already be getting fetched automatically:

the template nginx.tmpl should come and refresh automatically from nginx-gen container

however, I don't imagine nginx-gen would be fetching it since it is a more generalised image and it really shouldn't be bound to the particular needs of this project... so the job should be this package's...

if I run the nginx-gen by itself (by merely providing it a place to find/presumably put the template), it just dies because it can't parse it (because it isn't there)... so I need to put it there, ergo my request to have in included in this package (to save the user from having to fetch it and figure out where to put it)...

so I think my PR stands as it is. does that make sense?

lounagen commented 7 years ago

@ekkis : when I said that nginx.tmpl came with nginx-gen, I meant that's nginx-gen's responsability:

Letsencrypt nginx-proxy companion container is 'only' an automation helper to call LE for you. Its responsability (from my understanding) is:

By the way, i'm not the maintainer, i've just discovered this really cool stuff some months ago (and experimented a small issue for the renew that led me to investigate deeper the internals), and i tried to help you as a participation to the community for a merged PR some weeks ago :-) so let you wait for @JrCs feedback for your PR/issues

ekkis commented 7 years ago

no worries. I think what I'm a little vague about is this: docker-gen (and its container) are generic functionality. give it a template and it will fill it for you with docker meta-data. the nginx.tmpl is specifically used to create the nginx configuration file

this (companion) package facilitates putting together all these containers with the resultant functionality that you have SSL for nginx, thus the nginx template used is specific to this setup and really belongs in this package. I have added line to the Dockerfile to automatically fetch the latest version of the template in my PR and orchestrated the docker-compose.yml so it all works without user intervention. in other words, grab the docker-compose, run, and you're done. nice and clean

nathancahill commented 6 years ago

Had a similar issue. Periodically, the .well-known route would fail to be caught by letsencrypt-nginx-proxy, ending up being passed to the underlying app and throwing an error. Shutting down the services and removing the volumes fixed the issue.

buchdag commented 5 years ago

Hopefully this issue is not relevant anymore. Closing.