VPN-sertifikaadi uuendamine identiteeti muutmata

Sertifikaadi uuendamine, mis muudab identiteeti, ei ole uuendamine, vaid hoolduspiletit kandev migratsioon. Klient kontrollib nime, ahelat ja mõnikord konkreetset võtit ning kõik kolm võivad muutuda ilma aegumiskuupäeva muutumiseta. Enne asenduse tellimist kirjutage üles, mida klient tegelikult kontrollib: hostinimi või partneri identiteet, sertifikaadi otstarve, võtmepoliitika ja väljaandev ahel. Uuendus on rutiinne või koordineeritud sõltuvalt sellest, millist neist asendus muudab.

Uuenduse kuju otsustavad kolm tingimust

Kolm tingimust on: kas miski kinnitab lehtsertifikaati, kas ahel muutub ja kes veel nime valideerib. Vastake kliendi poolelt, mitte CA mugavusest lähtudes, sest klient on see, mis kell kolm öösel läbi kukub.

Alustage olemasoleva sertifikaadi uurimisest. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName prindib subjekti, väljaandja, kehtivusakna ja nimed, mille jaoks sertifikaat tegelikult kehtib. Viimane väli on kõige olulisem ja kõige sagedamini eeldatud: uuendustaotlus, mis jätab välja SAN-i, millele klient toetub, annab sertifikaadi, mis on tehniliselt kehtiv ja funktsionaalselt vale. Kopeerige SAN-i loend vanalt sertifikaadilt taotlusesse, selle asemel et see mälust uuesti sisestada.

Esimene tingimus: kas miski kinnitab lehtsertifikaati

Kui kliendid usaldavad hooldatavat CA-d ja valideerivad nime, on lehtsertifikaadi uuendamine uue võtmega neile nähtamatu. Kui mõni klient kinnitab lehtsertifikaadi, selle sõrmejälje või selle avaliku võtme, on asendus koordineeritud muutus kõva üleminekuga, sest vana kinnitus ei saa uut sertifikaati valideerida.

Tehke kindlaks, millises olukorras olete, enne kui midagi tellite. Kinnitus, mida keegi ei dokumenteerinud, jääb kinnituseks ka siis, kui see katki läheb.

Teine tingimus: võrrelge kinnitusi ja ahelat

Sõrmejäljed muudavad kinnituse kontrollitavaks: openssl x509 -noout -fingerprint -sha256 -in server.crt vanal ja uuel sertifikaadil, ja openssl x509 -noout -pubkey avalike võtmete võrdlemiseks. Kui kliendi konfiguratsioon, mobiiliprofiil või seadme usaldushoidla sisaldab kumbagi väärtust, on teil kinnitus. Mobiilsed VPN-profiilid on tavaline peidupaik, sest profiil jagatakse üks kord ja seda ei uurita enam kunagi.

Kui asendus pärineb samalt vahesertifikaadilt ja kliendil on see juba olemas või ta saab selle hankida, ei muutu usalduse poolel midagi. Uus vahesertifikaat, teine väljaandja või vales järjekorras edastatud ahel muudavad uuenduse usalduse muutuseks ja rike näeb välja nagu tundmatu väljaandja, mitte nagu aegunud sertifikaat.

Kontrollige ahelat, mille server tegelikult saadab, käsuga openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, ja verifitseerige see lokaalselt käsuga openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Selle tegemine enne muutust annab teile võrdlusaluse hilisemaks võrdlemiseks.

Kolmas tingimus: kes veel nime valideerib

VPN-kontsentraator, koormusjaotur, monitooringusond, RADIUS- või SAML-integratsioon ja mobiiliprofiil võivad igaüks hoida oma koopiat oodatavast nimest või usaldusankrust. Uuendus on hetk, mil need koopiad lahknevad, sest sertifikaat muutub ja koopiad mitte.

Loetlege enne muutust iga tarbija ja otsustage igaühe puhul, kas see vajab uuendamist. See, mille unustate, on see, mis teid välja kutsub.

On ka ajalõks. Uurige kehtivuse algust ja ka aegumist, sest hilisemaks aktiveerimiseks ettevalmistatud sertifikaat lükatakse tagasi, kui see paigaldatakse liiga vara, ja viga näeb välja nagu kellaprobleem, mitte nagu ettevalmistusprobleem. openssl x509 -noout -dates uuel failil enne kasutuselevõttu on kahe sekundi kontroll. Hoidke ka toetatud taasteteed ja teadaolevalt head konfiguratsiooni, et ebaõnnestunud uuenduse saaks tagasi pöörata, taastades eelmise sertifikaadi ja võtme.

Võtke kasutusele, verifitseerige värske autentimisega, seejärel kõrvaldage

Loodud tunnel peegeldab valideerimist, mis toimus selle loomisel, seega võib see paista terve, samal ajal kui iga uus ühendus ebaõnnestub. Testige värske autentimisega, kasutades tegelikku teenusenime, mida kliendid kasutavad.

Lõpetage rakendustasandi kontroll, mis kasutajale oluline on, ja kinnitage ahela kohaletoimetamine kliendi, mitte serveri vaatenurgast. Ärge suruge nime- ega sertifikaadikontrolli maha, et üleminek vaikseks jääks; see muudab ajutise ühilduvusprobleemi püsivaks.

Kõrvaldage vananenud materjal alles pärast kasutuselevõtu verifitseerimist, ja käsitlege kompromiteeritud võtit täiesti erineva juhtumina: uuendamine üksi ei tühista midagi, seega vajab mõjutatud identiteet kasutuselevõtu tühistamis- ja sessioonihaldusprotsessi. RFC 5280 määratleb sertifikaadi- ja teekontrollireeglid, millel kõik see põhineb. Hoidke rutiinne lehtsertifikaadi uuendus CA asendamisest eraldi, et klientidelt ei nõutaks uue väljaandja usaldamist ilma põhjuseta.