Unable to verify with letsencrypt about acme-companion HOT 16 CLOSED

Don't use https for you zetta container.
nginx-proxy talk to local containers using pure http protocol. Not https.
So retry removing VIRTUAL_PROTO=https in your zetta container

from acme-companion.

Hi, thanks for the suggestion! I tried it with the VIRTUAL_PROTO=https part removed and I'm seeing the same error in the logs :/. Anything else I should try?

from acme-companion.

Check that zetta.justbuchanan.com is well resolved to the ip of the nginx-proxy.

from acme-companion.

Thanks for this. Got really excited that I might have made this work out but then I got the same error with virtually the same configuration:
`proxy:
image: jwilder/nginx-proxy
container_name: proxy
ports:
- "80:80"
- "443:443"
volumes:
- /mnt/docker/certs:/etc/nginx/certs:ro
- /etc/nginx/vhost.d
- /usr/share/nginx/html
- /var/run/docker.sock:/tmp/docker.sock:ro
environment:
- DEFAULT_HOST=example.com
- VIRTUAL_HOST=example.com

letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
container_name: letsencrypt
volumes_from:
- proxy
volumes:
- /mnt/docker/certs:/etc/nginx/certs:rw
- /var/run/docker.sock:/var/run/docker.sock:ro

dreg:
image: registry:2
container_name: dreg
hostname: dreg
ports:
- "5000:5000"
volumes:
- /mnt/docker-aux/docker-reg:/var/lib/registry
- /mnt/docker/certs:/certs:ro
environment:
VIRTUAL_HOST: dreg.example.com
LETSENCRYPT_HOST: dreg.example.com
LETSENCRYPT_EMAIL: [email protected]`

Trying to setup my own docker registry. LETSENCRYPT container output:

Reloading nginx proxy... Q2016/02/05 05:51:58 Generated '/etc/nginx/conf.d/default.conf' from 2 containers ;2016/02/05 05:51:58 [notice] 39#39: signal process started Creating/renewal dreg.example.com certificates... (dreg.example.com) 2016-02-05 05:51:58,844:INFO:simp_le:1210: Generating new account key 2016-02-05 05:52:00,131:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:00,652:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:00,971:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:01,534:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): letsencrypt.org 2016-02-05 05:52:02,061:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:02,455:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:02,880:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): dreg.example.com 2016-02-05 05:52:02,942:INFO:simp_le:1311: dreg.example.com was successfully self-verified 2016-02-05 05:52:02,951:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:03,343:INFO:simp_le:1319: Generating new certificate private key 2016-02-05 05:52:04,799:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:09,107:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-02-05 05:52:09,432:ERROR:simp_le:1277: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Is there a warning log entry about unsuccessful self-verification? Are all your domains accessible from the internet? Failing authorizations: https://acme-v01.api.letsencrypt.org/acme/authz/UCvJnsaUEV5-altIPt_mnsvBi-jF2rqo4TAgf5Ef1jk Challenge validation has failed, see error log.

nginx default.conf entries look like this:
upstream dreg.example.com { # dreg server 172.17.0.5:5000; } server { server_name dreg.example.com; listen 80 ; access_log /var/log/nginx/access.log vhost; include /etc/nginx/vhost.d/default; location / { proxy_pass http://dreg.example.com; }

I'm kind of a noob at nginx but this looks right. dreg.example.com is accessible from the internet. Any tips?

edit: formatting

from acme-companion.

Check that /etc/nginx/vhost.d/defaultcontain configuration for the .well-known directory

from acme-companion.

This is what is in /etc/nginx/vhost.d/default

##Start of configuration add by letsencrypt container
location /.well-known/ {
    auth_basic off;
    root /usr/share/nginx/html;
    try_files $uri =404;
} 
##End of configuration add by letsencrypt container

I'm guessing this is correct?

from acme-companion.

getting a 503 just starting the jwilder/nginx-proxy with no extra config other than what was in the docker-compose.yml post above.

Stopped that and pulled the office nginx image and started with:
docker run -d -p 80:80 nginx

and was greeted with the Welcome to nginx default index.html

Must be something missing in the way I'm running jwilders image. Off to compare conf files...

from acme-companion.

Try also to remove the enviroment vraiables DEFAULT_HOST=example.comand VIRTUAL_HOST=example.com from the nginx-proxy container

from acme-companion.

nevermind... not sure I'm saying this right but letsencrypt doesn't work when there isn't an http port exposed on the target container. The docker registry exposes port 5000 but it's not a web/http port. That was the hang-up. I just tried with a 2nd nginx container on port 8080 and everything worked perfectly. Thanks for sticking with me.

from acme-companion.

In your web container you must specify your listen port with the environment variable VIRTUAL_PORT(see the documentation of nginx-proxy)

from acme-companion.

@johnny2678 May I ask, did you manage to create a certificate for Docker Registry container in the end? Automatically that is, with this docker companion container of course :)

from acme-companion.

@tinybitsofnothingness yep, at one point I had it working on two subdomains. Both showed up as secure when using http and https. Then reconfigured one of them and attempted to regenerate the cert, hit the cert limit, and now neither works. Prob something on my end... but need to wait for the cert ban to be lifted before I can keep testing. Is it 7 days?

from acme-companion.

@johnny2678 Yeah, it's 7 days... You can check the details of certificate for your domain at crt.sh.
I'm really curios why doesn't it work for me then... I have more/less exactly the same configuration, but keep getting the same error for my Docker Registry container which runs on port 5000, even if I include VIRTUAL_PORT variable... Will try to recreate everything from the scratch maybe...

from acme-companion.

oh, it won't work for Docker reg (at least I couldn't get it too). Letsencrypt has to be able to connect to an http backend (web server/app server) to verify/create the cert. Saw that somewhere but can't remember where now, so I gave up.

Certs generated fine when proxypassing to an nginx container running on 8080. Also got a gogs container to work.

from acme-companion.

Ah, I see... Maybe it could be done with manual config addition for particular vhost or maybe even with additional "dummy" container which would properly respond to letsencrypt and generate/renew certs which could be used for Docker Registry...

from acme-companion.

i'm sure a smart person could figure it out ;)

from acme-companion.