Permission denied: Unable to load certificate file

[ohammami]

Hi,

This is a small issue with the certbot rpm postscript script in the directories creation /etc/letsencrypt/.

Directories archiveand live should be read accessible for any user so any daemon can use let's encrypt certificate.

thanks again for this awesome solution !

My operating system is (include version):

CentOS Linux release 7.4.1708 (Core)

I installed Certbot with yum from epel repo:

[root@web-proxy-001 ~]# rpm -qa|grep certbot
python2-certbot-0.19.0-1.el7.noarch
certbot-0.19.0-1.el7.noarch

I ran this command and it produced this output:

I use the certificates symbolic link /etc/letsencrypt/live/MyDomain.com/fullchain.pem and /etc/letsencrypt/live/MyDomain.com/privkey.pem from my server but I've got this error:

load_cert(): TLSs<default>: Unable to load certificate file ...

Certbot's behavior differed from what I expected because:

Directory Permission on /etc/letsencrypt/live/and /etc/letsencrypt/archive/

 # ll -d /etc/letsencrypt/live/
drwx------. 3 root root 38 Sep 28 11:24 /etc/letsencrypt/live/

# ll -d /etc/letsencrypt/archive/
drwx------. 3 root root 38 Sep 28 11:24 /etc/letsencrypt/archive/

To fix this error:

# chmod 755 /etc/letsencrypt/live/
# chmod 755 /etc/letsencrypt/archive/
# ll /etc/letsencrypt/
total 0
drwxr-xr-x. 3 root root 38 Sep 28 11:24 archive
drwxr-xr-x. 3 root root 38 Sep 28 11:24 live
...

[Noah Swartz]

Can you share the first certbot log you have, or the command that you ran to generate certificates initially?

[ohammami]

• Initial command
  # certbot certonly --standalone -d MyDomain.com

• Certbot Log

/Ouss

[Noah Swartz]

So by default the directories should be owned by the user who ran certbot, if you ran certbot as sudo then those directories should be owned by root.
Additionally, since your private key is put into that directory, we don't want to default to it being world readable.
Your chmod solution should work, but please let me know if it reset the permissions after a renewal, as that would be bad.
Does that make sense?

[ohammami]

yes, thanks 👍
the renewal didn't reset permissions.

[Noah Swartz]

Awesome, I'm going to close this as resolved, let me know if you run into more issues.
If we receive more reports of this I'm happy to work on some sort of fix or change that addresses this issue, but for now it seems rare enough not to be a concern.

[Elad Nava]

Cheers @oussamahammami for the fix. It works like magic and allows non-root apps on the server to read the certificate and key files. 💯

[Daniel Borges]

Are there any plans of putting the private key in a different folder so that fullchain.pem can be set to readable by everyone?
EDIT: Well, actually, the private key is already set to be readable only by its owner so I don't understand why the directory is not rx for everyone

[facciolo]

I would add the recursivity:
chmod -R 755 /etc/letsencrypt/live/
chmod -R 755 /etc/letsencrypt/archive/

thanks @oussamahammami

[Git'Fellow]

Running into the same issue here (Ubuntu), thanks for the "fix".

[Ashesh Ambasta]

We're seeing this issue but in a different scenario. Certbot keeps resetting the permission on every new domain it requests the certificates for, and stores them. Since we're using LE to keep track of 100s of domains; this isn't quite the solution that works for us: a new domain receives a cert.; certbot stores them with the incorrect permissions and someone has to manually intervene every time to correct the permissions.

Is there a more permanent fix for this?

[/:)]

Hey, you can use --post-hook on the certbot:

certbot renew ...  --post-hook "chmod -R 755 /etc/letsencrypt/live/ /etc/letsencrypt/archive/"

• https://certbot.eff.org/docs/using.html?highlight=hook

FYI @asheshambasta

[Ashesh Ambasta]

@m0zgen thanks for the pointer; however, we've since rolled our own LE client that is built into an HTTP server. It was turning out for us that Certbot is possibly not the best solution if you're looking to SSL 1000's of domains (as in our use case).