@jsha noticed that the client currently wants some directories to have mode 755 and this is mandatory. I'm not sure that's the right policy.

Results of a partial audit, observing the results of running LE rather than reading all relevant code:

Everything under /etc/letsencrypt/ is 700, except for renewal/, csr/, and options-ssl-apache.conf. I actually don't understand how webservers that run as something other than root can get things from live/ and keys/ right now.

Everything under /var/log/letsencrypt is locked down.

There are world-readable backups of some things in /var/lib/letsencrypt/backups, but they appear to be config files and not keys. Since apache does not contain inline private keys or basic auth credentials, those should not be leaked by those permissions. However /var/lib/letsencrypt/backups should be less widely readable if possible.

Opened #1396

I think that's sufficient confidence to kick further work on this down the road for now.

So, how to make it possible for a Rails server run as a normal user to access the keys on /live directory?

@acrolink: Could you post your question at https://community.letsencrypt.org/? This issue is about a different question. Thanks!

I did an audit of the files in all the 700 directories in config-dir (usually /etc/letsencrypt/), where their permissions are set/enforced/created (it's not comprehensive-- permissions could also be set elsewhere, but this is intended as a starting point). Links are to lines in commit 92645619.

• accounts/<endpoint>/directory/<hash>/ all 700, enforced

  • meta.json default (644)
  • private_key.json 400
  • regr.json default (644)

• archive/ and live/ 700

  • <lineage>/ default (755)
    • fullchain.pem default (644)
    • cert.pem default (644)
    • chain.pem default (644)
    • privkey.pem default (644)

• keys/ 700, enforced

  • ####_key-certbot.pem 600

"enforced" means the permissions are verified with util.make_or_verify_dir. "default" means that the permissions are not explicitly set upon file/directory creation; in parentheses is what these files end up being when created.

As I mentioned in #1473, the biggest problem is that the permissions on archive/live are not verified or ensured to be 700, so making that directory more permissive in future versions of Certbot means that downgrading Certbot and renewing would expose private key material, since the new private keys would be created under 644.

This is my server directory, totally managed by cerbot, I never changed any permission:

 # ls -l /etc/letsencrypt/archive/dns.0latency.com/
total 48
-rw-r--r-- 1 root root 2159 Aug 17 21:46 cert1.pem
-rw-r--r-- 1 root root 2155 Oct 28 21:48 cert2.pem
-rw-r--r-- 1 root root 1911 Jan 11 15:46 cert3.pem
-rw-r--r-- 1 root root 1647 Aug 17 21:46 chain1.pem
-rw-r--r-- 1 root root 1647 Oct 28 21:48 chain2.pem
-rw-r--r-- 1 root root 1647 Jan 11 15:46 chain3.pem
-rw-r--r-- 1 root root 3806 Aug 17 21:46 fullchain1.pem
-rw-r--r-- 1 root root 3802 Oct 28 21:48 fullchain2.pem
-rw-r--r-- 1 root root 3558 Jan 11 15:46 fullchain3.pem
-rw-r--r-- 1 root root 1704 Aug 17 21:46 privkey1.pem
-rw-r--r-- 1 root root 1704 Oct 28 21:48 privkey2.pem
-rw-r--r-- 1 root root 1704 Jan 11 15:46 privkey3.pem

I think it's way too permissing, expecially for the Private key.
I am running certbot version: 0.10.2, on Debian with default umask of 0022.

Hi @maurorappa! We fixed this in #6480, which should be in the most recent release of Certbot v0.29.1. Regardless, your private key should still be safe as long as the permissions on the containing directories have remained the same (non group or world readable) as when Certbot created them.

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.

It seems that we finished the audit, so closing.

If we want to do a file directory structure rehaul in the future, that should go in a new issue.