É uma boa prática remover a senha de um certificado SSL?

Li em vários blogs agora que é necessário remover senhas de certificados SSL para evitar solicitações de senha durante a reinicialização do Apache.

Isso é verdade e isso representa algum risco à segurança?

Sim, ele interromperá o envio de avisos ao terminal ao iniciar um servidor web.

E sim, isso representa um risco à segurança, porque onde antes do certificado foi criptografado, ele agora está em texto sem formatação. Isso significa que pode ser possível roubar um certificado completamente funcional da máquina.

Se isso representa um risco de segurança significativo para você depende de quais seriam as repercussões se isso acontecesse com você e o que você ganha ao fazê-lo dessa maneira.

Se for mais importante para você que os serviços sejam reiniciados normalmente, mesmo sem a supervisão da segurança geral do sistema SSL, é uma resposta direta.

Pessoalmente, acho que manter cópias descriptografadas de certificados SSL em geral tem mais prós do que contras para minha carga de trabalho típica, eis o porquê;

1. Um invasor ainda teria uma cópia do certificado, mesmo que estivesse criptografado, portanto é seu dever revogá-lo.
2. Hoje em dia, é muito mais fácil para um invasor obter um certificado válido para o seu site via engenharia social do que roubar uma cópia de trabalho de um.
3. Certificados expiram naturalmente, limitando sua superfície de ataque.
4. Os sistemas de segurança baseados em host, como tradicionalmente as permissões e o SELinux, oferecem um meio robusto de proteger certificados na plataforma.
5. Um certificado não é um sistema seguro e completo. Existem muitos outros aspectos a serem considerados, como os dados que você armazena, a mídia em que os armazena e o valor e / ou natureza pessoal dos dados.

Coisas que podem me fazer criptografar:

1. Se você usou o certificado para executar autenticação mútua.
2. É um certificado curinga ou certificado que hospeda vários domínios (as perdas dobram, triplicam ou podem ser usadas por muitos hosts)
3. O certificado é multiuso de alguma outra maneira.
4. O objetivo dos certificados é garantir a integridade de dados de alto valor (registros médicos, transações financeiras e similares).
5. A outra extremidade espera um alto grau de confiança e / ou depende da integridade do seu sistema para tomar decisões operacionais.

Por fim, não confie nos outros para tomar decisões de segurança para você. Você precisa ponderar os riscos e determinar o que é melhor para você e sua instituição, usando o máximo de informações possível.

Ele fornece um pouco mais de segurança, mas a realidade é que, se alguém tiver chegado longe o suficiente no seu sistema para obter acesso à sua chave SSL privada, provavelmente você terá problemas maiores.

De uma perspectiva prática, você realmente quer estar lá toda vez que o apache precisar ser reiniciado para inserir uma senha?

Uma coisa que você pode fazer é manter a senha não protegida por chave no servidor (e protegê-la através da segurança normal do sistema) e manter o backup da chave armazenada em outro lugar com uma senha. Portanto, se alguém conseguir descartar a chave de outro lugar que não seja o servidor (muito mais provável, pense que o laptop de alguém seja roubado com ela na área de trabalho), ele ainda estará protegido.

As chaves Cient usadas para o login devem ser protegidas por senha.

Se você deseja que os serviços baseados em SSL sejam reiniciados sem intervenção manual, você tem duas opções:

1. Não tenha uma senha na chave e proteja-a para que somente os serviços necessários possam acessá-la.
2. Armazene a senha em texto sem formatação ou equivalente em texto sem formatação no servidor, para que os serviços necessários possam fornecer a senha. (Você pode acabar com várias cópias da senha em arquivos de configuração mal protegidos.)

As cópias de backup da chave devem ser protegidas por senha e protegidas como se não estivessem protegidas por senha.