Renovar um certificado VPN sem alterar a sua identidade

Uma renovação de certificado que altera a identidade não é uma renovação, é uma migração vestida de ticket de manutenção. O cliente verifica um nome, uma cadeia e por vezes uma chave específica, e os três podem mudar sem que a data de expiração mude. Antes de pedir uma substituição, anote o que o cliente realmente verifica: o nome do anfitrião ou a identidade do par, a finalidade do certificado, a política de chaves e a cadeia emissora. A renovação é rotineira ou coordenada consoante aquilo que a substituição altera.

Três condições decidem a forma da renovação

As três condições são se algo fixa a folha, se a cadeia muda e quem mais valida o nome. Responda do lado do cliente e não da conveniência da CA, porque o cliente é o que falha às três da manhã.

Comece por inspecionar o certificado que tem. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName imprime o sujeito, o emissor, a janela de validade e os nomes para os quais o certificado é realmente válido. Esse último campo é o mais importante e o mais frequentemente assumido: um pedido de renovação que omite um SAN em que o cliente confia produz um certificado tecnicamente válido mas funcionalmente errado. Copie a lista de SAN do certificado antigo para o pedido em vez de a escrever novamente de memória.

Condição um: algo fixa a folha

Se os clientes confiam numa CA mantida e validam o nome, uma renovação de folha com uma chave nova é invisível para eles. Se qualquer cliente fixa o certificado de folha, a sua impressão digital ou a sua chave pública, a substituição é uma mudança coordenada com uma transição rígida, porque a fixação antiga não pode validar o certificado novo.

Descubra em que caso está antes de encomendar seja o que for. Uma fixação que ninguém documentou continua a ser uma fixação quando quebra.

Condição dois: compare as fixações e a cadeia

As impressões digitais tornam a fixação verificável: openssl x509 -noout -fingerprint -sha256 -in server.crt no certificado antigo e no novo, e openssl x509 -noout -pubkey para comparar chaves públicas. Se a configuração do cliente, um perfil móvel ou um armazenamento de confiança de um equipamento contiver qualquer dos valores, tem uma fixação. Os perfis VPN móveis são um esconderijo comum, porque o perfil é distribuído uma vez e nunca mais inspecionado.

Se a substituição vier do mesmo intermédio e o cliente já o tiver ou o puder obter, nada muda do lado da confiança. Um novo intermédio, um emissor diferente ou uma cadeia entregue na ordem errada transformam uma renovação numa mudança de confiança, e a falha parece um emissor desconhecido em vez de um certificado expirado.

Verifique a cadeia que o servidor envia realmente com openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, e valide-a localmente com openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Fazê-lo antes da mudança dá-lhe uma linha de base para comparar depois.

Condição três: quem mais valida o nome

Um concentrador VPN, um balanceador de carga, uma sonda de monitorização, uma integração RADIUS ou SAML e um perfil móvel podem cada um deter a sua própria cópia do nome esperado ou da âncora de confiança. A renovação é o momento em que essas cópias divergem, porque o certificado muda e as cópias não.

Enumere todos os consumidores antes da mudança e decida, para cada um, se precisa de atualização. Aquele de que se esquecer é o que o vai contactar.

Há também uma armadilha de tempo. Inspecione o início da validade bem como a expiração, porque um certificado preparado para ativação posterior é rejeitado se for instalado demasiado cedo, e o erro parece um problema de relógio em vez de um problema de preparação. openssl x509 -noout -dates no ficheiro novo antes de o implementar é uma verificação de dois segundos. Mantenha também um caminho de recuperação suportado e a configuração conhecida como boa, para que uma renovação que corra mal seja reversível restaurando o certificado e a chave anteriores.

Implemente, verifique com uma autenticação nova e depois retire

Um túnel estabelecido reflete a validação que ocorreu quando foi construído, pelo que pode parecer saudável enquanto todas as novas ligações falham. Teste com uma autenticação nova usando o nome de serviço real que os clientes usam.

Conclua a verificação ao nível da aplicação que interessa ao utilizador e confirme a entrega da cadeia na perspetiva do cliente e não do servidor. Não suprima as verificações de nome ou de certificado para manter a transição silenciosa; isso transforma um problema de compatibilidade temporário num permanente.

Retire o material obsoleto apenas depois de a implementação estar verificada, e trate uma chave comprometida como um caso completamente diferente: a renovação por si só não revoga nada, pelo que a identidade afetada precisa do processo de revogação e de gestão de sessões da implementação. RFC 5280 define as regras de certificado e de validação de caminho por baixo de tudo isto. Mantenha uma renovação de folha rotineira separada de uma substituição de CA, para que não se peça aos clientes que confiem num novo emissor sem motivo.