Certificado VPN renovado: alguns clientes ainda o rejeitam

Metade do parque volta a ligar-se após a renovação e três dispositivos recusam, cada um com um aviso sobre a identidade do gateway. A renovação em si é rotina. O que esses três dispositivos guardam é um pin ao objeto antigo, e um pin não é uma lista de CA, uma verificação de nome ou uma entrada no armazenamento de confiança. Compare os três mecanismos antes de tocar em qualquer cliente.

Uma renovação, dois comportamentos

Os clientes que voltam a ligar-se têm uma decisão de confiança que ainda passa, e os que recusam têm um requisito que o novo certificado não satisfaz. Essa diferença é informação, não ruído. Leia com precisão a mensagem do cliente que falha. Uma divergência de nome, um emitente desconhecido e uma impressão digital alterada são três veredictos diferentes, e só o último aponta para um pin.

Verifique também qual perfil o cliente que falha selecionou. Uma cópia importada que vive no seu próprio armazenamento não muda quando o administrador edita o ficheiro original noutro sítio.

Uma renovação substitui o objeto, não apenas a data

Uma impressão digital identifica o conteúdo codificado do certificado. A renovação produz um novo certificado, por isso a impressão digital muda mesmo quando o nome do sujeito e a chave pública ficam idênticos. Isso é esperado e inofensivo para clientes que confiam numa CA e verificam o nome. É fatal para um cliente configurado para aceitar exatamente um certificado, e também é fatal para um cliente cujo armazenamento de confiança nunca recebeu o novo emitente.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

A segunda linha responde a outra pergunta, se o par de chaves sobreviveu. Uma renovação que reutiliza a chave mantém esse valor e altera apenas o certificado, e é exatamente o caso em que o administrador é tentado a assumir que nada mudou. Inspecione o certificado que está implementado, não o que está no host de compilação. Comparar um ficheiro num repositório prova o que foi gerado, não o que um listener está a apresentar neste momento.

Leia o que o cliente está a fixar

Alguns clientes guardam uma impressão digital no seu perfil e comparam-na em cada ligação. Outros guardam-na num armazenamento de confiança da plataforma, e outros ainda dependem apenas de uma CA. A reparação difere em cada caso, por isso identifique primeiro o mecanismo.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

O primeiro comando mostra um pin num perfil convencional; o segundo mostra a impressão digital que o endpoint está realmente a servir agora. Quando os dois diferem, localizou a falha sem adivinhar. Não cole o novo valor em todos os clientes que se queixam. Um cliente que recusa por razões de emitente continuará a recusar, e você terá convencido a si próprio de que a impressão digital era o problema quando não era.

Compare o certificado que cada backend serve

Resultados intermitentes costumam significar mais do que um endpoint, e uma renovação aplicada a um nó deixa os outros a apresentar o objeto antigo. Compare cada backend pelo endereço e não pelo nome partilhado.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Um conjunto em que um nó está atrasado explica um cliente que liga à segunda tentativa e falha à primeira. Também explica uma verificação de monitorização que passa enquanto os utilizadores se queixam. Corrija primeiro o atraso. Implementar a configuração de confiança antes de cada nó servir o novo certificado cria uma janela em que nada funciona, e implementá-la depois deixa os clientes a falhar de forma imprevisível.

Altere a confiança pelo caminho gerido

Confirme a substituição através de um canal administrativo já fidedigno antes de a aceitar em qualquer lugar. Uma data de validade plausível não é prova de propriedade. Atualize a configuração gerida através do processo que é seu proprietário, com qualquer sobreposição planeada de identidades aceitáveis, e mantenha a verificação de nome que a implementação exige. Um pin sem verificação de nome é um desenho mais fraco do que a confiança na CA que substituiu.

Depois verifique por cliente, ligue-se, confirme a identidade que aceitou e anote a versão do certificado em que agora confia. Um aviso ignorado uma vez tem o hábito de voltar na renovação seguinte.