privkey1.pem has 644, better is 600


#1

I was successful to enable my beta SSL certificates, what I discovered was
that privkey1.pem had 644,

I know the parent directory will hide the files in it, but for security reason
it is better to have chmod 600 for all private keys. Not shure about that just
looking and exploring around :smile:

BTW my client is letsencrypt-0.0.0.dev.20151114-1 on docker alpine linux


Keyfile is group/world readable (not really but sendmail believes so)
#2

Indeed. LE not taking this into account is quite disturbing. For SSH 644 can even result in a failure.

Also, 400 is even better than 600.

See:


#3

Thank you for pointing that out! The private key I use for my WeeChat relay ended up being world readable thanks to this. It’s being copied along with the chain to /home/$user/.weechat/ssl due to permission and format requirements. While I did chown and chmod the concatenated new file, I didn’t touch the permissions of the original files.

This should definitely be changed as it introduces potential security vulnerabilities.


#4

I’ve mentioned this in another thread, but the permissions LE sets on files really need rethinking.

As it is now, the entire /etc/letsencrypt/live directory is readable only to root, which breaks any attempt to give read access to specific certs for specific users because even if you give a user/group access to /etc/letsencrypt/live/example.com, you still can’t touch it because of the parent directory permissions. This forces you to give far too broad read access to /etc/letsencrypt/live if you want to use your certs with non-root software which defeats the entire concept of trying to secure your certs via principle of least privilege.


#5

Hi giminni.

Although the private key has permissions set to 644, the directory it’s in should have permissions set to 700 by default, so it isn’t actually world-readable in practice. If that’s not the case, please provide details in this github issue:


#6

That’s already stated in the OP. But if you move the file, the permissions are wrong. Nevertheless, permissions should be 600 instead of 644 even if the parent directory is set correctly.


#7

Agree that we should change those permissions. I’ve bumped it ahead on our roadmap, but feel free to send us a PR for #1473 if you want it to happen quickly :slight_smile:

Aside to OP: it’s also much, much better to symlink to these files rather than copying them out of /etc/letsencrypt, and it’s actually bad to move them out of /etc/letsencrypt, because the autorenewal code we’re working on may use the past keys and certs in that directory to understand what successor certs you’ll need at renewal time.


Feedback and problems: My experience with LE
#8

Alright so I’ve written a small script to change the LE permissions to something more sensible using inotify to watch for cert changes. You should probably run it as a daemon somehow (screen/tmux).

Disclaimer: Use at your own risk. I give no guarantees this won’t melt your CPU, kill your dog, or delete your entire filesystem, nor will I accept any responsibility for any problems caused by the use of this script. You are expected to be able to read and understand bash scripts yourself to determine if this script could break anything on your system, and be able to fix any problems related to it’s use.

https://pste.pw/v/gkRKWjaIGbL5

By default, files are protected from anyone but root (as normal), but this setup allows you to change group ownership of /etc/letsencrypt/archive/domain.com to grant read access for a single domain (instead of the entire cert folder) to a particular group.

In other words, your permissions should look something like this.


#9

It’s also a problem with sendmail.
Complaining about a world readable privkey.