Nginx docker setup for LE

Server
1

Finally I got my letsencrypt beta invite(thanks for the great work you are doing!) and managed to create a reasonable setup for docker users which I would like to share and also receive feedback on how to improve.

I added a location in my nginx config redirectig the acme-challenge requests to the letsencrypt docker container instead of the actual application.

        location /.well-known/acme-challenge {
            proxy_pass http://localhost:1086;
            proxy_set_header Host            $host;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header X-Forwarded-Proto https;
        }

Then i request the certificate using the letsencrypt docker image

        docker run -it --rm -p 1086:80 -p 1087:443 --name letsencrypt \
        -v "/etc/letsencrypt:/etc/letsencrypt" \
        -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
        quay.io/letsencrypt/letsencrypt:latest auth --agree-dev-preview --server \
        https://acme-v01.api.letsencrypt.org/directory -d my.example.com

I had to forward ports 443 and 80 to successfully request a certificate, this was an issue in the current documentation.

A more detailed description including a sample config can be found at github

The setup works fine for requesting a certificate for the first time, but renewals currently fail with the following error:

Failed authorization procedure. my.example.com (dvsni): unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge

I tested it on the live and testing environment with the same error. Are renewals currently not supported?

1 Like
2

this looks like an issue I worked around a while ago in a similar setup that I plan to document more fully and post hopefully soon, my setup had to do with a system where everything was in lxc containers and with one exception for compatibility reasons I couldn’t work out unprivileged ones, while I have set it up so I can directly map public ip addresses through to containers with them actually taking the ip through routing (not nat forwarding, the ip is configured on the vm interface) for both security and keeping the ip count low and keeping things flexible I use one instance with most of the in use ip’s mapped to it and most instances don’t have any mapped through (though more then one does). That front end runs haproxy which is key here as what you are seeing is an issue with a dvsni challenge, you can’t forward those like that as that is looking for you to respond to a special name requested with server name indication with a special certificate, you need to use the webroot auth style to do that kind of forwarding, haproxy can with enough care, but almost anything else can’t, as it needs to process the ssl request for the sni name but not be terminating the ssl connection. Your best option though is probably using the webroot/simplehttp chalenge, rather than the effort to make dvsni work for you.

I know this post isn’t worded the best but I hope it helps, saying it well and concisely is exactly why I don’t yet have a post about my setup in detail yet out.

3

Meanwhile renewal of certificates also works with my docker setup. I did not have to change anything so I assume it has been solved on the server side somehow.