ssl_certificate_key name must be privkey.pem and nothing else. about docker-nginx-certbot

[JonasAlfredsson]

I do not want to sound rude, but the first line in the readme is "Automatically create and renew website SSL certificates...", and the renewal interval is explained in its own section in "good to know", with a link to an issue discussing on how often you should renew. That the lifetime of Let's Encrypt certificates are only 90 days are explained in their FAQ, with link explaining their reasoning for this short lifetime.

There is also an explanation on how you should create your config files over here, so a really quick fix for you would perhaps be to just change the file paths in your current config files to match what is inside the example, and just restart this image. Since there is nothing unique about your current certificates this should only cause you a couple of seconds of downtime before the new certs are created and verified, and then this image's automatic renewal script will keep them updated automatically without having to struggle against how certbot expects things to look.

[monarchwadia]

Created PR for the issue.

[JonasAlfredsson]

Hi monarchwadia,

I have not run into this issue before, so would you mind answering some questions so I can better understand why this is happening and what your usecase is? :)

That command you linked to is based on information from the README of cerbot's "live" folder:

$ cat /etc/letsencrypt/live/README 

This directory contains your keys and certificates.

`[cert name]/privkey.pem`  : the private key for your certificate.
`[cert name]/fullchain.pem`: the certificate file used in most server software.
`[cert name]/chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`[cert name]/cert.pem`     : will break many server configurations, and should not be used
                             without reading further documentation (see link below).

WARNING: DO NOT MOVE OR RENAME THESE FILES!
         Certbot expects these files to remain in this location in order
         to function properly!

We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

In this container we can only update "normal" Let's Encrypt certificates, and this is a way of filtering out so that we only make requests to certificates that are managed by certbot.

So I am a little bit curious to how you changed them, and why.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JonasAlfredsson]

The proposed change goes against what the documentation of certbot states, so I will not look further into this.

[monarchwadia]

Hi @JonasAlfredsson ! Sorry, I don't check my github notifications regularly. Cool, I see it from your perspective.

From my perspective, I only used this docker image because I'm not a certbot expert. I created the certs myself and named them how I saw fit, then inserted them where I thought they were supposed to be found.

I guess one way to look at it is user-friendliness. Your docker image is a wrapper around Certbot, so it can (and in my opinion should) do things differently. This change only expands on top of what Certbot expects, while not breaking the spec.

[JonasAlfredsson]

No worries :)

I don't know how it works if you create the certificates yourself, because certbot both creates and manages certificate renewal by itself. The certificates it manages will be automatically placed according to the layout it expects, and those certs it doesn't manage should be placed in a completely directory which is not /etc/letsencrypt/ in my opinion. So a suggestion could be to either rename the certificates to match what certbot expects, or use symlinks perhaps if you really need this specific name.

However, I am interested in why you have created your own certificates. Are they special in some way that the current creation process does not support?

[monarchwadia]

No, in hindsight there was nothing special about creating my own. The thing is, there was no easy tutorial or how-to, and so I assumed that I would have to create my own.

I wonder how many people are in the same boat as me. I had to find out the very hard way (my certs expired in production, and I only found out when that happened... and that was only 60 days after I thought I had finished the work!)

[monarchwadia]

Thanks for the info, I'm grateful that you took out time to offer that help to me. I've already fixed this, but I certainly appreciate you pointing out these links.

The documentation on this package has a few places where a user could get confused when setting up the package. For example, no explanation is given for exactly why the certs need to be in a volume.

The reason I decided to use this docker image (or its predecessor) was because I am a newbie and don't want to fiddle around with cert renewals, and I think that's a valid use case. If this could happen to me, then perhaps it's statistically possible that it will happen to someone else. Or maybe this was a one-off case, I don't know.

But either way, I wanted to give you the feedback that developers with less domain knowledge in this area could fall through certain holes in the onboarding workflow offered by the docs right now.

Grateful for the work you've done on the package, it has been working very smoothly on our end. Much gratitude 🙏

[JonasAlfredsson]

No worries at all, I am really glad I can help and want as many people as possible to have HTTPS on their sites :)

And I also do appreciate any and all feedback, if there is something very unclear then I have done something wrong and we should address it as soon as possible. This is where people like you come in and help me understand what I need to change :) However, some parts I think is out of scope of my repository, and that information needs to be searched for by users themselves on external sites otherwise I would sooner or later end up having to include detailed documentation about how the Linux kernel handles network packages ;)

For example: I would assume that a user who knows that HTTPS is required for a more secure connection to their site know why port 80 and 443 needs to be forwarded for this to work, so i don't have to elaborate on it. Also when they find that Let's Encrypt offers free certificates I expect them to read that these certificates expire after 90 days. This would then be the reason for why the user want to automate the process of renewing the certificates, so after a search along the lines of "docker nginx lets encrypt automatic renewal" they would find my repository. If I then don't explicitly write that you should create certificates before starting the container, I don't expect you to do that :P

Also, there exist three different types of Docker volume mounts that should be researched by the user to see which one best suits their usecase. The volume itself is necessary so we do not have to get new certificates and dhparam files every time the container is restarted, since Docker containers are otherwise designed to be stateless. Since this is mentioned in the "getting started" section of Docker docs I assumed that this was known before someone tried to use this (comparatively) advanced image.

Again, I am more than happy to help individual users with their problems, but including links and documentation for every edge case would make my README too cluttered and unreadable :)