5

I'm attempting to set up a standalone secure certificate using CertBot and create a symbolic link (./public/certbot) from my server so that I can include the certificates without them actually being under the directory tree of the server (this is a Linode I use for testing and development, so I'm going to be using a variety of server software). The certificates have installed successfully under /etc/letsencrypt/, and as instructed in the CertBot documentation, installation was done using sudo, so all the files are owned by root. I have tried everything I could think of to create a symlink that the server can read, but I keep getting a permission error. Currently, the symlink file, /etc/letsencrypt/live, the domain folder, and all files inside the domain folder have been sudo chmodded to 777, and I tried creating the symlink file without sudo, but it didn't let me. As a normal user, I am able to cd into the symlink file and ls the domain folder without sudo, so I can see everything in there, but when I start my server (currently webpack-dev-server), it doesn't have permission. The error message from the server indicates that the path is being resolved correctly (since it's giving me an access error, not ENOENT).

I've also tried creating a real public/certbot folder and individual symlinks to the certificate files, with the same errors.

There must be some gap in my knowledge about Linux permissions. Is there a way around this? Thanks.

1 Answer 1

3

so that I can include the certificates without them actually being under the directory tree of the server

Most software do not have this requirement in the first place, and can access certificates directly from `/etc/letsencrypt/live just fine.

Whether your current problem is caused by file permissions or chrooting, this symlink won't help with it at all. If you have enough permissions to follow a symlink to /etc​/letsencrypt​/live​/foo​/privkey.pem, then you also have enough permissions to access the same file directly.

Currently, the symlink file, …

Permissions of "symlink files" are irrelevant and you cannot change them on Linux. They're always reported as "lrwxrwxrwx", but it's only the target file itself that matters, not the symlink to it.

… /etc/letsencrypt/live, the domain folder, and all files inside the domain folder, …

Look at those files under /etc/letsencrypt/live; notice that they themselves are symlinks to yet another directory, archive. That directory is also not world-readable by default.

Use namei -l ./public/certbot/example.com/privkey.pem to quickly see every component in the path (including symlink resolution) and its permissions.

… have been sudo chmodded to 777.

Do not try to "solve" permission problems with a sledgehammer. Giving everyone write permissions to those folders was completely unnecessary.

1
  • Upvoted for calling out "chmod 777".
    – Richlv
    Commented Dec 26, 2022 at 14:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .