Onde as empresas geralmente armazenam certificados SSL para uso futuro?

Question

Recentemente, compramos um certificado SSL curinga para nosso domínio. Nós convertemos todos os certs para um keystore Java, mas agora estamos nos perguntando onde devemos armazená-los para uso posterior.

As pessoas usam o controle de código-fonte, como o BitBucket, para esses tipos de arquivos, ou simplesmente geram toda vez que são necessárias, ou qualquer outra coisa?

Estamos nos perguntando se existe uma solução padrão ou qualquer "melhor prática" para armazenar esses certificados para uso futuro.

    

Answer 1

Existem várias soluções:

Uma avenida é um cofre de chaves específico, seja um dispositivo baseado em hardware, um módulo de segurança de hardware ou um equivalente baseado em software.

Outra é simplesmente revogar a chave antiga e gerar um novo par de chaves privada / pública quando a situação surgir. Isso muda um pouco o problema de manter a segurança de chave para proteger o nome de usuário / senha da conta com o provedor de certificado e seus procedimentos para reemissão. A vantagem é que a maioria das organizações já possui uma solução de gerenciamento de conta privilegiada, por exemplo, 1 2

Existem várias formas de armazenamento off-line, desde a impressão de uma cópia impressa do par de chaves privado e público, incluindo a senha (mas que será uma cadela para restaurar) até simplesmente armazená-las em mídia digital classificada para muito tempo de armazenamento.

Locais realmente ruins são o GitHub, sua equipe WiKi ou um compartilhamento de rede (e você tem a ideia).

Atualização de 2015/4/29: Keywhiz parece uma abordagem interessante também.

    

Answer 2

Não, os certificados SSL não entram no controle de origem, pelo menos não na parte da chave privada.

Trate-os como se fosse uma senha. Nossas são armazenadas da mesma maneira que nossas senhas - no KeePass. Ele permite que você anexe arquivos e seja criptografado.

    

Answer 3

Se você colocar a chave privada no controle de origem, qualquer pessoa que tenha acesso a ela poderá representar seu servidor. Se o seu servidor web não estiver usando o PFS (sigilo de encaminhamento perfeito), então também é possível descriptografar qualquer tráfego SSL capturado com ferramentas de software livre normalmente disponíveis, como o Wireshark.

Você pode proteger a chave por DES ou AES, criptografando-a com uma senha usando o OpenSSL. O OpenSSL está disponível para Linux, OSX e Windows.

O OpenSSL também pode remover a frase secreta quando uma frase secreta é inconveniente (por exemplo, em um servidor da Web que inicia automaticamente, mas não oferece suporte à entrada automática de senhas).

Adicionando uma senha usando criptografia AES (mais segura que DES): -

openssl rsa -aes256 -in private.key -out encrypted.private.key

Removendo uma frase secreta (você será perguntado pela frase secreta): -

openssl rsa -in encrypted.private.key -out decrypted.private.key

    

Answer 4

Eu recomendaria procurar um HSM offline (como um token de criptografia de hardware ou um CAC) para armazenar a chave privada e o certificado. Isso não apenas protege a chave privada contra comprometimentos acidentais, como também fornece algum descarregamento criptográfico básico.

Se você tiver mais ativos criptográficos para gerenciar, eu recomendaria pesquisar em um Enterprise Key & Software de gerenciamento de certificados, que pode automatizar renovações, acompanhar o ciclo de vida, automatizar o provisionamento para endpoints, etc. A maioria deles armazena o ativo criptografado em repouso como um CLOB em um banco de dados.

    

Answer 5

Outra opção, depois de ler sobre o KeyWhiz, foi o Vault da HashiCorp. Não é apenas um gerenciador de senhas, mas uma loja Secrets, eu acredito um pouco semelhante ao KeyWhiz. É escrito em GO, e o cliente também funciona como o servidor e conecta-se a vários backends e métodos de autenticação. O Vault também é de código aberto, com a opção Enterprise também.

Como as chaves e os certificados SSL são apenas arquivos de texto, você pode codificá-los com base64 e salvá-los como uma string no Vault ou até mesmo apenas no texto do Google Apps Vault. Não há uma WebUI, ou GUI, sua linha de comando, ou script, e tem uma API web muito boa e estável para inicializar.

1. link
2. link