Wat er gebeurt als u een VPN-certificeringsautoriteit vervangt

Een VPN-certificeringsautoriteit vervangen is geen bestandsvervanging. Op het moment dat de nieuwe CA zijn eerste certificaat ondertekent, moet elke validator die nog alleen de oude vertrouwt een beslissing nemen, en hosts die het nieuwe anker nooit ontvangen, blijven goede peers weigeren. Ik heb het in beide richtingen zien misgaan: de gateway leerde de nieuwe CA en de clients niet, dus nieuwe verbindingen faalden, terwijl tunnels die al overeind stonden bleven staan en de storing op een routeringsprobleem leek. Hier is wat er verandert, in de volgorde waarin fouten optreden.

Eén vervanging, twee afzonderlijke wijzigingen

Een certificeringsautoriteit is een naam, een openbare sleutel en de privésleutel die ondertekent. Validators vertrouwen nooit de CA in het abstracte. Ze vertrouwen één specifiek certificaat dat al in een truststore staat, en ze accepteren een uitgever alleen als een keten van handtekeningen die opgeslagen kopie bereikt. Het vervangen van de CA verandert dus twee dingen die onafhankelijk falen: welke ankers worden geaccepteerd en welke peer-identiteiten daaronder zijn uitgegeven.

De meeste VPN-implementaties valideren in beide richtingen. De client authenticeert het certificaat van de gateway en de gateway dat van de client. Een overgang die alleen de clientbundel vernieuwt, laat de server elke client weigeren die nog een identiteit van de oude CA presenteert, en het omgekeerde is even gewoon. Inventariseer eerst de handhavingspunten: truststores van clients, het ca-bestand van de gateway, elke proxy die TLS ervoor beëindigt en de probe die het eindpunt van buitenaf controleert.

Wat een validator controleert, op volgorde

Padvalidatie klimt van het peercertificaat via eventuele tussenliggende certificaten tot het een vertrouwd anker bereikt. Bij elke stap verifieert het de handtekening, controleert het dat elk certificaat binnen zijn geldigheidsvenster valt en bevestigt het dat basisbeperkingen en sleutelgebruik de uitgever toestaan te ondertekenen. Pas dan kijkt de applicatie naar het bladcertificaat: de alternatieve namen van het subject moeten de opgevraagde naam dekken, en het uitgebreide sleutelgebruik moet server- of clientauthenticatie toestaan.

Om dat pad offline te herhalen, wijst u -CAfile naar precies de bundel die u gaat uitrollen, niet naar de systeemopslag. Anders test u de host, niet de wijziging:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Dat commando werkt alleen tegen een eenvoudige TLS-listener zoals de HTTPS-beheerpagina van de gateway; het controlelkanaal van OpenVPN komt vóór TLS, dus s_client kan de handshake van de tunnel niet inspecteren.

De padopbouwregels achter die fouten staan in RFC 5280 sectie 6. Ze verklaren de fouten die anders willekeurig lijken: een verlopen tussenliggend certificaat dat niemand zich herinnerde, een certificaat waarvan het sleutelgebruik ondertekenen verbiedt, of een naambeperking die de host uitsluit die u test.

Waarom de oude tunnel blijft werken

TLS en OpenVPN houden beide een gevestigde sessie in leven nadat de handshake is afgerond. Niets valideert het peercertificaat opnieuw per pakket, dus een client die vóór de wijziging verbinding maakte, blijft verkeer doorlaten tot hij opnieuw onderhandelt, opnieuw verbindt of de tunnel wegvalt. Juist die kloof maakt dat een CA-vervanging een uur lang goed lijkt en dan op het slechtste moment faalt: een laptop wordt wakker uit slaapstand, een NAT-mapping verloopt, een gateway herstart.

Sessiehervatting rekt de illusie nog verder op. Een TLS-sessieticket laat de client terugkeren zonder certificaten opnieuw te sturen, en hervatting slaat padvalidatie over omdat de eerste handshake die al deed. De eerlijke test is dus een volledige handshake in een nieuw proces. Herstart de client in plaats van de tunnel opnieuw te verbinden, en overweeg op een testprofiel tickets uit te schakelen zodat het hervattingspad een gebroken keten niet kan verbergen.

Houd de laag van de statische sleutel hiervan gescheiden. tls-auth voegt een HMAC toe aan het controlelkanaal, tls-crypt versleutelt en authenticeert het, en geen van beide draagt certificaatmateriaal, dus rotatie van een van beide is een aparte wijziging met zijn eigen faalmodus. Implementaties die beide door elkaar halen, eindigen met een client waarvan de statische sleutel in orde is, het certificaat verouderd en de foutmelding geen van beide noemt.

De valkuil van het hergebruiken van de subjectnaam

Het is verleidelijk de distinguished name van de voorganger te hergebruiken zodat stroomafwaarts niets hoeft te veranderen. Dat houdt de uitgeverregel stabiel in de interface en vernietigt het enige signaal dat u nodig hebt. Twee certificaten met identieke subjects en verschillende sleutels zijn niet op naam te onderscheiden, dus een bundel met beide ankers geeft de validator twee kandidaten en geen regel om te kiezen.

De padopbouw kan dan de verkeerde kiezen, melden dat het lokale uitgevercertificaat niet op te halen is terwijl het juiste anker aanwezig is, of slagen op de ene host en falen op een andere met dezelfde bundel, omdat de kandidatenvolgorde verschilde. Als de naam hergebruikt moet worden, houd beide ankers tijdens de overgang in aparte bestanden en laad ze expliciet, en voeg ze pas samen wanneer elke peer de nieuwe uitgever presenteert. Geef de vervanging anders een eigen common name — een generatie- of datumsuffix volstaat — zodat logboeken en foutteksten zeggen onder welke autoriteit een falende peer is uitgegeven.

Een overgang die het netwerk niet neerhaalt

Accepteer voor een geplande vervanging beide ankers gedurende een begrensd venster in plaats van in één stap om te schakelen. Geef de nieuwe CA en haar tussenliggende certificaten uit, zet het nieuwe anker naast het oude in de bundel van elke validator, en begin pas daarna peer-certificaten eruit uit te geven. Peers met oude identiteiten valideren tegen het oude anker; nieuwe werken tegen het nieuwe.

In die volgorde gedaan is elke stap omkeerbaar. De fout die u vermijdt is de gelijktijdige omschakeling, waarbij een client die de bundelupdate miste een gateway treft die het oude anker al heeft afgedankt, de handshake sterft en geen enkel logboek zegt welke kant verouderd is.

Trek terug in de tegenovergestelde richting. Geef elke identiteit opnieuw uit die moet overleven, bevestig dat elk de nieuwe keten presenteert en verwijder dan het oude anker uit de bundels. Neem de privésleutel van de oude CA uit dienst, want een uitgever die nog kan ondertekenen betekent dat de overgang niet klaar is. Bewaar de certificaten en uitgifteregistraties voor de audit. Een verloren uitgever wordt naar hetzelfde vertrouwen hersteld; een blootstelling vereist nieuwe identiteiten en geen terugkeer naar het oude anker.

Controleer het resultaat, niet de bestandslijst

Een trustbestand in de verwachte map bewijst weinig. De applicatie kan een ander pad, een ander formaat of een kopie in een pakket lezen dat een upgrade vervangt. Controleer het gedrag aan beide uiteinden, niet of een bestand bestaat.

Bevestig dat een nieuwe verbinding met een nieuwe identiteit slaagt en bevestig dan dat een identiteit die door de afgedankte CA is uitgegeven wordt geweigerd. Die tweede test is degene die mensen overslaan, en de enige die laat zien dat de oude autoriteit geen toegang meer geeft. Waar de implementatie op CRL's of OCSP leunt, controleer dat de distributiepunten in de nieuwe certificaten oplossen en dat de responder bereikbaar is vanaf de peers die hem bevragen.

Sluit af met een client die nooit verbinding heeft gemaakt: wis zijn profielstatus, verbind en lees de onderhandelde keten. Een peer die een gecachte sessie hervat, meldt vrolijk dat de migratie is geslaagd terwijl hij niets heeft gevalideerd.