
Eu tenho um servidor openvpn, os clientes autenticam usando certificados SSL. Sempre que um certificado de cliente expirar, um novo certificado deverá ser emitido e enviado ao cliente.
Descobri que o easyrsa do openvpn tem umrenovarcomando, mas AFAIK realmente não renova:Easyrsa “renovar” é um nome enganoso · Edição nº 345 · OpenVPN/easy-rsa
Então a questão é: é tecnicamente possível estender a validade de um certificado SSL independentemente de ele ter expirado ou não, para evitar o envio de um novo arquivo ao usuário cliente?
Responder1
Esta é uma pergunta muito boa :-).
Technically : yes (at the end the client could use expired one to connect)
Easily : no
Em princípio não é possível que a CA assine o pedido de certificado com prazo de validade específico, pelo que não pode ser prorrogado. O que você pode fazer é criar um novo certificado e a parte complicada pode estar no processo de emissão e no processo de verificação da validade.
No início seria justo mencionar que o material a seguir está tecnicamente relacionado a certificados em geral e eu não testei com openvpn - se não passasse a resposta geral seria NÃO :-(.
Na configuração do openVPN existem 3 parâmetros relacionados aos certificados - ca, chave e certificado.
key: chave privada para assinatura de dados. Pode ser usado para descriptografar os dados criptografados pelocertificado.
cert: chave pública (derivada dechave) para confirmar a validade dos dados assinados pela chave. Ele pode ser usado para criptografar os dados da chave. Isto seria fornecido ao "outro extremo" durante a negociação da conexão segura. / este cenário funciona no caso em que o certificado válido já pode ser conhecido no terminal remoto, portanto, o envio do certificado pode ser opcional e desde que um certificado expirado possa ser ignorado /
ca: É usado para verificar a validade do certificado fornecido durante a negociação de conexão segura.
Depois que o certificado do cliente expirar, o caso é que apenascertificadoestá desatualizado. A chave, em princípio, não está expirando e a CA não deve expirar (nesse caso, é um caso de uso totalmente diferente ;-)). O certificado contém prazo de validade e faz parte do “envelope” assinado pela CA em estrutura x.509.
É uma boa prática gerar uma nova chave com a geração de um novo certificado, mas não há nada que force esta etapa, então tecnicamente não é problema criar CSR (Solicitação de Assinatura de Certificado) usando a mesma chave como um certificado realmente expirado. Caso você tenha CSR antigo disponível, você pode usá-lo diretamente para um novo certificado. Depois que este CSR for assinado com a CA, o novo certificado será derivado da chave "antiga".
A parte complicada é que você precisa de (um de):
entregar este novo certificado ao usuário atual para substituir o certificado
conheça o servidor sobre este certificado para que ele possa ser usado em vez do expirado fornecido pelo cliente (esta é a parte teórica deste caso de uso ;-))
O que eu sei é que você pode combinar mais certificados CA emcaarquivo vinculado na configuração do servidor sem problemas (em formato PEM). Tecnicamente, o certificado "usuário" e o certificado "ca" diferem no parâmetro que indica se pode ser usado como CA. Então, tecnicamente, você pode combinar o certificado CA com este certificado recém-gerado em um arquivo...
Assim que este arquivo estiver instalado (provavelmente será necessário reiniciar o servidor openvpn), você pode tentar estabelecer uma nova conexão. Uma vez que o cliente com a chave tente se conectar, pode acontecer que o servidor seja capaz de "identificar" a chave com base no hash emparelhado com este certificado de cliente localizado no servidor e ignorar o certificado fornecido pelo cliente (isso deve ser testado ). Tecnicamente (ponto de vista do certificado como tecnologia) funcionaria, mas não tentei com o openVPN. Como o openVPN está usando uma biblioteca externa para coisas SSL, pode ser uma abordagem funcional ;-).
No lado do cliente é necessária uma CA para comprovar o lado do servidor (não expirou), chave para assinar e descriptografar a comunicação (não expirou) e o próprio certificado não é realmente necessário para operação local, portanto, um certificado expirado não é realmente um problema. O certificado do servidor é obtido durante a negociação SSL e verificado usando o certificado CA local para que tudo o que for necessário esteja disponível (chave local, certificado remoto).
A desvantagem dessa abordagem é que você está perdendo um pouco o benefício da CA como certificado único para validação do certificado do cliente (você precisa listá-lo no lado do servidor próximo ao certificado da CA), mas por outro lado, a vantagem seria a possibilidade de renovação o certificado...
Caso você tente, sinta-se à vontade para fornecer feedback ...
Boa sorte!
A outra abordagem em caso de planejamento poderia ser emitir certificados de longo prazo de validade e utilizar CRL (Lista de Relocação de Certificados) para revogar certificados inválidos durante o período. Mas este não é o escopo desta questão ...