Om 'n VPN-sertifikaat te hernu sonder om die identiteit daarvan te verander

'n Sertifikaathernuwing wat die identiteit verander, is nie 'n hernuwing nie; dit is 'n migrasie in 'n onderhoudskaartjie se klere. Die kliënt verifieer 'n naam, 'n ketting en soms 'n spesifieke sleutel, en al drie kan verander sonder dat die vervaldatum verander. Skryf voordat jy 'n vervanging aanvra neer wat die kliënt werklik nagaan: die gasheernaam of eweknie-identiteit, die sertifikaatdoel, die sleutelbeleid en die uitreikende ketting. Die hernuwing is roetine of gekoördineerd, afhangend van watter van dié die vervanging wysig.

Drie voorwaardes bepaal die vorm van die hernuwing

Die drie voorwaardes is of enigiets die bladsertifikaat vaspen, of die ketting verander, en wie anders die naam valideer. Beantwoord dit van die kliënt se kant eerder as uit die CA se gerief, want die kliënt is wat om drieuur in die oggend faal.

Begin deur die sertifikaat te inspekteer wat jy het. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName druk die subjek, die uitreiker, die geldigheidsvenster en die name waarvoor die sertifikaat werklik geldig is, uit. Daardie laaste veld is die belangrikste en word die meeste aangeneem: 'n hernuwingsversoek wat 'n SAN weglaat waarop die kliënt staatmaak, lewer 'n sertifikaat wat tegnies geldig en funksioneel verkeerd is. Kopieer die SAN-lys uit die ou sertifikaat na die versoek eerder as om dit uit die geheue te hertik.

Voorwaarde een: is daar enigiets wat die bladsertifikaat vaspen

As kliënte 'n onderhoude CA vertrou en die naam valideer, is 'n hernuwing van die bladsertifikaat met 'n nuwe sleutel onsigbaar vir hulle. As enige kliënt die bladsertifikaat, die vingerafdruk daarvan of die publieke sleutel daarvan vaspen, is die vervanging 'n gekoördineerde verandering met 'n harde oorskakeling, want die ou vaspenning kan nie die nuwe sertifikaat valideer nie.

Vind uit in watter geval jy is voordat jy iets bestel. 'n Vaspenning wat niemand gedokumenteer het nie, is steeds 'n vaspenning wanneer dit breek.

Voorwaarde twee: vergelyk die vaspenninge en die ketting

Vingerafdrukke maak die vaspenning kontroleerbaar: openssl x509 -noout -fingerprint -sha256 -in server.crt op die ou en die nuwe sertifikaat, en openssl x509 -noout -pubkey om publieke sleutels te vergelyk. As die kliëntkonfigurasie, 'n mobiele profiel of 'n toestel se vertrouensbewaarplek enige van die twee waardes bevat, het jy 'n vaspenning. Mobiele VPN-profiele is 'n algemene skuilplek, want die profiel word een keer versprei en nooit weer geïnspekteer nie.

As die vervanging van dieselfde intermediêre sertifikaat kom en die kliënt het daardie intermediêre sertifikaat al of kan dit haal, verander niks aan die vertrouekant nie. 'n Nuwe intermediêre sertifikaat, 'n ander uitreiker of 'n ketting wat in die verkeerde volgorde gestuur word, verander almal 'n hernuwing in 'n vertroueverandering, en die fout lyk soos 'n onbekende uitreiker eerder as 'n vervalle sertifikaat.

Kontroleer die ketting wat die bediener werklik stuur met openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, en verifieer dit plaaslik met openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. As jy dit voor die verandering doen, het jy 'n basislyn om daarna mee te vergelyk.

Voorwaarde drie: wie anders valideer die naam

'n VPN-konsentrator, 'n lasbalanseerder, 'n moniteringsprobe, 'n RADIUS- of SAML-integrasie en 'n mobiele profiel kan elkeen sy eie kopie van die verwagte naam of vertrouensanker hou. Hernuwing is die oomblik waarop daardie kopieë uiteenloop, want die sertifikaat verander en die kopieë nie.

Lys elke verbruiker voor die verandering en besluit vir elkeen of dit 'n opdatering nodig het. Die een wat jy vergeet, is die een wat jou op die pieper roep.

Daar is ook 'n tydsberekeningstrik. Inspekteer die geldigheidsbegin sowel as die vervaldatum, want 'n sertifikaat wat vir latere aktivering voorberei is, word verwerp as dit te vroeg geïnstalleer word, en die fout lyk soos 'n klokprobleem eerder as 'n voorbereidingsprobleem. openssl x509 -noout -dates op die nuwe lêer voordat jy dit ontplooi, is 'n twee-sekonde-kontrole. Hou ook 'n ondersteunde herstelpad en die bekende-goeie konfigurasie byderhand, sodat 'n hernuwing wat verkeerd loop omkeerbaar is deur die vorige sertifikaat en sleutel te herstel.

Ontplooi, verifieer met 'n vars verifikasie en trek dan terug

'n Gevestigde tonnel weerspieël die validering wat gebeur het toe dit gebou is, so dit kan gesond lyk terwyl elke nuwe verbinding misluk. Toets met 'n vars verifikasie deur die werklike diensnaam te gebruik wat die kliënte gebruik.

Voltooi die toepassingsvlakkontrole wat vir die gebruiker saak maak, en bevestig kettingaflewering vanuit die kliënt se perspektief eerder as vanuit die bediener s'n. Moenie naam- of sertifikaatkontroles onderdruk om die oorgang stil te hou nie; dit verander 'n tydelike versoenbaarheidsprobleem in 'n permanente een.

Onthou eers verouderde materiaal nadat die ontplooiing geverifieer is, en behandel 'n gekompromitteerde sleutel as 'n heeltemal ander geval: hernuwing alleen herroep niks, so die geaffekteerde identiteit het die ontplooiing se herroepings- en sessiehanteringsproses nodig. RFC 5280 definieer die sertifikaat- en padvalideringsreëls onder dit alles. Hou 'n roetine-hernuwing van die bladsertifikaat apart van 'n CA-vervanging, sodat kliënte nie gevra word om 'n nuwe uitreiker sonder rede te vertrou nie.