Melhor localização para certificado SSL e chaves privadas no Ubuntu

No Ubuntu, parece que o melhor lugar para uma chave privada usada para assinar um certificado (para uso pelo nginx) é /etc/ssl/private/

Esta resposta acrescenta que o certificado deve entrar, /etc/ssl/certs/mas parece um local inseguro. Os .crtarquivos precisam ser mantidos em segurança ou são considerados públicos?

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

Para adicionar ao local da chave privada; assegure-se de protegê-lo adequadamente e de tê-lo lá. ( chown root:ssl-certe chmod 640)

Realmente não importa onde você os coloca, desde que proteja adequadamente seus arquivos 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 manter todo o meu em uma área separada devido a backups e outros motivos.

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

Exemplo de configuração

Esta publicação é voltada para o 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).
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. (Ver comentários)
permissão Definir a 700na /etc/apache2/ssl/privatetambém irá funcionar bem.

Coloque arquivos SSL:

Coloque certificados públicos www ssl junto com certificados intermediários em /etc/apache2/ssl
Coloque chaves privadas SSL/etc/apache2/ssl/private

Proprietário do conjunto:

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

Nota:
Se você não possui um grupo ssl-cert , use 'root: root' na linha acima ou pule a segunda linha.

Defina permissões:

Certificados públicos

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

Chave (s) privada (s)

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

Nota:
A permissão do grupo está definida como READ (640) devido ao grupo ssl-cert do Ubuntu. '600' também é bom.

Ativar o módulo SSL do Apache

sudo a2enmod ssl

Edite todos os arquivos do site Apache e ative

(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 do site SSL Apache padrão ( 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' simples (Ubuntu / Debian) Apache / SSL . Normalmente, ele aponta para um certificado SSL autoassinado + chave (snakeoil), pacotes CA, bem como diretrizes comuns usadas para um determinado site SSL.

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

Todas as respostas aqui parecem boas, mas quero mencionar uma coisa que achei ser um problema ... Se você precisar concatenar seu certificado com intermediários ou raízes para criar um arquivo em cadeia, não o coloque /etc/ssl/certs, porque quando c_rehashfor executado, ele pode criar links simbólicos de hash para seus certificados devido às raízes ou intermediários neles.

Depois, mais tarde, se seus certificados expiraram e você os remove, e não sabe executar novamente c_rehash, você pode ter quebrado 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 o curl, de repente comecei a receber:

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

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

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

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

Com essas permissões, os caminhos mencionados e / usr / local / ssl devem estar bem.

Os locais estão corretos:

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

O proprietário deve ser root:rootpara ambos (use sudo chmod root:root <file>para alterar, se necessário).

Permissões :

• 644para .crtarquivo
• 600para .keyarquivo

Isso irá funcionar nginx.