Wat gebeur wanneer jy 'n VPN-sertifikaatowerheid vervang

Om 'n VPN-sertifikaatowerheid te vervang is nie 'n lêerruiling nie. Die oomblik wanneer die nuwe CA sy eerste sertifikaat onderteken, moet elke valideerder wat nog net die oue vertrou, 'n besluit neem, en gashere wat nooit die nuwe anker ontvang nie, hou aan om goeie eweknieë te verwerp. Ek het dit al in beide rigtings sien skeefloop: die poort het die nuwe CA geleer terwyl die kliënte dit nie gedoen het nie, so nuwe verbindings het gefaal, terwyl tonnels wat reeds op was, bly staan het en die onderbreking soos 'n roeteringsprobleem laat lyk het. Hier is wat verander, in die volgorde waarin foute verskyn.

Een vervanging, twee afsonderlike veranderinge

'n Sertifikaatowerheid is 'n naam, 'n publieke sleutel en die private sleutel wat onderteken. Valideerders vertrou nooit ‘die CA’ in die abstrak nie. Hulle vertrou een spesifieke sertifikaat wat reeds in 'n vertrouensbergplek sit, en hulle aanvaar 'n uitreiker net as 'n ketting van handtekeninge daardie gestoorde kopie bereik. Om die CA te vervang verander dus twee dinge wat onafhanklik faal: watter ankers aanvaar word, en watter eweknie-identiteite onder hulle uitgereik is.

Die meeste VPN-ontplooiings valideer in albei rigtings. Die kliënt verifieer die poort se sertifikaat, en die poort verifieer die kliënt se sertifikaat. 'n Oorskakeling wat net die kliëntbundel vernuwe, laat die bediener elke kliënt verwerp wat nog 'n identiteit uit die ou CA aanbied, en die omgekeerde kom net so gereeld voor. Inventariseer eers die handhawingspunte: kliëntvertrouensbergplekke, die poort se ca-lêer, enige TLS-afsluitende instaanbediener daarvoor, en die peiling wat die eindpunt van buite af toets.

Wat 'n valideerder nagaan, in volgorde

Padvalidering klim van die eweknie-sertifikaat deur enige tussenliggende sertifikate totdat dit 'n vertroude anker bereik. By elke stap verifieer dit die handtekening, kontroleer dat elke sertifikaat binne sy geldigheidsvenster val, en bevestig dat basiese beperkings en sleutelgebruik die uitreiker toelaat om te onderteken. Eers dan kyk die toepassing na die blaar: die vakalternatiewename moet die naam dek wat geskakel is, en die uitgebreide sleutelgebruik moet bediener- of kliëntverifikasie toelaat.

Om daardie stappie vanlyn te herhaal, wys -CAfile na die presiese bundel wat jy gaan ontplooi en nie na die stelselbergplek nie. Anders toets jy die gasheer, nie die verandering nie:

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

Daardie opdrag werk net teen 'n gewone TLS-luisteraar soos die poort se HTTPS-administrasiebladsy; OpenVPN se beheerkanaal kom voor TLS, so s_client kan nie die tonnel-handdruk inspekteer nie.

Die padboureëls agter daardie foute staan in RFC 5280 afdeling 6. Hulle verduidelik die mislukkings wat andersins willekeurig lyk: 'n vervalle tussenliggende sertifikaat wat niemand onthou het nie, 'n sertifikaat waarvan die sleutelgebruik ondertekening verbied, of 'n naambeperking wat die gasheer wat jy toets, uitsluit.

Hoekom die ou tonnel aanhou werk

TLS en OpenVPN hou albei 'n gevestigde sessie lewendig nadat die handdruk klaar is. Niks hervalideer die eweknie-sertifikaat per pakkie nie, so 'n kliënt wat voor die verandering gekoppel het, hou aan om verkeer deur te stuur totdat dit weer onderhandel, weer koppel of die tonnel val. Daardie gaping is hoekom 'n CA-vervanging 'n uur lank goed kan lyk en dan op die slegste oomblik faal: 'n skootrekenaar word wakker uit slaap, 'n NAT-kaarteerding verstryk, 'n poort herbegin.

Sessie-hervatting rek die illusie verder. 'n TLS-sessiekaartjie laat 'n kliënt terugkeer sonder om sertifikate weer te stuur, en hervatting slaan padvalidering oor omdat die eerste handdruk dit reeds gedoen het. Dus is die eerlike toets 'n volle handdruk op 'n vars proses. Herbegin die kliënt eerder as om die tonnel weer te koppel, en oorweeg dit op 'n toetsprofiel om kaartjies te deaktiveer sodat die hervattingpad nie 'n stukkende ketting kan verberg nie.

Hou die statiese-sleutellaag hiervan apart. tls-auth voeg 'n HMAC by die beheerkanaal, tls-crypt versleutel en verifieer dit, en nie een van hulle dra sertifikaatmateriaal nie, so die rotering van enigeen is 'n aparte verandering met sy eie foutmodus. Ontplooiings wat die twee verwar, eindig met 'n kliënt wie se statiese sleutel reg is, wie se sertifikaat verouderd is, en wie se foutboodskap nie een van die twee noem nie.

Die strik daarvan om die subjeknaam te hergebruik

Dit is aanloklik om die voorganger se onderskeidende naam te hergebruik sodat niks stroomaf hoef te verander nie. Dit hou die uitreikerlyn stabiel in die koppelvlak en vernietig die een sein wat jy nodig het. Twee sertifikate met identiese subjekte en verskillende sleutels kan nie by naam onderskei word nie, so 'n bundel met albei ankers gee die valideerder twee kandidate en geen reël om te kies nie.

Die padbou kan dan die verkeerde een kies, ‘kan nie die plaaslike uitreikersertifikaat kry nie’ rapporteer terwyl die korrekte anker teenwoordig is, of op een gasheer slaag en op 'n ander met dieselfde bundel faal, omdat die kandidaatorde verskil het. As die naam hergebruik moet word, hou albei ankers in die oorgang in aparte lêers en laai hulle eksplisiet, en voeg hulle eers saam wanneer elke eweknie die nuwe uitreiker aanbied. Anders gee die vervanging 'n ander algemene naam, 'n generasie- of datumagtervoegsel is genoeg, sodat logs en foutstringe sê onder watter owerheid 'n falende eweknie uitgereik is.

'n Oorskakeling wat nie die netwerk laat val nie

Aanvaar vir 'n beplande vervanging albei ankers vir 'n begrensde venster eerder as om in een stap oor te skakel. Reik die nuwe CA en sy tussenliggende sertifikate uit, plaas die nuwe anker in elke valideerder se bundel langs die ou een, en begin eers daarna eweknie-sertifikate daaruit uitreik. Eweknieë met ou identiteite valideer teen die ou anker; nuwes werk teen die nuwe anker.

In daardie volgorde gedoen, is elke stap omkeerbaar. Die mislukking wat jy vermy, is die gelyktydige oorskakeling, waar 'n kliënt wat die bundelopdatering gemis het, 'n poort ontmoet wat die ou anker al afgetree het, die handdruk sterf, en geen van die twee logs sê watter kant verouderd is nie.

Tree in die teenoorgestelde rigting af. Herreik elke identiteit wat moet oorleef, bevestig dat elkeen die nuwe ketting aanbied, en verwyder dan die ou anker uit die bundels. Neem die ou CA se private sleutel uit diens, want 'n uitreiker wat nog kan onderteken, beteken die oorskakeling is onvoltooid. Hou die sertifikaat- en uitreikingsrekords vir oudit. 'n Verlore uitreiker word na dieselfde vertroue herstel; 'n blootstelling vereis nuwe identiteite en geen terugkeer na die ou anker nie.

Verifieer die uitkoms, nie die lêerlys nie

'n Vertrouenslêer in die verwagte gids bewys min. Die toepassing mag 'n ander pad, 'n ander formaat of 'n kopie in 'n pakket lees wat 'n opgradering vervang. Toets gedrag aan albei kante, nie of 'n lêer bestaan nie.

Bevestig dat 'n vars verbinding met 'n nuwe identiteit slaag, en bevestig dan dat 'n identiteit wat deur die afgetrede CA uitgereik is, geweier word. Daardie tweede toets is die een wat mense oorslaan, en die enigste een wat wys dat die ou owerheid nie meer toegang verleen nie. Waar die ontplooiing op CRL's of OCSP staatmaak, kontroleer dat die verspreidingspunte in die nuwe sertifikate oplos en die responder bereikbaar is van die eweknieë wat dit navraag doen.

Eindig met 'n kliënt wat nog nooit gekoppel het nie: vee sy profieltoestand uit, koppel, en lees die onderhandelde ketting. 'n Eweknie wat 'n gekaste sessie hervat, sal vrolik rapporteer dat die migrasie gewerk het terwyl dit niks gevalideer het nie.