On Ubuntu, it looks like the best place for a private key used to sign a certificate (for use by nginx) is in /etc/ssl/private/
This answer adds that the certificate should go in /etc/ssl/certs/
but that seems like an unsafe place. Do .crt
files need to be kept safe or are they considered public?
The .crt file is sent to everything that connects; it is public. (
chown root:root
andchmod 644
)To add to the private key location; make sure you secure it properly as well as having it in there. (
chown root:ssl-cert
andchmod 640
)It really doesn't matter where you put them as long as you properly protect your private key file(s). The public certificate is public; no protection needed - server privileges or otherwise.
To expand on the answer, I do not use the default location
/etc/ssl
.It's easier for me to keep all mine in a separate area due to backups+other reasons.
For Apache SSL, I keep mine in
/etc/apache2/ssl/private
or similar "root area" in/etc/apache2
.Example Setup
This post is geared toward Ubuntu (Debian) + Apache, but should work on most systems.
Just apply the permissions and update location/path in given config (apache/nginx/etc).
This answer also assumes you are NOT using LetsEncrypt/Certbot, or some automated SSL service. You have bought, or created a SSL certificate and have obtained the file bundle.
If the SSL key file(s) are protected correctly (directory & files), you will be fine. Note the notes!
Create directories:
Note:
chmod 710
supportsssl-cert
group under Ubuntu. (See comments)Setting permission to
700
on/etc/apache2/ssl/private
will also work fine.Place SSL files:
Put the public SSL certificate(s) AND intermediate certificate(s) in:
/etc/apache2/ssl
(These are*.crt
files, normally)Put the corresponding private SSL key(s) in:
/etc/apache2/ssl/private
(These are*.key
files, or no extension, normally)Note: LetsEncrypt/Certbot uses the ".pem" extension for all SSL files (public, intermediate chains and private). But, you do not need to move (or protect) those files. They are already in place and protected. Just call them directly in your Apache '.conf'.
Set owner:
Note - If you do not have a ssl-cert group, just skip the 2nd line:
Set permissions:
Public Certificate(s)
Private Key(s)
Note:
The group permission for private key(s) is set to READ (640) due to Ubuntu ssl-cert group. Using '600' (owner only control) is the normal permission for private keys and will work fine as well.
Enable the Apache SSL module
Edit any Apache site files and enable
(see last paragraph) *
Restart Apache2 service
or
Done. Test your new SSL site.
* Again this goes beyond the question, but you can copy the default Apache SSL site configuration file (
sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf
) as a good starting point/example of default directives/directories normally used under a simple (Ubuntu/Debian) Apache/SSL 'conf' file. It normally points to a self-signed SSL certificate+key (snakeoil), CA bundles, as well as common directives used for a given SSL site.After copying, just edit the new .conf file and add/remove/update it as needed with new information/paths above then execute
sudo a2ensite mysiteexample-ssl
to enable it. Reload/restart apache2. Test.All the answers here seem OK, but I want to mention one thing I found is a problem... If you have to concatenate your cert with intermediates or roots to come up with a chain file, don't put that in
/etc/ssl/certs
, because whenc_rehash
is run, it may create hash symlinks to your certs due to the roots or intermediates within them.Then later down the road if your certs have expired and you remove them, and don't know to re-run
c_rehash
, you may have broken hash symlinks in your/etc/ssl/certs
directory, and weird things start happening when your local machine tries to connect to itself through SSL, and it can't find the roots to validate against. For example, with curl I suddenly started getting:Shortly after cleaning up some old .crt and concatenated .pem files I had in
/etc/ssl/certs
.Storing at least your chains somewhere else avoids this problem. I ended up making a
/etc/ssl/local_certs
to hold my certs and chains, so they weren't lost in the mess of CA certs you'll find in/etc/ssl/certs
Locations are correct:
/etc/ssl/certs/
for.crt
file/etc/ssl/private
for.key
fileOwner:
root:root
for/etc/ssl/certs
root:ssl-cert
for/etc/ssl/private
Permissions:
644
for.crt
file600
for.key
fileThis will work for
nginx
.There's not really an unsafe place if permission for the individual files/directory is set to something like
chown root :0 private.key
andchmod 600 private.key
so that only root can read it. CSRs and certificate files are less sensitive as you say.With those permissions the paths you mention and /usr/local/ssl should be fine.