Wat bart der as jo in VPN-sertifikaatautoriteit ferfange

In VPN-sertifikaatautoriteit ferfange is gjin bestânsferfanging. Op it stuit dat de nije CA syn earste sertifikaat ûndertekent, moat elke falidearmer dy't noch allinnich de âlde fertrout in beslút nimme, en hosts dy't de nije anker nea krije, bliuwe goede pearen wegerjen. Ik haw it beide kanten misgean sjoen: de gateway learde de nije CA en de kliïnten net, sadat nije ferbiningen mislearren, wylst tunnels dy't al omheech wiene oerein bleaunen en de steuring op in routingprobleem lykje lieten. Hjir is wat feroaret, yn de folchoarder wêryn't de flaters ferskine.

Ien ferfanging, twa aparte feroarings

In sertifikaatautoriteit is in namme, in iepenbiere kaai en de private kaai dy't ûndertekent. Falidearmers fertrouwe nea «de CA» yn it abstrakte. Se fertrouwe ien bepaald sertifikaat dat al yn in fertrouwensopslach sit, en se akseptearje in útjouwer allinnich as in keatling fan ûndertekeningen dat bewarre eksimplaar berikt. It ferfangen fan de CA feroaret dêrom twa dingen dy't ûnôfhinklik mislearje: hokker ankers akseptearre wurde en hokker pear-identiteiten ûnder har útjûn binne.

De measte VPN-útrullingen falidearje yn beide rjochtingen. De kliïnt autentisearret it sertifikaat fan de gateway, en de gateway dat fan de kliïnt. In oergong dy't allinnich it kliïntbondel fernijt, lit de tsjinner elke kliïnt wegerjen dy't noch in identiteit fan de âlde CA presintearret, en it omkearde is like gewoan. Ynventarisearje earst de hanthaveningspunten: fertrouwensopslaggen fan kliïnten, it ca-bestân fan de gateway, elke TLS-beëinigjende proxy derfoar en de probe dy't it einpunt fan bûten kontrolearret.

Wat in falidearmer kontrolearret, yn folchoarder

Paadfalidaasje klimt fan it peersertifikaat troch eventuele tuskenlizzers oant it in fertroud anker berikt. By elke stap ferifiearret it de ûndertekening, kontrolearret dat elk sertifikaat binnen syn jildichheidsfinster leit, en befêstiget dat basisbeheiningen en kaaiberik de útjouwer tastean te ûndertekenjen. Pas dan sjocht de applikaasje nei it bledsertifikaat: de alternative ûnderwerpnammen moatte de oanfrege namme dekke, en it útwreide kaaiberik moat tsjinner- of kliïntautentikaasje tastean.

Om dy kuier offline te werheljen, rjochtsje -CAfile op itselde bondel dat jo útrôlje sille, net op de systeemopslach. Oars testen jo de host, net de feroaring:

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 kommando wurket allinnich tsjin in gewoane TLS-harker lykas de HTTPS-behearspagina fan de gateway; it kontrôlekanaal fan OpenVPN giet foar TLS, sadat s_client de hânskodding fan de tunnel net besjen kin.

De paadboustregels efter dy flaters steane yn RFC 5280 paragraaf 6. Se ferklearje de flaters dy't oars willekeurich lykje: in ferfallen tuskenlizzer dy't nimmen betocht, in sertifikaat wêrfan't it kaaiberik ûndertekenjen ferbiedt, of in nambebeining dy't de host útslút dy't jo testen.

Wêrom't de âlde tunnel trochwurket

TLS en OpenVPN hâlde beide in fêstige sesje libben nei't de hânskodding klear is. Neat falidearret it peersertifikaat opnij per pakket, dus in kliïnt dy't foar de feroaring ferbûn, bliuwt ferkear trochjaan oant it opnij ûnderhannelt, opnij ferbynt of de tunnel falt. Krekt dy kleau makket dat in CA-ferfanging in oere goed lykje kin en dan op it minste stuit mislearret: in laptop wurdt wekker út sliep, in NAT-kaartering ferrint, in gateway start opnij.

Sesjeferfanging rekket de yllúzje fierder op. In TLS-sesjeticket lit in kliïnt weromkomme sûnder sertifikaten opnij te stjoeren, en ferfanging slacht paadfalidaasje oer om't de earste hânskodding it al dien hat. Dat de earlike test is in folsleine hânskodding yn in nij proses. Start de kliïnt opnij ynstee fan de tunnel opnij te ferbinen, en oerweegje op in testprofyl tickets út te setten sadat it ferfangingspaad in brutsen keatling net ferbergje kin.

Hâld de statyske-kaailaach hjirfan apart. tls-auth foeget in HMAC ta oan it kontrôlekanaal, tls-crypt fersiferet en autentisearret it, en gjin fan beide draacht sertifikaatmateriaal, dus rotaasje fan ien fan beide is in aparte feroaring mei eigen flatermodus. Útrullingen dy't de beide trochinoar helje, einigje mei in kliïnt waans statyske kaai goed is, waans sertifikaat ferâldere is en waans flaterberjocht gjin fan beide neamt.

De falstrik fan it werbrûken fan de ûnderwerpn namme

It is ferloklik om de ûnderskiedende namme fan de foargonger wer te brûken sadat neat streamôf feroarje hoecht. Dat hâldt de útjouwersrigel stabyl yn de ynterface en ferneatiget it iene sinjaal dat jo nedich hawwe. Twa sertifikaten mei identike ûnderwerpen en ferskillende kaaien kinne net op namme ûnderskaat wurde, dus in bondel mei beide ankers jout de falidearmer twa kandidaten en gjin regel om te kiezen.

Paadboust kin dan de ferkearde kieze, «kin gjin sertifikaat fan lokale útjouwer krije» melde wylst it goede anker oanwêzich is, of slagje op ien host en mislearje op in oare mei deselde bondel, om't de kandidaatfolchoarder oars wie. As de namme wer brûkt wurde moat, hâld beide ankers yn aparte bestannen yn 'e oergong en laad se eksplisyt, en foegje se pas gear as elk pear de nije útjouwer presintearret. Oars jou it ferfanging in aparte algemiene namme — in generaasje- of datumachterheaksel is genôch — sadat logboeken en flaterteksten sizze ûnder hokker autoriteit in mislearjend pear útjûn is.

In oergong dy't it netwurk net delhellet

Akseptearje foar in plande ferfanging beide ankers foar in beheind finster ynstee fan yn ien stap omskeakelje. Jout de nije CA en syn tuskenlizzers út, set it nije anker by it âlde yn it bondel fan elke falidearmer, en begjin pas dêrnei peersertifikaten derút út te jaan. Pearen mei âlde identiteiten falidearje tsjin it âlde anker; nije wurkje tsjin it nije.

Yn dy folchoarder dien is elke stap omkearber. De flater dy't jo foarkomme is de tagelykse omskeakeling, wêrby't in kliïnt dy't de bondelupdate mist hat in gateway treft dy't it âlde anker al ôfstjitten hat, de hânskodding stjert en gjin fan beide logs seit hokker kant ferâldere is.

Lûk werom yn 'e tsjinoerstelde rjochting. Jou elke identiteit opnij út dy't oerlibje moat, befêstigje dat elk de nije keatling presintearret, en helje dan it âlde anker út 'e bondels. Nim de private kaai fan de âlde CA út tsjinst, want in útjouwer dy't noch ûndertekenje kin betsjuttet dat de oergong net dien is. Bewarje de sertifikaten en útjaanregistraasjes foar audit. In ferlerne útjouwer wurdt wersteld nei itselde fertrouwen; in bleatstelling freget nije identiteiten en gjin weromkommen nei it âlde anker.

Kontrolearje de útslach, net de bestânslijst

In fertrouwensbestân yn 'e ferwachte map bewiist mar in bytsje. De applikaasje kin in oar paad, in oar formaat of in kopy yn in pakket lêze dat in upgrade ferfangt. Kontrolearje gedrach oan beide einen, net oft in bestân bestiet.

Befêstigje dat in nije ferbining mei in nije identiteit slagget, en befêstigje dan dat in identiteit útjûn troch de ôfstjitten CA wegere wurdt. Dy twadde test is dejinge dy't minsken oerslaan, en de iennichste dy't sjen lit dat de âlde autoriteit gjin tagong mear jout. Wêr't de útrulling op CRL of OCSP fertrout, kontrolearje dat de distribúsjepunten yn 'e nije sertifikaten oplosse en dat de beäntwurder berikber is foar de pearen dy't him freegje.

Einigje mei in kliïnt dy't nea ferbûn hat: wiskje syn profylsteat, ferbyn en lês de ûnderhannele keatling. In pear dat in cachet sesje ferfettet, sil fleurich melde dat de migraasje slagge is wylst it neat falidearre hat.