No Ubuntu, parece que o melhor lugar para uma chave privada usada para assinar um certificado (para uso do nginx) é em /etc/ssl/private/
Esta resposta adiciona que o certificado deve ir em /etc/ssl/certs/ , mas isso parece um lugar inseguro. Os arquivos .crt precisam ser mantidos em segurança ou são considerados públicos?
Realmente não importa onde você os coloca, desde que você proteja adequadamente seus arquivos de chave privada . O certificado público é público; nenhuma proteção necessária - privilégios de servidor ou de outra forma.
Para expandir a resposta, eu não uso o local padrão /etc/ssl .
É mais fácil manter todos os meus em uma área separada devido a backups + outras razões.
Para o Apache SSL, mantenho o meu em /etc/apache2/ssl/private ou "área de raiz" semelhante em /etc/ .
Este post é voltado para o Ubuntu (Debian) + Apache, mas deve funcionar na maioria dos sistemas -
Apenas aplique as permissões e atualize o local / caminho em determinada configuração (apache / nginx / etc).
Se os arquivos da chave SSL estiverem protegidos corretamente (diretório & arquivos), você estará bem. Anote as notas!
sudo mkdir /etc/apache2/ssl
sudo mkdir /etc/apache2/ssl/private
sudo chmod 755 /etc/apache2/ssl
sudo chmod 710 /etc/apache2/ssl/private
Observação: chmod 710 suporta ssl-cert group no Ubuntu. (Ver comentários)
Definir permissão para 700 on /etc/apache2/ssl/private também funcionará bem .
sudo chown -R root:root /etc/apache2/ssl/
sudo chown -R root:ssl-cert /etc/apache2/ssl/private/
Nota:
Se você não tiver o grupo ssl-cert , use apenas 'root: root' na linha acima ou pule a segunda linha.
Put public www ssl certificate(s) along with intermediate certificate(s) in
/etc/apache2/ssl
Put private ssl key(s) in/etc/apache2/ssl/private
Certificado (s) Público (s)
sudo chmod 644 /etc/apache2/ssl/*.crt
chave privada (s)
sudo chmod 640 /etc/apache2/ssl/private/*.key
Observação:
A permissão do grupo está definida como READ (640) devido ao grupo do ssl-cert do Ubuntu. '600' também está bem.
sudo a2enmod ssl
(ver último parágrafo) *
sudo nano /etc/apache/sites-available/mysiteexample-ssl.conf
sudo a2ensite mysiteexample-ssl
# ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)
sudo service apache2 restart
ou
sudo systemctl restart apache2.service
* Novamente, isso vai além da pergunta, 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 Apache simples (Ubuntu / Debian) / SSL 'conf'. Normalmente, ele aponta para um certificado SSL auto-assinado + chave (snakeoil), pacotes da CA, bem como diretivas comuns usado para um determinado site SSL.
Após a cópia, edite o novo arquivo .conf e adicione / remova / atualize conforme necessário com novas informações / caminhos acima e execute sudo a2ensite mysiteexample-ssl para ativá-lo.
Todas as respostas aqui parecem OK, mas quero mencionar uma coisa que encontrei é um problema ... Se você tiver que concatenar seu certificado com intermediários ou raízes para criar um arquivo em cadeia, não coloque isso em /etc/ssl/certs , porque quando c_rehash é executado, ele pode criar links simbólicos para seus certificados devido às raízes ou intermediários dentro deles.
Em seguida, mais tarde, se seus certificados expirarem e você removê-los, e não souber executar novamente c_rehash , você pode ter quebrado links simbólicos de hash no diretório /etc/ssl/certs , e coisas estranhas começam a acontecer quando sua máquina local tenta se conectar por meio de 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
Logo após a limpeza de alguns arquivos antigos .crt e concatenados .pem eu tinha em /etc/ssl/certs .
Armazenar pelo menos suas cadeias em outro lugar evita esse problema. Eu acabei fazendo um /etc/ssl/local_certs para segurar meus certificados e correntes, para que eles não fossem perdidos na bagunça dos CERs 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 definida como chown root :0 private.key e chmod 600 private.key , de modo que apenas o root possa lê-lo. Os CSRs e os arquivos de certificado são menos sensíveis, como você diz.
Com essas permissões, os caminhos que você mencionou e / usr / local / ssl devem estar bem.