Melhor local para manter certificados SSL e chaves privadas em servidores Ubuntu?

O arquivo .crt é enviado para tudo que se conecta; é público. ( chown root:roote chmod 644)

Para adicionar ao local da chave privada; certifique-se de prendê-lo corretamente, bem como tê-lo lá. ( chown root:ssl-certe chmod 640)

Realmente não importa onde você os coloque, desde que proteja adequadamente seu (s) arquivo(s) de chave privada . O certificado público é público; nenhuma proteção necessária - privilégios de servidor ou outros.

Para expandir a resposta, não uso o local padrão /etc/ssl.
É mais fácil para mim manter todos os meus em uma área separada devido a backups + outros motivos.

Para o Apache SSL, mantenho o meu na /etc/apache2/ssl/private"área raiz" ou similar em /etc/apache2.

Exemplo de configuração

Este post é voltado para Ubuntu (Debian) + Apache, mas deve funcionar na maioria dos sistemas.
Basta aplicar as permissões e atualizar o local/caminho na configuração fornecida (apache/nginx/etc).

Esta resposta também pressupõe que você NÃO está usando LetsEncrypt/Certbot ou algum serviço SSL automatizado. Você comprou ou criou um certificado SSL e obteve o pacote de arquivos.

Se os arquivos de chave SSL estiverem protegidos corretamente (diretório e arquivos), você ficará bem. Observe as notas!

Crie diretórios:

sudo mkdir /etc/apache2/ssl
sudo mkdir /etc/apache2/ssl/private
sudo chmod 755 /etc/apache2/ssl
sudo chmod 710 /etc/apache2/ssl/private

Nota:
chmod 710suporta ssl-certgrupo no Ubuntu. (Veja comentários)
Definir permissão para 700ligado /etc/apache2/ssl/privatetambém funcionará bem.

Coloque arquivos SSL:

Coloque o (s) certificado(s) SSL público E o(s) certificado(s) intermediário(s) em:
/etc/apache2/ssl(Estes são *.crtarquivos, normalmente)

Coloque a (s) chave(s) SSL privada
/etc/apache2/ssl/private (s) correspondente(s) em: (Estes são *.keyarquivos, ou sem extensão, normalmente)

Nota: LetsEncrypt/Certbot usa a extensão ".pem" para todos os arquivos SSL (públicos, intermediários e privados). Mas você não precisa mover (ou proteger) esses arquivos. Eles já estão no lugar e protegidos. Basta chamá-los diretamente no seu Apache '.conf'.

Proprietário do conjunto:

Nota - Se você não tiver um grupo ssl-cert , pule a 2ª linha:

sudo chown -R root:root /etc/apache2/ssl/
sudo chown -R root:ssl-cert /etc/apache2/ssl/private/

Definir permissões:

Certificado(s) Público(s)

sudo chmod 644 /etc/apache2/ssl/*.crt

Chave(s) privada(s)

sudo chmod 640 /etc/apache2/ssl/private/*.key

Nota:
A permissão de grupo para chave(s) privada(s) está definida como READ (640) devido ao grupo ssl-cert do Ubuntu. Usar '600' (controle somente do proprietário) é a permissão normal para chaves privadas e também funcionará bem.

Habilite o módulo Apache SSL

sudo a2enmod ssl

Edite qualquer arquivo do site Apache e habilite

(ver último parágrafo) *

sudo nano /etc/apache/sites-available/mysiteexample-ssl.conf
sudo a2ensite mysiteexample-ssl
#             ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)

Reinicie o serviço Apache2

sudo service apache2 restart

ou

sudo systemctl restart apache2.service

Feito. Teste seu novo site SSL.

* Novamente, isso vai além da questão, mas você pode copiar o arquivo de configuração padrão do site Apache SSL ( sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf) como um bom ponto de partida/exemplo de diretivas/diretórios padrão normalmente usados ​​em um arquivo 'conf' Apache/SSL simples (Ubuntu/Debian) . Ele normalmente aponta para um certificado SSL autoassinado + chave (snakeoil), pacotes CA, bem como diretivas comuns usadas para um determinado site SSL.

Após copiar, apenas edite o novo arquivo .conf e adicione/remova/atualize conforme necessário com as novas informações/caminhos acima e execute sudo a2ensite mysiteexample-sslpara habilitá-lo. Recarregue/reinicie o apache2. Teste.

Todas as respostas aqui parecem boas, mas quero mencionar uma coisa que encontrei é um problema... Se você tiver que concatenar seu certificado com intermediários ou raízes para obter um arquivo de cadeia, não coloque isso /etc/ssl/certsem c_rehashé executado, ele pode criar links simbólicos de hash para seus certificados devido às raízes ou intermediários dentro deles.

Então, mais tarde, se seus certificados expiraram e você os remove, e não sabe como executar novamente c_rehash, você pode ter quebrado os links simbólicos de hash em seu /etc/ssl/certsdiretório e coisas estranhas começam a acontecer quando sua máquina local tenta se conectar a si mesma através SSL e não consegue encontrar as raízes para validar. Por exemplo, com curl, de repente comecei a receber:

curl: (60) SSL certificate problem: unable to get issuer certificate

Pouco depois de limpar alguns arquivos .crt antigos e .pem concatenados que eu tinha em /etc/ssl/certs.

Armazenar pelo menos suas correntes em outro lugar evita esse problema. Acabei fazendo um /etc/ssl/local_certspara guardar meus certificados e correntes, para que eles não se perdessem na bagunça de certificados da CA que você encontrará em/etc/ssl/certs

Os locais estão corretos:

• /etc/ssl/certs/para .crtarquivo
• /etc/ssl/privatepara .keyarquivo

Proprietário :

• root:rootpor/etc/ssl/certs
• root:ssl-certpor/etc/ssl/private

Permissões :

• 644para .crtarquivo
• 600para .keyarquivo

Isso funcionará para nginx.

Não há realmente um lugar inseguro se a permissão para os arquivos/diretórios individuais estiver definida para algo como chown root :0 private.keye chmod 600 private.keypara que apenas o root possa lê-lo. CSRs e arquivos de certificado são menos sensíveis como você diz.

Com essas permissões, os caminhos que você menciona e /usr/local/ssl devem estar bem.