Fornyet VPN-certifikat: nogle klienter afviser det stadig

Halvdelen af miljøet genopretter forbindelsen efter fornyelsen, og tre enheder afviser, hver med en advarsel om gatewayens identitet. Selve fornyelsen er rutine. Det, de tre enheder holder, er et pin til det gamle objekt, og et pin er ikke en CA-liste, en navnekontrol eller en post i et trust store. Sammenlign de tre mekanismer, før du rører nogen klient.

Én fornyelse, to adfærdsmønstre

De klienter, der genopretter forbindelsen, har en tillidsbeslutning, der stadig består, og dem, der afviser, har et krav, som det nye certifikat ikke opfylder. Den forskel er information, ikke støj. Læs den fejlende klients besked præcist. Et navnemismatch, en ukendt udsteder og et ændret fingeraftryk er tre forskellige kendelser, og kun den sidste peger på et pin.

Kontrollér også, hvilken profil den fejlende klient valgte. En importeret kopi, der bor i sit eget lager, ændrer sig ikke, når administratoren redigerer den oprindelige fil et andet sted.

Fornyelsen erstatter objektet, ikke bare datoen

Et fingeraftryk identificerer certifikatets kodede indhold. Fornyelse producerer et nyt certifikat, så fingeraftrykket ændrer sig, selv når subjektnavnet og den offentlige nøgle forbliver identiske. Det er forventet og uskadeligt for klienter, der stoler på en CA og verificerer navnet. Det er fatalt for en klient, der er konfigureret til at acceptere præcis ét certifikat, og det er også fatalt for en klient, hvis trust store aldrig modtog den nye udsteder.

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

Den anden linje besvarer et andet spørgsmål: om nøgleparret overlevede. En fornyelse, der genbrugte nøglen, beholder den værdi og ændrer kun certifikatet, hvilket netop er det tilfælde, hvor en administrator fristes til at antage, at intet er ændret. Undersøg det certifikat, der er udrullet, ikke det på build-værten. At sammenligne en fil i et repository beviser, hvad der blev genereret, ikke hvad en lytter præsenterer lige nu.

Læs, hvad klienten pinner

Nogle klienter holder et fingeraftryk i deres profil og sammenligner det ved hver forbindelse. Andre gemmer det i et platform-trust store, og andre igen stoler kun på en CA. Reparationen er forskellig i hvert tilfælde, så identificér først mekanismen.

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

Den første kommando viser et pin i en konventionel profil; den anden viser det fingeraftryk, som endpointet faktisk betjener lige nu. Når de to er forskellige, har du lokaliseret fejlen uden at gætte. Indsæt ikke den nye værdi i hver klient, der klager. En klient, der afviser på udsteder-grunde, vil blive ved med at afvise, og du har lært dig selv, at fingeraftrykket var problemet, da det ikke var.

Sammenlign certifikatet, som hver backend betjener

Periodiske resultater betyder normalt mere end ét endpoint, og en fornyelse, der blev anvendt på én node, efterlader de andre med at præsentere det gamle objekt. Sammenlign hver backend efter adresse i stedet for efter det delte navn.

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

En pulje, hvor én node sakker bagud, forklarer en klient, der forbinder i andet forsøg og fejler i det første. Det forklarer også en overvågningskontrol, der består, mens brugerne klager. Ret forsinkelsen først. Udrulning af tillidskonfigurationen, før hver node betjener det nye certifikat, skaber et vindue, hvor intet virker, og udrulning bagefter lader klienter fejle uforudsigeligt.

Skift tillid ad den administrerede vej

Bekræft udskiftningen gennem en allerede betroet administrativ kanal, før du accepterer den noget sted. En plausibel udløbsdato er ikke bevis på ejerskab. Opdatér den administrerede konfiguration gennem den proces, der ejer den, med ethvert planlagt overlap af acceptable identiteter, og behold den navneverifikation, som udrulningen kræver. Et pin uden navnekontrol er et svagere design end den CA-tillid, det erstattede.

Verificér derefter pr. klient: forbind, bekræft den identitet, den accepterede, og notér den certifikatversion, den nu stoler på. En advarsel, der afvises én gang, har en tendens til at vende tilbage ved næste fornyelse.