Debian: Make live directory readable by ssl-cert group

[cweiske]

On Debian, programs that run as non-root have the group ssl-cert, for example ejabberd.

The /etc/letsencrypt/live is only readable by root and nobody else. This directory should be readable and executable by the ssl-cert group.

[pastukhov]

Same for me.
I have node-red installation that running from dedicated user.

[NEOatNHNG]

+1 But you also have to make archive readable for the ssl-cert group as the live directory only contains symlinks

[shr3k]

👍

[clawoflight]

Please add this!

[KevinBrogan]

Unless you're not on ubuntu or debian and there is no ssl-cert group.

If you have root access, set the group manually yourself. Coding in a dependency to a specific distribution's idiosyncrasies is a terrible idea.

[boltronics]

It only needs to check if the group exists, and if so use that instead, and then document this behaviour. I don't think it needs to be coded to be distribution-specific, and it would make for a small usability improvement that has caught out a number of people.

[tgies]

There already is distro-specific behavior for every major class of distro, out of necessity, so that might be a moot point. In any case I'd argue that it's not a "terrible idea" to comport to a general quality of life measure in one of the 2 general classes of distribution that everyone uses, especially if the project is going to recommend that people use the upstream version and not a distribution package (which would presumably be tweaked to comply with this ssl-cert group scheme).

[VA1DER]

Coding in a dependency to a specific distribution's idiosyncrasies is a terrible idea.

Making it run smoothly on the distribution family that accounts for almost 73% of known Linux servers is not catering to a distribution's idiosyncrasies. It is addressing the needs of your major user base.

especially if the project is going to recommend that people use the upstream version

Wholeheartedly agree. The moment you suggest users not use a distribution-supplied package, you are essentially taking responsibility for working correctly on each distribution.

[stale]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[adferrand]

In the scope of us recommending to use the upstream version through the snap packaging, I think this issue still need to be studied to see if we can improve things. @bmw what do you think?

[bmw]

Sure, but especially since neither us or Debian/Ubuntu has done anything about this in any Certbot distribution method for the last 4.5 years, I'll add that I honestly doubt the small Certbot team will have the resources to prioritize this ourselves anytime soon.

In the meantime, if you modify the directories and private key with the permissions you want, Certbot should preserve them.

[stale]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[boltronics]

On one of my systems I have:
drwx------ 4 root root 4096 May 4 09:51 live
so unless something changed in the last couple of months, this still seems to be an issue.

[stokito]

I think this is an important issue because now users have to use self made deploy hooks and use some random tutorials from internet.
Also related forum topics have many answers that differs: 1,2,3,

It's a big probability to mess and expose system.

From what I read it looks like LE must use the following approach.
First of all the all private keys should definitely belong to the ssl-cert group. The user may remain the root.
Any daemon that needs for the keys should join the ssl-cert group e.g.:

$ sudo usermod -a -G ssl-cert ejabberd
$ id -a postgres
uid=105(postgres) gid=108(postgres) groups=105(ssl-cert),108(postgres)

This can be done via post install hook.
The root user is still have access to all keys so the change is backward compatible.

But still remains a big problem that users should configure the path to a cert themselves.
This is something that is difficult to automize. Not all users can do this. On the package upgrade the conf file may be overwritten.
It looks like we may solve the problem too.

The Debian has ssl-cert package with a /usr/sbin/make-ssl-cert wrapper for openssl req to simplify a self signed cert generation.
It's used in post-install to generate a default /etc/ssl/private/ssl-cert-snakeoil.key and /etc/ssl/certs/ssl-cert-snakeoil.pem that will use the computer hostname as domain (commonName).
This key and cert may be used by default so at least the server (like httpd) won't fail on start.
But users will see browser's notice that cert is not signed by CA and not trusted. Still this is better than nothing.

To be compliant with existing Debian approach the LE privkey should be also stored into /etc/ssl/private folder. The files in the folder are accessible for the ssl-cert group.
But remains a question the public cert location. As you saw above the ssl-cert-snakeoil.pem was put into /etc/ssl/certs/.
But the folder is used to store CA certs and this may cause unexpected bugs.
For the ssl-cert package there is an open bug with discussion of the pub cert location https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790943
Please read it and all mentioned links.

I think that instead of separate privkey and fullchain files the LE should generate a single file as discussed in #5087.
And the file may be located in the /etc/ssl/private with a name the same as a domain name.
Then a daemon can make a lookup of the file automatically. Or load all the certs on start into RAM and lookup by a commonName.
I.e. users won't need to configure anything: just run certbot and your daemon will find the needed cert itself.

It remains few things to consider.

Keys location

The /etc/ssl/private is only Debian specific but RedHat uses /etc/pki/tls/private. But I don't know if there is the ssl-cert group.
It looks like FreeBSD also uses the /etc/ssl/ folder. I don't know about MacOS.
Windows stores certs to %APPDATA%\Microsoft\SystemCertificates\.

Daemon specific certs

If the same cert is used by many daemons then if one of them was hacked and private key leaked then all others are compromised too.
In the page https://wiki.debian.org/X.509 there was a proposition to have a daemon specific keys like /etc/x509/keys/example.com_imapd.key.
I think that if anyone wants to use separate certs they can rename them so the domain won't match with a file name and configure manually a path.
At least for beginning that should be fine.

Certs management

In the https://wiki.debian.org/SslCertificateHandling was proposed a tool that simplifies certs configuration. Maybe some ideas may be useful to consider.

Archive

The certs archive may remain the current /etc/letsencrypt/ folder but the certs in /etc/ssl/private may be symlinks.

Alternative ACME clients

The acme.sh, dehydrated and others like Caddy may store the certs in the same location.
This will simplify daemon tutorials and install instructions and users may easily change the ACME clients.

Additional links

• https://dailystuff.nl/blog/2015/installing-ssl-certificates-on-debian
• https://www.getpagespeed.com/server-setup/ssl-directory
• https://ubuntu.com/server/docs/security-certificates

[github-actions]

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

[github-actions]

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.