Eu tenho que criar um CSR para um certificado SSL curinga. Algumas perguntas frequentes de provedores SSL dizem que eu devo gerar o arquivo CSR na máquina em que desejo instalar o certificado? Meu entendimento é que não importa onde eu gere o CSR ou o arquivo de chave, desde que mova os arquivos para o local correto posteriormente.
Então, minha pergunta é: importa onde o CSR e os arquivos-chave para certificação SSL são gerados?
Respostas:
Sua compreensão está correta. Todas as outras coisas são iguais, não importa; mas há rugas.
Uma vantagem de gerá-los no servidor em questão é que ele minimiza a chance de a chave ser comprometida em trânsito. Contanto que você use uma máquina segura para gerá-los e um método seguro (imune a ataques MITM) para movê-los para o servidor, você escapará disso. Não se esqueça de apagá-los com segurança no sistema de geração, a menos que você pretenda manter cópias, e esteja protegido adequadamente.
Uma vantagem de gerar em uma máquina separada: geralmente, essa será a sua área de trabalho. O conjunto de entropia em uma máquina de mesa é quase sempre mais profundo do que em um servidor autônomo, porque a área de trabalho tem uma grande fonte de aleatoriedade conectada através dos cabos do teclado e do mouse (ou seja, você!). A escassez de entropia pode levar a geração de chaves a demorar muito tempo, ou usar a /dev/urandomsaída PRNG, dependendo de quão paranóica é a ferramenta geradora, e isso pode levar a chaves mais fracas; máquinas de mesa tendem a não ter esse problema.
Edição posterior : de acordo com uma discussão em outro lugar que apontou aqui, dois pontos foram levantados. Em primeiro lugar, você poderia ir para uma casa no meio do caminho, gerando a entropia no ambiente de trabalho com, por exemplo dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, a cópia que para o servidor remoto, e alimentá-lo para o seu processo de geração da chave diretamente ou através do aprofundamento poça de entropia do servidor remoto. Ainda não encontrei uma maneira de fazer a primeira, e geralmente é necessário exercer privilégios, os quais - se o canal entre você e o servidor remoto não é seguro, o que é o objetivo de toda a objeção - também são inseguros.
Em segundo lugar, o mjg59 estimável levanta a questão dos módulos de segurança de hardware - ou seja, dispositivos nos quais você coloca, ou dentro dos quais você cria, chaves privadas e, em seguida, executa operações de chave sem nunca deixar a chave sair. Esse é um ponto excelente, mas fora do escopo desta questão.
Mas o resultado mais geral do encadeamento - que você deve ter um modelo de ameaça preciso e escolher suas respostas adequadamente - é bom. Meu modelo de ameaça é que meus canais de comunicação são seguros, mas meus terminais estão sob ataque inteligente. Isso significa que gerarei pares de chaves SSL com entropia forte localmente e os distribuirei. Se meu modelo for impreciso e minhas comunicações se tornarem vulneráveis, saberei imediatamente que todos os meus pares de chaves SSL estão comprometidos. Se o seu modelo de ameaça for diferente, você deve adaptar suas práticas de acordo.
Isso importa um pouco.
Se você gerá-los em outra máquina, as chaves estarão vulneráveis na máquina geradora e, em seguida, no servidor. Se você usar uma máquina infectada para gerá-los, alguns vírus poderão roubar as chaves, mesmo antes de serem movidas para o servidor seguro.
Se você gerá-los em um servidor seguro e apenas mover o CSR / cert, as chances de alguém / algo obter a chave privada são menores do que no primeiro caso, uma vez que a chave privada está localizada apenas em uma máquina.