Een VPN-certificaat vernieuwen zonder de identiteit te wijzigen

Een certificaatvernieuwing die de identiteit wijzigt is geen vernieuwing, het is een migratie in een onderhoudsticket. De client verifieert een naam, een keten en soms een specifieke sleutel, en alle drie kunnen veranderen zonder dat de vervaldatum verandert. Schrijf voordat u een vervanging aanvraagt op wat de client werkelijk controleert: de hostnaam of peer-identiteit, het doel van het certificaat, het sleutelbeleid en de uitgevende keten. De vernieuwing is routine of gecoördineerd, afhankelijk van wat de vervanging daarvan wijzigt.

Drie voorwaarden bepalen de vorm van de vernieuwing

De drie voorwaarden zijn of iets het blad vastpint, of de keten verandert, en wie de naam nog meer valideert. Beantwoord ze vanaf de clientzijde in plaats van vanuit het gemak van de CA, want de client is wat er om drie uur 's nachts faalt.

Begin met het inspecteren van het certificaat dat u hebt. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName drukt het subject, de uitgever, het geldigheidsvenster en de namen af waarvoor het certificaat werkelijk geldig is. Dat laatste veld is het belangrijkst en wordt het vaakst aangenomen: een vernieuwingsaanvraag die een SAN weglaat waarop de client vertrouwt, levert een certificaat op dat technisch geldig en functioneel onjuist is. Kopieer de SAN-lijst uit het oude certificaat naar de aanvraag in plaats van die uit het geheugen opnieuw te typen.

Voorwaarde één: pint iets het blad vast

Als clients een onderhouden CA vertrouwen en de naam valideren, is een bladvernieuwing met een nieuwe sleutel onzichtbaar voor hen. Als een client het bladcertificaat, de vingerafdruk of de openbare sleutel vastpint, is de vervanging een gecoördineerde wijziging met een harde overgang, omdat de oude pin het nieuwe certificaat niet kan valideren.

Zoek uit in welk geval u zit voordat u iets bestelt. Een pin die niemand heeft gedocumenteerd, is nog steeds een pin als hij breekt.

Voorwaarde twee: vergelijk de pins en de keten

Vingerafdrukken maken de pin controleerbaar: openssl x509 -noout -fingerprint -sha256 -in server.crt op het oude en het nieuwe certificaat, en openssl x509 -noout -pubkey om openbare sleutels te vergelijken. Als de clientconfiguratie, een mobiel profiel of een truststore van een apparaat een van beide waarden bevat, hebt u een pin. Mobiele VPN-profielen zijn een veelvoorkomende schuilplaats, omdat het profiel één keer wordt verspreid en daarna nooit meer wordt geïnspecteerd.

Als de vervanging van dezelfde tussenliggende uitgever komt en de client die al heeft of kan ophalen, verandert er niets aan de vertrouwenskant. Een nieuwe tussenliggende uitgever, een andere uitgever of een keten die in de verkeerde volgorde wordt geleverd, maken van een vernieuwing een vertrouwenswijziging, en de fout ziet eruit als een onbekende uitgever in plaats van een verlopen certificaat.

Controleer de keten die de server werkelijk verstuurt met openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, en verifieer die lokaal met openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Dat vóór de wijziging doen geeft u een basislijn om daarna mee te vergelijken.

Voorwaarde drie: wie valideert de naam nog meer

Een VPN-concentrator, een loadbalancer, een monitoringprobe, een RADIUS- of SAML-integratie en een mobiel profiel kunnen elk hun eigen kopie van de verwachte naam of het vertrouwensanker hebben. De vernieuwing is het moment waarop die kopieën uiteenlopen, omdat het certificaat verandert en de kopieën niet.

Inventariseer elke verbruiker vóór de wijziging en beslis voor elk of er een update nodig is. Degene die u vergeet, is degene die u belt.

Er is ook een timingval. Inspecteer de start van de geldigheid naast de vervaldatum, omdat een certificaat dat voor latere activering klaarstaat wordt geweigerd als het te vroeg wordt geïnstalleerd, en de fout lijkt op een klokprobleem in plaats van een voorbereidingsprobleem. openssl x509 -noout -dates op het nieuwe bestand voordat u het uitrolt is een controle van twee seconden. Houd ook een ondersteund herstelpad en de bekende goede configuratie bij, zodat een vernieuwing die misgaat omkeerbaar is door het vorige certificaat en de sleutel te herstellen.

Rol uit, verifieer met een nieuwe authenticatie en trek daarna in

Een bestaande tunnel weerspiegelt de validatie die plaatsvond toen hij werd opgebouwd, dus hij kan gezond lijken terwijl elke nieuwe verbinding faalt. Test met een nieuwe authenticatie met de werkelijke servicenaam die de clients gebruiken.

Voltooi de controle op applicatieniveau die de gebruiker belangrijk vindt, en bevestig de ketenlevering vanuit het perspectief van de client in plaats van de server. Onderdruk naam- of certificaatcontroles niet om de overgang stil te houden; dat maakt een tijdelijk compatibiliteitsprobleem permanent.

Trek verouderd materiaal pas in nadat de uitrol is geverifieerd, en behandel een gecompromitteerde sleutel als een volstrekt ander geval: een vernieuwing alleen trekt niets in, dus de getroffen identiteit heeft het intrekkings- en sessiebeheerproces van de uitrol nodig. RFC 5280 definieert de certificaat- en padvalidatieregels onder dit alles. Houd een routine bladvernieuwing gescheiden van een CA-vervanging, zodat clients niet zonder reden wordt gevraagd een nieuwe uitgever te vertrouwen.