Vernieuwd VPN-certificaat: sommige clients weigeren het nog steeds

De helft van de omgeving maakt opnieuw verbinding na de vernieuwing en drie apparaten weigeren, elk met een waarschuwing over de identiteit van de gateway. De vernieuwing zelf is routine. Wat die drie apparaten vasthouden is een pin op het oude object, en een pin is geen CA-lijst, geen naamcontrole en geen vermelding in de truststore. Vergelijk de drie mechanismen voordat u een client aanraakt.

Eén vernieuwing, twee gedragingen

Clients die opnieuw verbinden hebben een vertrouwensbeslissing die nog slaagt, en de weigerende hebben een eis waaraan het nieuwe certificaat niet voldoet. Dat verschil is informatie, geen ruis. Lees het bericht van de falende client nauwkeurig. Een naamverschil, een onbekende uitgever en een gewijzigde vingerafdruk zijn drie verschillende oordelen, en alleen het laatste wijst op een pin.

Controleer ook welk profiel de falende client heeft gekozen. Een geïmporteerde kopie die in zijn eigen opslag leeft, verandert niet wanneer de beheerder het originele bestand elders bewerkt.

Een vernieuwing vervangt het object, niet alleen de datum

Een vingerafdruk identificeert de gecodeerde inhoud van het certificaat. Een vernieuwing levert een nieuw certificaat op, dus de vingerafdruk verandert ook wanneer de subjectnaam en de publieke sleutel identiek blijven. Dat is verwacht en onschadelijk voor clients die een CA vertrouwen en de naam verifiëren. Het is fataal voor een client die is geconfigureerd om precies één certificaat te accepteren, en het is ook fataal voor een client wiens truststore de nieuwe uitgever nooit heeft ontvangen.

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

De tweede regel beantwoordt een andere vraag, of het sleutelpaar heeft overleefd. Een vernieuwing die de sleutel hergebruikt, behoudt die waarde en wijzigt alleen het certificaat, en dat is precies het geval waarin een beheerder in de verleiding komt aan te nemen dat er niets is veranderd. Inspecteer het certificaat dat is uitgerold, niet dat op de buildhost. Een bestand in een repository vergelijken bewijst wat er is gegenereerd, niet wat een listener op dit moment presenteert.

Lees wat de client pint

Sommige clients bewaren een vingerafdruk in hun profiel en vergelijken die bij elke verbinding. Anderen slaan die op in een truststore van het platform, en weer anderen vertrouwen alleen op een CA. De reparatie verschilt per geval, dus identificeer eerst het mechanisme.

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

De eerste opdracht toont een pin in een conventioneel profiel; de tweede toont de vingerafdruk die het eindpunt nu daadwerkelijk serveert. Wanneer die twee verschillen, hebt u de storing gevonden zonder te gissen. Plak de nieuwe waarde niet in elke client die klaagt. Een client die om uitgeverredenen weigert, blijft weigeren, en u hebt uzelf wijsgemaakt dat de vingerafdruk het probleem was terwijl dat niet zo was.

Vergelijk het certificaat dat elke backend serveert

Wisselvallige resultaten betekenen meestal meer dan één eindpunt, en een vernieuwing die op één node is toegepast, laat de andere het oude object presenteren. Vergelijk elke backend op adres in plaats van op de gedeelde naam.

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

Een pool waarin één node achterloopt verklaart een client die bij de tweede poging verbindt en bij de eerste faalt. Het verklaart ook een monitoringcontrole die slaagt terwijl gebruikers klagen. Los eerst de achterstand op. De vertrouwensconfiguratie uitrollen voordat elke node het nieuwe certificaat serveert, creëert een venster waarin niets werkt, en die daarna uitrollen laat clients onvoorspelbaar falen.

Wijzig vertrouwen via het beheerde pad

Bevestig de vervanging via een al vertrouwd administratief kanaal voordat u die ergens accepteert. Een plausibele vervaldatum is geen bewijs van eigendom. Werk de beheerde configuratie bij via het proces dat er eigenaar van is, met elke geplande overlap van acceptabele identiteiten, en behoud de naamverificatie die de uitrol vereist. Een pin zonder naamcontrole is een zwakker ontwerp dan het CA-vertrouwen dat hij verving.

Verifieer daarna per client, maak verbinding, bevestig de identiteit die hij accepteerde, en noteer de certificaatversie die hij nu vertrouwt. Een waarschuwing die één keer is weggeklikt, komt bij de volgende vernieuwing makkelijk terug.