VPN-varmenteen uusiminen identiteettiä muuttamatta

Varmenteen uusiminen, joka muuttaa identiteettiä, ei ole uusiminen vaan huoltolippuun pukeutunut migraatio. Asiakas varmistaa nimen, ketjun ja joskus tietyn avaimen, ja kaikki kolme voivat muuttua ilman, että vanhenemispäivä muuttuu. Ennen korvaavan varmenteen tilaamista kirjoita ylös, mitä asiakas todella tarkistaa: isäntänimi tai vastapuolen identiteetti, varmenteen käyttötarkoitus, avainkäytäntö ja myöntäjäketju. Uusiminen on rutiinia tai koordinoitua sen mukaan, mitä korvaava varmenne niistä muuttaa.

Kolme ehtoa ratkaisee uusimisen muodon

Kolme ehtoa ovat: kiinnittääkö jokin lehtivarmenteen, muuttuuko ketju ja kuka muu vahvistaa nimen. Vastaa asiakkaan puolelta eikä CA:n mukavuuden perusteella, sillä asiakas on se, joka epäonnistuu kolmelta aamuyöllä.

Aloita tarkistamalla varmenne, joka sinulla on. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName tulostaa subjektin, myöntäjän, voimassaoloikkunan ja nimet, joille varmenne todella on voimassa. Viimeinen kenttä on tärkein ja eniten oletettu: uusimispyyntö, joka jättää pois SAN:n, johon asiakas luottaa, tuottaa varmenteen, joka on teknisesti voimassa ja toiminnallisesti väärä. Kopioi SAN-luettelo vanhasta varmenteesta pyyntöön sen sijaan, että kirjoittaisit sen uudelleen muistista.

Ehto yksi: kiinnittääkö jokin lehtivarmenteen

Jos asiakkaat luottavat ylläpidettyyn CA:han ja vahvistavat nimen, lehtivarmenteen uusiminen uudella avaimella on heille näkymätöntä. Jos jokin asiakas kiinnittää lehtivarmenteen, sen sormenjäljen tai sen julkisen avaimen, korvaaminen on koordinoitu muutos ja kova siirtymä, koska vanha kiinnitys ei voi vahvistaa uutta varmennetta.

Selvitä, missä tapauksessa olet, ennen kuin tilaat mitään. Kiinnitys, jota kukaan ei dokumentoinut, on edelleen kiinnitys, kun se hajoaa.

Ehto kaksi: vertaa kiinnityksiä ja ketjua

Sormenjäljet tekevät kiinnityksestä tarkistettavan: openssl x509 -noout -fingerprint -sha256 -in server.crt vanhalla ja uudella varmenteella, ja openssl x509 -noout -pubkey julkisten avainten vertaamiseen. Jos asiakkaan kokoonpano, mobiiliprofiili tai laitteen luottamusvarasto sisältää jommankumman arvon, sinulla on kiinnitys. Mobiilit VPN-profiilit ovat tavallinen piilopaikka, koska profiili jaetaan kerran eikä sitä koskaan tarkisteta uudelleen.

Jos korvaava varmenne tulee samasta välivarmenteesta ja asiakkaalla on se jo tai hän voi hakea sen, luottamuksen puolella ei muutu mikään. Uusi välivarmenne, eri myöntäjä tai väärässä järjestyksessä toimitettu ketju muuttavat kaikki uusimisen luottamuksen muutokseksi, ja vika näyttää tuntemattomalta myöntäjältä eikä vanhentuneelta varmenteelta.

Tarkista ketju, jonka palvelin todella lähettää, komennolla openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, ja vahvista se paikallisesti komennolla openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Jos teet sen ennen muutosta, sinulla on vertailukohta myöhempää vertailua varten.

Ehto kolme: kuka muu vahvistaa nimen

VPN-keskitin, kuormantasaaja, valvonta-anturi, RADIUS- tai SAML-integraatio ja mobiiliprofiili voivat kukin pitää omaa kopiotaan odotetusta nimestä tai luottamusanchorista. Uusiminen on hetki, jolloin nämä kopiot erkanevat, koska varmenne muuttuu eivätkä kopiot.

Listaa jokainen kuluttaja ennen muutosta ja päätä kunkin kohdalla, tarvitseeko se päivityksen. Se, jonka unohdat, on se, joka hälyttää sinut.

On myös ajoitushoukutus. Tarkista voimassaolon alku yhtä hyvin kuin vanheneminen, koska myöhempään aktivointiin valmisteltu varmenne hylätään, jos se asennetaan liian aikaisin, ja virhe näyttää kello-ongelmalta eikä valmisteluongelmalta. openssl x509 -noout -dates uudella tiedostolla ennen käyttöönottoa on kahden sekunnin tarkistus. Pidä myös tuettu palautuspolku ja tiedossa oleva hyvä kokoonpano, jotta pieleen mennyt uusiminen voidaan perua palauttamalla edellinen varmenne ja avain.

Ota käyttöön, vahvista tuoreella todennuksella ja poista sitten käytöstä

Muodostettu tunneli heijastaa sitä vahvistusta, joka tapahtui sitä rakennettaessa, joten se voi näyttää terveeltä, vaikka jokainen uusi yhteys epäonnistuu. Testaa tuoreella todennuksella käyttäen todellista palvelunimeä, jota asiakkaat käyttävät.

Suorita loppuun sovellustason tarkistus, joka käyttäjälle on tärkeä, ja vahvista ketjun toimitus asiakkaan näkökulmasta eikä palvelimen. Älä vaienna nimi- tai varmennetarkistuksia, jotta siirtymä pysyisi hiljaisena; se muuttaa tilapäisen yhteensopivuusongelman pysyväksi.

Poista vanhentunut materiaali käytöstä vasta, kun käyttöönotto on vahvistettu, ja käsittele vaarantunutta avainta täysin eri tapauksena: uusiminen yksin ei peruuta mitään, joten vaikutuksen kohteena oleva identiteetti tarvitsee käyttöönoton peruutus- ja istunnonhallintaprosessin. RFC 5280 määrittelee varmenne- ja polunvahvistussäännöt, joihin kaikki tämä perustuu. Pidä rutiininomainen lehtivarmenteen uusiminen erillään CA:n korvaamisesta, jotta asiakkailta ei vaadita uuteen myöntäjään luottamista ilman syytä.