Certificado VPN renovado: algúns clientes aínda o rexeitan

A metade do parque reconéctase despois da renovación e tres dispositivos rexeitan, cada un cun aviso sobre a identidade da pasarela. A renovación en si é rutina. O que gardan eses tres dispositivos é un pin ao obxecto antigo, e un pin non é unha lista de CA, unha comprobación de nome nin unha entrada nun almacén de confianza. Compare os tres mecanismos antes de tocar calquera cliente.

Unha renovación, dous comportamentos

Os clientes que se reconectan teñen unha decisión de confianza que aínda pasa, e os que rexeitan teñen un requisito que o novo certificado non satisfai. Esa diferenza é información, non ruído. Lea a mensaxe do cliente que falla con precisión. Unha discrepancia de nome, un emisor descoñecido e unha pegada cambiada son tres veredictos distintos, e só o último apunta a un pin.

Comprobe tamén que perfil seleccionou o cliente que falla. Unha copia importada que vive no seu propio almacén non cambia cando o administrador edita o ficheiro orixinal noutro lugar.

A renovación substitúe o obxecto, non só a data

Unha pegada identifica o contido codificado do certificado. A renovación produce un certificado novo, así que a pegada cambia mesmo cando o nome do suxeito e a clave pública seguen idénticos. Iso é agardable e inofensivo para os clientes que confían nunha CA e verifican o nome. É fatal para un cliente configurado para aceptar exactamente un certificado, e tamén é fatal para un cliente cuxo almacén de confianza nunca recibiu o novo emisor.

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

A segunda liña responde a outra pregunta: se o par de claves sobreviviu. Unha renovación que reutilizou a clave conserva ese valor e só cambia o certificado, que é xusto o caso no que un administrador se ve tentado de supoñer que nada cambiou. Inspeccione o certificado que está despregado, non o do host de compilación. Comparar un ficheiro nun repositorio demostra que se xerou, non que está presentando agora un oínte.

Lea que está fixando o cliente

Algúns clientes gardan unha pegada no seu perfil e compárana en cada conexión. Outros almacénana nun almacén de confianza da plataforma, e outros apoianse só nunha CA. A reparación difire en cada caso, así que 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 un pin nun perfil convencional; o segundo mostra a pegada que o punto final serve realmente agora mesmo. Cando os dous difiren, localizou o fallo sen adiviñar. Non pegue o valor novo en cada cliente que se queixa. Un cliente que rexeita por motivos de emisor seguirá rexeitando, e terá aprendido que a pegada era o problema cando non o era.

Compare o certificado que serve cada backend

Os resultados intermitentes adoitan significar máis dun punto final, e unha renovación aplicada a un nodo deixa os demais presentando o obxecto antigo. Compare cada backend por enderezo en lugar de polo nome compartido.

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

Un conxunto onde un nodo vai atrasado explica un cliente que se conecta ao segundo intento e falla ao primeiro. Tamén explica unha comprobación de monitorización que pasa mentres os usuarios se queixan. Corrixa primeiro o atraso. Despregar a configuración de confianza antes de que cada nodo sirva o certificado novo crea unha xanela na que nada funciona, e despregala despois deixa os clientes fallando de forma imprevisible.

Cambie a confianza pola vía xestionada

Confirme a substitución por unha canle administrativa xa fiable antes de aceptala en calquera sitio. Unha data de caducidade plausible non é proba de propiedade. Actualice a configuración xestionada mediante o proceso que a posúe, con calquera solapamento planificado de identidades aceptables, e manteña a verificación de nome que esixe o despregamento. Un pin sen comprobación de nome é un deseño máis feble que a confianza de CA que substituíu.

Despois verifique por cliente: conecte, confirme a identidade que aceptou e anote a versión de certificado na que confía agora. Un aviso descartado unha vez ten a costume de volver na próxima renovación.