Wat je VPN-client controleert voordat hij een certificaat vertrouwt

Je VPN-client meldt dat het certificaat niet kon worden geverifieerd, en de dialoog stopt daar. Het bestand is er, de server draait, en hetzelfde profiel werkte vorige maand op een andere laptop. Onder die waarschuwing van één regel liet de client het peercertificaat door vier poorten gaan: een certificaatautoriteit die je hebt geconfigureerd borgt het handtekeningspad, dat pad bereikt de autoriteit, de peernaam is degene die je vroeg, en het certificaat is nu bruikbaar voor dit doel. Vind de poort die dichtging en de reparatie is meestal één bestand; sla die stap over en je importeert de hele middag bundels opnieuw.

Lees de dialoog voordat je het profiel bewerkt

Certificaatfouten worden geformuleerd door de bibliotheek eronder, niet door het VPN-product dat je hebt geïnstalleerd, dus de exacte tekenreeks is je eerste bewijs. ‘Kan het certificaat van de lokale uitgever niet ophalen’ wijst op het pad of op het vertrouwensanker. ‘Het certificaat is verlopen of nog niet geldig’ wijst op tijd. ‘Niet-ondersteund certificaatdoel’ wijst op uitgebreid sleutelgebruik. Een naamverschil vertelt je welke naam hij wilde. Geen van de vier wordt gerepareerd door de client opnieuw te installeren.

Verhoog de logboekregistratie voordat je iets wijzigt. OpenVPN meldt de verificatiefout rond de handshake wanneer je het met --verb 4 uitvoert, en strongSwan schrijft zijn identiteits- en ketenbeslissingen naar het charon-log. Bevestig daarna welk certificaat je onderzoekt, want mensen testen routineus het bestand op schijf terwijl het profiel een oudere kopie insluit. Wanneer het profiel PEM-blokken insluit, is het ingesloten certificaat degene die wordt getest.

Een certificaatautoriteit ondertekent identiteiten, geen rechten

De autoriteit houdt een naam en een ondertekeningssleutel. Ze geeft certificaten uit die een openbare sleutel volgens haar eigen beleid aan die naam binden, met een geldigheidsvenster en gebruiksbeperkingen eraan. Je client heeft alleen het certificaat van de autoriteit nodig om de uitgever te herkennen; hij heeft de ondertekeningssleutel nooit nodig, en die sleutel naar clients sturen zou hun de mogelijkheid geven elke identiteit te maken die de uitrol vertrouwt.

Een autoriteit vertrouwen maakt elk certificaat dat ze heeft ondertekend een kandidaat, niet de juiste peer. Een webservercertificaat van dezelfde interne CA is ook een kandidaat. Daarom bestaan de naam- en doelpoorten, en daarom weegt een gecompromitteerde CA-sleutel zwaarder dan elke afzonderlijke server: hij bereikt elke identiteit die de autoriteit ooit heeft uitgegeven. Geef clientcertificaten per apparaat uit, zodat een verloren laptop één intrekking is in plaats van een sleutelvernieuwing voor de hele uitrol.

Bouw het pad opnieuw dat de client probeert te bouwen

Het pad loopt van het peercertificaat, via nul of meer tussenliggende certificaten, naar een wortel in je vertrouwensopslag. Een ontbrekend tussenliggend certificaat is de meest voorkomende ketenfout, en vanaf de clientkant ziet die er precies zo uit als een niet-vertrouwde wortel. Lees eerst het blad en laat OpenSSL daarna het pad bouwen uit het materiaal dat je wilt versturen.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Exitstatus nul betekent dat het pad uit die bestanden is gebouwd; een fout noemt het certificaat dat niet bereikt kon worden. Als openssl verify slaagt terwijl de client nog weigert, zit het verschil in wat de server werkelijk stuurt of in welk vertrouwensbestand het profiel laadt. In OpenVPN kunnen tussenliggende certificaten meereizen in het servercertificaatbestand of apart worden geleverd met --extra-certs, en een bundel met twee wortels onder dezelfde subjectnaam stuurt een van je clients de verkeerde tak in.

Naam en doel zijn aparte poorten

Ketenopbouw vraagt nooit of de naam van jou is. OpenVPN controleert het alleen wanneer het profiel --verify-x509-name instelt, en de oudere gewoonte om alleen de common name te matchen breekt op certificaten waarvan de identiteiten in subjectAltName leven. IKEv2-implementaties matchen de geconfigureerde identiteit met SAN-vermeldingen of met de distinguished name, afhankelijk van de client, en een wildcard- of %any-waarde schakelt stilletjes de vergelijking uit waarvan je dacht dat je die had.

Daarna komen tijd en doel. Een laptop waarvan de klok een paar uur voorloopt, weigert een certificaat dat nog niet geldig is, en een verlopen tussenliggend certificaat laat het pad mislukken terwijl het blad geldig is. Doelfouten komen van een certificaat zonder serverAuth in uitgebreid sleutelgebruik, of met een keyUsage die de handtekeningsignatuur van de handshake niet toestaat, wat OpenSSL als een niet-ondersteund certificaatdoel meldt. Geef opnieuw uit vanuit de juiste sjabloon; niets in dat bericht is een reden om verificatie uit te schakelen.

Intrekking werkt alleen als iemand die heeft geconfigureerd

Een CRL of een OCSP-antwoord wordt niet automatisch geraadpleegd. Op een OpenVPN-server worden clientcertificaten alleen tegen een lijst gecontroleerd wanneer --crl-verify naar een lijst wijst. Controle van het servercertificaat aan de clientkant hangt af van de implementatie en ontbreekt vaak. strongSwan heeft zijn intrekkingsplug-in en een beleid nodig voordat het voor een peer naar een CRL kijkt.

Dat verklaart de ticket die je uiteindelijk krijgt: een ingetrokken clientcertificaat verbindt nog steeds, en iedereen concludeert dat intrekking kapot is. Niets controleerde. Publiceer en ververs de CRL, of houd clientcertificaten kort genoeg levend dat een verouderde intrekking even telt, en oefen het intrekkingspad op een laboratoriumcertificaat voordat je het tijdens een incident nodig hebt.

Een reparatievolgorde die verificatie aan laat

Sorteer op symptoom voordat je bestanden aanraakt, want elke rij van de tabel stuurt je naar een ander object.

Werk de lijst in één pass af: bevestig het bestand dat het profiel laadt, bouw het pad zelf, controleer dat de server het tussenliggende certificaat stuurt, vergelijk de klok, lees de SAN, lees de EKU, en herverbind daarna en kijk hoe dezelfde logregel verdwijnt. Als een apparaat helemaal geen CA kan krijgen, is pinning het eerlijke alternatief, omdat OpenVPN 2.6 --peer-fingerprint accepteert en het vertrouwen tot één sleutel vernauwt in plaats van de controle te verwijderen. RFC 5280 is de referentie voor wat elk van die velden betekent.