Hacker News Reader

Comment by sandGorgon | Hacker News Reader

Is anyone using letsencrypt using nginx+docker ? How do you take care of the chicken and egg situation when you spawn a nginx docker container - nginx cannot start without a valid certificate and you cannot generate a valid certificate without nginx.

I haven't looked into this for about six months - I just bought a wildcard SSL certificate for 70$ and called it a day.

View on HN

Is the reason that nginx wouldn't start because you're specifying the certificate location in the config?

So when it goes to start up it will fail because ther is no certificate in place? (If not then tell me why Nginx won't start).

If that's the case, don't link to where the certificate should be. That'll let nginx start, then the certbot-nginx tool can run and it'll add links to the generated certificates directly to your config files as part of the initilisation.

All it does is insert the paths to the certificate files before the final closing bracket of any server block that listens on port 443.

I use Ansible and automate the install of new server/sites, unless there's something extra different with Docker, the automation process should still work fine. It also still works if your config is setup to redirect all incoming from port 80 to 443.

One time run commands and dependent commands are difficult in docker init. So I have to fall back upon a startup manager like supervisord. I tried that last time , but it was very funky.

Docker VM are like short lived machines with no dependency management in init. But 70$ for 3 years is a cheap price to pay versus giving up docker , nginx (vs traefik), etc

Still, it seems unusual to not be able to run a set of commands on initialisation.

I haven't looked at Docker in a long time, but isn't there something called an entryscript? I'm not sure I'm remembering the name correctly -

- yep, entrypoint script not entryscript.

I remember something about setting up Wordpress in Docker and the official docker image has this type of script that initialised the database just once.

Might be worth looking into just for interest (maybe not for fixing this 'issue' as you point out its cheap to get a 3 year cert). I imagine one time init commands would be useful to have in their own right anyway.

I used it, and I used a combination of manual and automated steps.

It wasn't worth it in the end, perhaps you could look into traefik or caddy. Both can automatically request and refresh certificates for you, caddy is good for hobby projects and is very easy to configure, traefik offers a lot of features and can be a bit harder to setup, but is truly awesome if you connect it to an orchestrator for automatic request routing.

Using letsencrypt + nginx. You start with just a http server, letsencrypt does its thing and gives you a certificate, then you set up https.

Manual setup with a running nginx server is easy. It's when you have docker on the mix that it all goes for a toss.

Are you using docker to spawn nginx ?

Not using docker, but I fail to see how a single certbot command is "Manual setup" and not easily automated.

Because a docker machine spawns with the nginx executable - and because of letsencrypt is unable to start.

Docker services are not long running processes on a base OS. The entire OS is pretty much freshly created when you spawn a container. This gets to be an issue with letsencrypt.

What we do is take a 3 year certificate and bake it into docker build. So we only have to mess with it very infrequently. I can shutdown and scale my nginx containers (meaning - spawn new ones). Since the certificate is baked into the VM, it works seamlessly.

I would argue that you are using images wrong. An image should not contain credentials, and should be independent of deployment. We use the same image to test, deploy to staging, etc.

We always have a manually managed reverse proxy in front. For us, it takes care of TLS, caching, and makes me personally feel better than having the app HTTP/TLS stack facing the internet. This is just an nginx container with `/etc/nginx` mounted.

We also run certbot in a container. The two share a volume holding certs, and we do `certonly --webroot` to grab new certs. The container is not permanent, but launched from a script that essentially wraps certbot. Just need to disable the TLS vhost for a bit manually, and don’t forget to setup cron to refresh.

> We always have a manually managed reverse proxy in front. For us, it takes care of TLS, caching, and makes me personally feel better than having the app HTTP/TLS stack facing the internet. This is just an nginx container with `/etc/nginx` mounted.

well that is both your prerogative as well as your expenditure. We work in regulated spaces (finance in India) and dont get to have a lot of leeway in hosting and infrastructure. Docker is a lifesaver that way. Which is why we like letsencrypt, but it is a blocker for those of us using docker to run nginx itself.

Not sure I follow, we run nginx and certbot in Docker too? It's just that we manually manage its configuration, and need the extra (not too cumbersome) steps to get a cert up.

I usually copy a vhost config from one of our templates, comment out the TLS vhost, reload nginx, request cert, uncomment TLS vhost, reload nginx.

So, I'm not sure what's not possible in your setup? Unless there's a limitation on what kind of volumes you can connect to your containers?

Are you able to use docker's multi-stage builds in order to both start nginx and use letsencrypt?

Just wondering, why do you need nginx started to generate a valid certificate?

LetsEncrypt uses having some files able to be served from your webserver to verify domain ownership afaik.

The Let’s Encrypt client validates your server by placing a file on your website at a specific location.

There are other ways too, but this is the easiest.

If the server isn't started yet, the easiest way is to use the HTTP validation. Once it's started placing the file is easiest. You can use both methods.

Reply on news.ycombinator.com