Aconteça o que acontecer, você precisará descriptografar o arquivo de chaves para usá-lo. Existem algumas opções.
- Descriptografe o arquivo de chaves e use isso. Isso oferece um reinício permanente e elegante de seus serviços, que é o que você procura. Mas a chave é desprotegida, não criptografada, armazenada em seu servidor.
- Forneça as senhas do provedor de serviços aos seus certificados. Isso pode ser ideal, mas você precisa de um nível de garantia de que o serviço será reiniciado com o prompt na inicialização. Seja que eles possam ter seu software de monitoramento os alertando para este evento, no entanto, você deve, sob essas circunstâncias, estar aberto a situações em que a senha da chave não é digitada, ou com um atraso na senha digitada pelo provedor de serviços. Caberá a você negociar os termos que o prestador de serviços oferecerá a você nesse serviço e quais garantias de sucesso eles fornecerão. Se eles vão fornecer isso em tudo.
- Alguns servidores http, como o apache, fornecem uma opção chamada SSLPassPhraseDialog , que tentará descriptografar a chave usando um programa escrito que transmitirá a frase-senha correta quando executada. Isso pode ser um shell script ou programa de sua escolha que fará isso. Isto tem o benefício de lhe dar a opção nº 1, mas age apenas como uma barreira fraca a todos os problemas descritos na opção número 1. Além disso, dependendo de quão cuidadoso você está (ou não) fornecendo uma senha executável, isso pode fornecer um mecanismo para alguém para obter algo outro do que o executável da senha para executar na inicialização.
- Solicite ao seu provedor de hospedagem que ele forneça um tempo de inatividade programado (se eles estiverem fazendo a reinicialização) para que você possa estar pronto para inserir a senha em si mesmo ou alterar as atualizações para serem executadas no momento em que você estiver pronto para entrar a frase secreta para o certificado imediatamente.
Minha primeira sugestão é perguntar por que você precisa criptografar o certificado SSL e quais perdas isso produz em sua operação se o serviço ficar inativo por, digamos, duas horas até que seja descoberto. Quais são as possíveis perdas para você se o certificado for violado e quanto tempo levaria para corrigir? Se custar mais do que o seu certificado SSL e o tempo de recuperação em caso de violação for muito alto, talvez seja correto mantê-lo criptografado.
Para ser franco, você não pode ter seu bolo e comê-lo. Se você deseja criptografar a chave SSL, faça isso com o custo de reinicializações não-graciosas e atrasos na sua operação. Se você criptografá-lo, mas fornecer uma maneira de automatizar a descriptografia, provavelmente será tão inútil ou potencialmente mais perigoso do que ter a chave descriptografada em primeiro lugar. Se você assumir a responsabilidade de seus provedores VPS, então apenas transferirá o problema para eles e isso provavelmente lhe custará muito para lhe dar as garantias desejadas, ou você terá que aceitar que haverá momentos em que o provedor de VPS não atende às suas expectativas quando eles reinicializam o VPS.
Minha sugestão, é fazer reinicializações em tempo hábil e com aviso prévio, eu não acho que seria razoável perguntar ao seu provedor de VPS para isso. Dessa forma, não deve haver um incidente que você não possa pelo menos colocar sob algum controle.
* O problema de usar SSLPassPhraseDialog é um erro semelhante, mais comum e problemático que as pessoas fazem com as tarefas agendadas. Ou seja, implantar o cronjob para executar como root e, em seguida, tornar a propriedade dos arquivos do que está executando um usuário não raiz (digamos, FTP) que possa potencialmente modificar o aplicativo para escalonar privilégios. Se você escrever um programa para citar a senha, tome providências para garantir que o arquivo não seja prontamente legível, nem o arquivo pode ser modificado com nada além de root (isso inclui garantir que seu diretório pai mantido não seja de outra pessoa).