0

I have to configure a number of webservers to use HTTPS, I wouldn't consider any 'high security', but I want to cover at least basic security best practices.

I'm wondering where I should store the private key the webserver needs to support HTTPS, and how I should handle access of it? From what I read making the private key passwordless and depending on file permissions is standard for a web server that doesn't need high security. However, the most likely compromise angle for any web server is an exploit in the server itself, resulting in anyone who has gotten access to the box already having read access on my key. Is there any easy way to minimize this threat?

I'm also not sure where to keep the key in regardes to centos conventions. It looks like /etc/pki is where I should put my keys, but I'm not sure where within that directory private/public keys are usually stored, I don't understand it's directory layout. I had read about private keys being stored in /etc/pki/private but that directly doesn't exist by default which makes me wonder if convention is to create the directory or store the key elsewhere. More importantly what I read also said that /etc/pki/private should only be readable by root, but my web server won't be running as root so either I need to store the private key somewhere else or open up access to /etc/pki/private to my web server as well.

Improve this question
6
  • What is this key for? If it's for connecting to the server, it shouldn't be on the server at all - the private key would be on your computer, and only the public key would be on the server.
    – ceejayoz
    May 26, 2017 at 17:48
  • @ceejayoz for the https, the web server needs to authenticate itself by signing a response that matches the public key of the CA
    – dsollen
    May 26, 2017 at 17:50
  • OK, so this is for a webserver's SSL. It should be somewhere only root can access, as your webserver will be root when accessing it. A normal compromise of the server via something like a hacked PHP script won't compromise it in that situation (and you've got bigger concerns than SSL in a compromise, anyways). File path doesn't really matter - I typically make a keys directory in the Apache config dir.
    – ceejayoz
    May 26, 2017 at 17:53
  • 1
    The nginx workers run as the nginx user, but the service (master process) typically runs as root. It can't bind to port 80 otherwise. ps aux | grep nginx and you'll likely see this.
    – ceejayoz
    May 26, 2017 at 18:11
  • 1
    @ceejayoz yeah, I kind of thought you were going to say that. I did know that it was started as root, but I hadn't known that the logic for reading the PKI was also run at root level, but after your first comment caused me to think about it that seemed by far a better approach then what I assumed. if you want to officially answer the question I'll accept the answer so you get credit
    – dsollen
    May 26, 2017 at 18:15

2 Answers 2

Reset to default
4

The master process for your webserver typically runs as root, including for reading SSL private keys, so putting it somewhere only root can read should suffice. If your server's compromised you're going to be re-keying your SSL certs anyways and you've got bigger problems than MITMing.

Location doesn't matter at all (as long as the aforementioned permissions are in place), so put it wherever makes sense to you. Probably not /tmp, but my personal preference is a folder called keys or ssl in the webserver's config directory in /etc.

Improve this answer
2
  • 2
    lol. I want to laugh at the probably not /tmp part, but I've actually had a programmer under me do that and act confused when his code disappeared one day
    – dsollen
    May 26, 2017 at 18:19
  • 3
    @dsollen Yowch! Also, hahahaha.
    – ceejayoz
    May 26, 2017 at 18:20
5

On modern versions of CentOS, the normal directory for private keys would be /etc/pki/tls/private/, which should not have any permissions for anyone other than root. The corresponding public keys should be stored in /etc/pki/tls/certs.

Enabling SELinux, or AppArmor or some other MAC (Mandatory Access Control), if you prefer that, should help prevent any web exploit from accessing your private key.

Of course, there's nothing stopping you from storing them elsewhere, but you would then need to set the MAC ACLs manually if you are using one.

Improve this answer

You must log in to answer this question.

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