Mitä tapahtuu, kun vaihdat VPN-varmenteiden myöntäjän

VPN-varmenteiden myöntäjän vaihtaminen ei ole tiedoston vaihtamista. Hetkellä, jolloin uusi CA allekirjoittaa ensimmäisen varmenteensa, jokaisen validaattorin, joka luottaa edelleen vain vanhaan, on tehtävä päätös, ja isännät, jotka eivät koskaan saa uutta ankkuria, hylkäävät edelleen hyviä vertaisia. Olen nähnyt sen menevän pieleen molempiin suuntiin: yhdyskäytävä oppi uuden CA:n eivätkä asiakkaat, joten uudet yhteydet epäonnistuivat, kun taas jo pystyssä olleet tunnelit pysyivät pystyssä ja saivat katkoksen näyttämään reititysongelmalta. Tässä on, mikä muuttuu, siinä järjestyksessä kuin viat ilmenevät.

Yksi vaihto, kaksi erillistä muutosta

Varmenteiden myöntäjä on nimi, julkinen avain ja yksityinen avain, joka allekirjoittaa. Validaattorit eivät koskaan luota ”CA:han” abstraktisti. Ne luottavat yhteen tiettyyn varmenteeseen, joka on jo luottamusvarastossa, ja hyväksyvät myöntäjän vain, jos allekirjoitusketju yltää siihen tallennettuun kopioon. Siksi CA:n vaihtaminen muuttaa kahta asiaa, jotka epäonnistuvat toisistaan riippumatta: mitkä ankkurit hyväksytään ja mitkä vertaisidentiteetit on myönnetty niiden alla.

Useimmat VPN-käyttöönotot validoivat molempiin suuntiin. Asiakas todentaa yhdyskäytävän varmenteen ja yhdyskäytävä asiakkaan varmenteen. Vaihto, joka päivittää vain asiakaspaketin, jättää palvelimen hylkäämään jokaisen asiakkaan, joka esittää yhä vanhan CA:n identiteettiä, ja päinvastainen on yhtä yleistä. Luetteloi ensin valvontapisteet: asiakkaiden luottamusvarastot, yhdyskäytävän ca-tiedosto, mikä tahansa sitä edeltävä TLS:n päättävä välityspalvelin ja päätepisteen ulkopuolelta tarkistava anturi.

Mitä validaattori tarkistaa, järjestyksessä

Polun validointi kiipeää vertaisvarmenteesta välivarmenteiden kautta, kunnes se saavuttaa luotetun ankkurin. Jokaisella askeleella se tarkistaa allekirjoituksen, varmistaa että jokainen varmenne on voimassaoloikkunassaan, ja vahvistaa, että perusrajoitukset ja avaimen käyttö sallivat myöntäjän allekirjoittaa. Vasta sitten sovellus katsoo lehtivarmennetta: subjektin vaihtoehtoisten nimien on katettava valittu nimi, ja laajennetun avaimen käytön on sallittava palvelimen tai asiakkaan todennus.

Toistaaksesi tuon kulun offline-tilassa, osoita -CAfile täsmälleen siihen pakettiin, jonka otat käyttöön, älä järjestelmän varastoon. Muuten testaat isäntää, et muutosta:

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

Tuo komento toimii vain tavallista TLS-kuuntelijaa vasten, kuten yhdyskäytävän HTTPS-hallintasivua; OpenVPN:n ohjauskanava edeltää TLS:ää, joten s_client ei voi tarkastella tunnelin kättelyä.

Näiden virheiden takana olevat polunrakennussäännöt ovat kohdassa RFC 5280 luku 6. Ne selittävät epäonnistumiset, jotka muuten näyttävät mielivaltaisilta: vanhentunut välivarmenne, jota kukaan ei muistanut, varmenne jonka avaimen käyttö kieltää allekirjoittamisen, tai nimirajoitus, joka sulkee pois testattavan isännän.

Miksi vanha tunneli jatkaa toimintaansa

TLS ja OpenVPN pitävät molemmat muodostetun istunnon elossa kättelyn päätyttyä. Mikään ei validoi vertaisvarmennetta uudelleen pakettia kohden, joten ennen muutosta yhteyden muodostanut asiakas välittää liikennettä, kunnes se neuvottelee uudelleen, yhdistää uudelleen tai tunneli putoaa. Juuri tämä aukko saa CA:n vaihdon näyttämään tunnin ajan hyvältä ja sitten epäonnistumaan pahimmalla hetkellä: kannettava herää unitilasta, NAT-määritys vanhenee, yhdyskäytävä käynnistyy uudelleen.

Istunnon jatkaminen venyttää illuusiota pidemmälle. TLS-istuntolippu sallii asiakkaan palata lähettämättä varmenteita uudelleen, ja jatkaminen ohittaa polun validoinnin, koska ensimmäinen kättely teki sen jo. Rehellinen testi on siis täysi kättely uudessa prosessissa. Käynnistä asiakas uudelleen sen sijaan, että yhdistäisit tunnelin uudelleen, ja harkitse testiprofiilissa lippujen poistamista käytöstä, jotta jatkamispolku ei voi piilottaa rikkinäistä ketjua.

Pidä staattisen avaimen kerros tästä erillään. tls-auth lisää HMAC:n ohjauskanavaan, tls-crypt salaa ja todentaa sen, eikä kumpikaan kanna varmennemateriaalia, joten kummankaan vaihtaminen on erillinen muutos omalla vikatilallaan. Käyttöönotot, jotka sekoittavat nämä kaksi, päätyvät asiakkaaseen, jonka staattinen avain on kunnossa, varmenne vanhentunut eikä virheilmoitus mainitse kumpaakaan.

Subjektin nimen uudelleenkäytön ansa

On houkuttelevaa käyttää uudelleen edeltäjän erottuvaa nimeä, jotta mikään alavirrassa ei joudu muuttumaan. Se pitää myöntäjän rivin vakaana käyttöliittymässä ja tuhoaa ainoan signaalin, jonka tarvitset. Kahta varmennetta, joilla on samat subjektit ja eri avaimet, ei voi erottaa nimen perusteella, joten molemmat ankkurit sisältävä paketti antaa validaattorille kaksi ehdokasta eikä mitään valintasääntöä.

Polunrakennus voi silloin valita väärän, raportoida ”paikallisen myöntäjän varmennetta ei saada”, vaikka oikea ankkuri on läsnä, tai onnistua yhdellä isännällä ja epäonnistua toisella samalla paketilla, koska ehdokkaiden järjestys erosi. Jos nimi on pakko käyttää uudelleen, pidä molemmat ankkurit erillisissä tiedostoissa siirtymän ajan ja lataa ne eksplisiittisesti, ja yhdistä ne vasta kun jokainen vertais esittää uuden myöntäjän. Muussa tapauksessa anna korvaajalle erillinen yleisnimi — sukupolvi- tai päivämääräliite riittää — jotta lokit ja virhetekstit kertovat, minkä viranomaisen alla epäonnistuva vertais on myönnetty.

Vaihto, joka ei kaada verkkoa

Suunniteltua vaihtoa varten hyväksy molemmat ankkurit rajatun ajan, sen sijaan että kytkisit yhdellä askeleella. Myönnä uusi CA ja sen välivarmenteet, aseta uusi ankkuri jokaisen validaattorin pakettiin vanhan viereen ja aloita vasta sitten vertaisvarmenteiden myöntäminen siitä. Vanhat identiteetit omaavat vertaiset validoituvat vanhaa ankkuria vasten; uudet toimivat uutta vasten.

Tässä järjestyksessä tehtynä jokainen askel on peruttavissa. Vika, jota vältät, on samanaikainen kytkentä: asiakas, joka missasi paketin päivityksen, kohtaa yhdyskäytävän, joka on jo poistanut vanhan ankkurin, kättely kuolee, eikä kumpikaan loki kerro, kumpi puoli on vanhentunut.

Poista käytöstä vastakkaiseen suuntaan. Myönnä uudelleen jokainen identiteetti, jonka on selvittävä, vahvista että jokainen esittää uuden ketjun, ja poista sitten vanha ankkuri paketeista. Poista vanhan CA:n yksityinen avain käytöstä, sillä myöntäjä, joka voi yhä allekirjoittaa, tarkoittaa että vaihto on kesken. Säilytä varmenteet ja myöntötiedot auditointia varten. Kadonnut myöntäjä palautetaan samaan luottamukseen; paljastuminen vaatii uudet identiteetit eikä paluuta vanhaan ankkuriin.

Tarkista tulos, ei tiedostoluetteloa

Luottamustiedosto odotetussa hakemistossa todistaa vähän. Sovellus voi lukea toisen polun, toisen muodon tai kopion paketissa, jonka päivitys korvaa. Tarkista käyttäytyminen molemmissa päissä, ei tiedoston olemassaoloa.

Vahvista, että uusi yhteys uudella identiteetillä onnistuu, ja vahvista sitten, että käytöstä poistetun CA:n myöntämä identiteetti hylätään. Tuo toinen testi on se, jonka ihmiset ohittavat, ja ainoa, joka osoittaa, ettei vanha viranomainen enää anna pääsyä. Jos käyttöönotto nojaa CRL:ään tai OCSP:hen, tarkista että uusien varmenteiden jakelupisteet ratkeavat ja että vastaaja on kysyvien vertaisten tavoitettavissa.

Lopeta asiakkaaseen, joka ei ole koskaan yhdistänyt: pyyhi sen profiilin tila, yhdistä ja lue neuvoteltu ketju. Välimuistiin tallennetun istunnon jatkava vertais kertoo iloisesti, että siirto onnistui, vaikka se ei validoinut mitään.