What happens to certificates on container's restart? And can we copy and paste certs?

[amankapoor]

Yesterday I messed up my site by fiddling with Cloudflare settings and long story short, I lost my original cert for a test cert after which I messed up more by exhausting rate limits and also had to wait 24 hours to change Cloudflare's SSL mode back from full strict to no SSL.

What I was wishing was by the end of the day, if I had backed up my first cert then I would not have face those issues. So if I had a backup and copied back my original cert and removed the newly generated test cert, then my site would show the previous (original) cert right? Does LetsEncrypt keep record of latest cert generated for a domain name and restricts to using that latest cert only?

And, here are some more questions concerning re deployment of containers.

1. What happens to the certificates when I restart, stop-then-start, remove-then-start etc a container (volume not deleted). Do the previous certs are discovered first and used if available, which I most probably think is happening behind the scenes. Or, new cert is created every time?

2. When running the container again, is there any need to use the LETSENCRYPT_HOST and other le env vars again. Can I not simply use VIRTUAL_HOST env var to instruct nginx-proxy to create config file for that domain and because there is already a cert for the virtual host, so it is used automatically? How do you suggest running the app containers again?

3. Can I expose multiple apps on same port, I generally use 8080 while developing locally, so can I expose port 8080 for app1 as well as for app2 in their Dockerfiles, or they have to different?

4. In case I don't wish to terminate SSL at nginx, then I would need to enter path to certs in the app's code. Consider a Golang application using ListenAndServeTLS function. So, how can I point to that path. Generally, to access anything from outside, I create an env var in docker compose file (say for mongo db host uri) and use that env var in my app. But, how can I make this trick work this time as, in the app's docker compose file, I only run one service which is of the application itself and the rest is taken care of by your code.

Now, a question regarding adding subdomain (SAN).

1. I never know beforehand how many subdomains I may need. So suppose I first create a cert for my base domain (example.com) using LETSENCRYPT_HOST: example.com. Then few days later, I wish to use another subdomain, so now in this case how should my LETSENCRYPT_HOST env var look like -
   LETSENCRYPT_HOST: example.com,sub1.example.com? And then again few days later I need another subdomain, so will it be like LETSENCRYPT_HOST: example.com,sub1.example.com,sub2.example.com. That is, we have to keep the history and that too in exact order intact while creating certs for new subdomains?

Also, this is optional but I have seen you to be really helpful on Github. So, I don't know of any automated volume backup/restore system for docker. And I have read the docker docs for doing it manually, but I don't want to. If I had backup of my certs, then I yesterday I would have saved my time because I believe copying the original cert back after generating a test cert would result in showing original cert and not the test cert right? So could you please recommend any good solution, or point me towards a resource to do backups in the right manner?

[buchdag]

What happens to the certificates when I restart, stop-then-start, remove-then-start etc a container (volume not deleted). Do the previous certs are discovered first and used if available, which I most probably think is happening behind the scenes. Or, new cert is created every time?

If the volume is not deleted the certificates will stay there and if the same volume is re-used again the existing certificates will be re-used by the container. To ensure volume reutilisation you should use host or named volumes rather than anonymous volumes. Anonymous volumes are tied to a specific container, so if the container get removed this volume won't get automatically reused (it can but its name will be a random generated id, not super user friendly).

• anonymous volume: -v /etc/nginx/certs
• host volume: -v /path/to/some/local/dir:/etc/nginx/certs
• named volume: -v certs:/etc/nginx/certs

Named volumes (handled by docker and referred to with their name) is IMO the best option, and it seems to avoid issue with data persistence on some specific case (see #273).

When running the container again, is there any need to use the LETSENCRYPT_HOST and other le env vars again. Can I not simply use VIRTUAL_HOST env var to instruct nginx-proxy to create config file for that domain and because there is already a cert for the virtual host, so it is used automatically? How do you suggest running the app containers again?

If you don't set the LETSENCRYPT_HOST variable again, automatic renewal won't work. This env var is how the letsencrypt container keeps track of the domains it has to handle certificates for. But yes even without this variable set, if the certs are still there with the correct names, nginx-proxy will enable SSL for those virtual hosts.

Can I expose multiple apps on same port, I generally use 8080 while developing locally, so can I expose port 8080 for app1 as well as for app2 in their Dockerfiles, or they have to different?

In case I don't wish to terminate SSL at nginx, then I would need to enter path to certs in the app's code. Consider a Golang application using ListenAndServeTLS function. So, how can I point to that path. Generally, to access anything from outside, I create an env var in docker compose file (say for mongo db host uri) and use that env var in my app. But, how can I make this trick work this time as, in the app's docker compose file, I only run one service which is of the application itself and the rest is taken care of by your code.

Both those questions are not relevant to this project but to nginx-proxy, they should be asked there if reading the doc does not answer them.

For the port: yes, you can (as long as you expose it correctly and set VIRTUAL_PORT if the container expose multiple ports).

For the SSL backend: see https://github.com/jwilder/nginx-proxy#ssl-backends

I never know beforehand how many subdomains I may need. So suppose I first create a cert for my base domain (example.com) using LETSENCRYPT_HOST: example.com. Then few days later, I wish to use another subdomain, so now in this case how should my LETSENCRYPT_HOST env var look like -
LETSENCRYPT_HOST: example.com,sub1.example.com? And then again few days later I need another subdomain, so will it be like LETSENCRYPT_HOST: example.com,sub1.example.com,sub2.example.com. That is, we have to keep the history and that too in exact order intact while creating certs for new subdomains?

You should try to keep the first domain the same because it's considered as the base domain by the letsencrypt container and it impacts where the files are created and looked for by simp_le. The order of the alternative names does not really matter.

As told previously, the container does not keep a persistent DB of the domains it handles certificate for, it just derive this at runtime from the LETSENCRYPT_HOST vars of the containers that have it set. So yes you need to keep the whole history set at all time if you want to avoid mistakes, just don't bother with the order of the domains beside the first one.

Note that the rate limit by registered domain is not the same as the rate limit for duplicate certificates. If you add an alternative domain to a SAN certificate, that's not considered a duplicate certificate. You got 20 of those / week vs 5 / week for duplicate certificates.

So, I don't know of any automated volume backup/restore system for docker. And I have read the docker docs for doing it manually, but I don't want to. If I had backup of my certs, then I yesterday I would have saved my time because I believe copying the original cert back after generating a test cert would result in showing original cert and not the test cert right? So could you please recommend any good solution, or point me towards a resource to do backups in the right manner?

You can easily rotate between different named volumes, for instance let say you have test certificates on the named volume certs-test and the non test certificates on the named volume certs, you can then mount either one or the other depending on what you want to do:

• -v certs-test:/etc/nginx/certs and you're working with the test certificates
• -v certs:/etc/nginx/certs and you're working with the non test certificates

Cloning an existing named volume to a new one will have to be done manually from inside a container, there is no command like docker volume clone vol1 vol2 (yet ?).

I'm not aware of an existing automated solution for doing backup/restore of volumes, but I haven't really searched for one. If I happen to need it at some point I'll probably write a small script from the manual steps described in the doc. That's not hard if you know a bit of bash scripting, so there must already be stuff like this on github or stackoverflow or [...]