Certificat VPN renovat: alguns clients encara el rebutgen

La meitat del parc es reconnecta després de la renovació i tres dispositius refusen, cadascun amb un avís sobre la identitat de la passarel·la. La renovació en si és rutina. El que guarden aquests tres dispositius és un pin a l’objecte antic, i un pin no és una llista de CA, una comprovació de nom ni una entrada al magatzem de confiança. Compareu els tres mecanismes abans de tocar cap client.

Una renovació, dos comportaments

Els clients que es reconnecten tenen una decisió de confiança que encara passa, i els que refusen tenen un requisit que el certificat nou no satisfà. Aquesta diferència és informació, no soroll. Llegiu el missatge del client que falla amb precisió. Una discrepància de nom, un emissor desconegut i una empremta canviada són tres veredictes diferents, i només l’últim apunta a un pin.

Comproveu també quin perfil ha seleccionat el client que falla. Una còpia importada que viu al seu propi magatzem no canvia quan l’administrador edita el fitxer original en un altre lloc.

La renovació substitueix l’objecte, no només la data

Una empremta identifica el contingut codificat del certificat. La renovació produeix un certificat nou, així que l’empremta canvia fins i tot quan el nom del subjecte i la clau pública es mantenen idèntics. Això és esperable i inofensiu per als clients que confien en una CA i verifiquen el nom. És fatal per a un client configurat per acceptar exactament un certificat, i també és fatal per a un client el magatzem de confiança del qual mai no va rebre l’emissor nou.

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

La segona línia respon una pregunta diferent: si el parell de claus ha sobreviscut. Una renovació que ha reutilitzat la clau conserva aquest valor i només canvia el certificat, que és exactament el cas en què un administrador es veu temptat d’assumir que no ha canviat res. Inspeccioneu el certificat desplegat, no el de l’amfitrió de compilació. Comparar un fitxer en un repositori demostra què es va generar, no què està presentant ara un oient.

Llegiu què està fixant el client

Alguns clients guarden una empremta al seu perfil i la comparen a cada connexió. Altres la guarden en un magatzem de confiança de plataforma, i d’altres es basen només en una CA. La reparació difereix en cada cas, així que identifiqueu primer el mecanisme.

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

La primera ordre mostra un pin en un perfil convencional; la segona mostra l’empremta que el punt final serveix realment ara mateix. Quan aquestes dues difereixen, heu localitzat la fallada sense endevinar. No enganxeu el valor nou a cada client que es queixa. Un client que rebutja per motius d’emissor continuarà rebutjant, i us haureu ensenyat que l’empremta era el problema quan no ho era.

Compareu el certificat que serveix cada backend

Els resultats intermitents normalment signifiquen més d’un punt final, i una renovació aplicada a un node deixa els altres presentant l’objecte antic. Compareu cada backend per adreça en lloc del nom compartit.

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 conjunt on un node va endarrerit explica un client que es connecta al segon intent i falla al primer. També explica una comprovació de monitoratge que passa mentre els usuaris es queixen. Arregleu primer l’endarreriment. Desplegar la configuració de confiança abans que cada node serveixi el certificat nou crea una finestra en què res no funciona, i desplegar-la després deixa els clients fallant de manera impredictible.

Canvieu la confiança pel camí gestionat

Confirmeu la substitució per un canal administratiu ja fiable abans d’acceptar-la enlloc. Una data de caducitat plausible no és prova de propietat. Actualitzeu la configuració gestionada a través del procés que la posseeix, amb qualsevol solapament planificat d’identitats acceptables, i manteniu la verificació de nom que requereix el desplegament. Un pin sense comprovació de nom és un disseny més feble que la confiança de CA que ha substituït.

Després verifiqueu per client: connecteu-vos, confirmeu la identitat que ha acceptat i anoteu la versió de certificat en què confia ara. Un avís descartat una vegada té tendència a tornar a la propera renovació.