VPN-tanúsítvány megújítása az identitás megváltoztatása nélkül

Az identitást megváltoztató tanúsítvány-megújítás nem megújítás, hanem karbantartási jegyet viselő átköltözés. Az ügyfél ellenőrzi a nevet, a láncot és néha egy adott kulcsot is, és mindhárom megváltozhat anélkül, hogy a lejárati dátum változna. A csere igénylése előtt írja le, mit ellenőriz valójában az ügyfél: a hosztnevet vagy a partner identitását, a tanúsítvány célját, a kulcspolitikát és a kibocsátó láncot. A megújítás rutin vagy összehangolt attól függően, hogy a csere melyiket változtatja meg.

Három feltétel dönti el a megújítás formáját

A három feltétel: rögzít-e bármi a levélhez, változik-e a lánc, és ki más ellenőrzi a nevet. A válaszokat az ügyfél oldaláról adja meg, nem a CA kényelme szerint, mert hajnali háromkor az ügyfél az, ami elakad.

Kezdje a meglévő tanúsítvány vizsgálatával. A openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName kiírja a tárgyat, a kibocsátót, az érvényességi időszakot és azokat a neveket, amelyekre a tanúsítvány ténylegesen érvényes. Az utolsó mező a legfontosabb, és ezt veszik leginkább adottnak: az a megújítási kérelem, amely kihagy egy SAN-t, amelyre az ügyfél támaszkodik, technikailag érvényes, de funkcionálisan hibás tanúsítványt ad. Másolja át a SAN-listát a régi tanúsítványból a kérelembe, ahelyett hogy emlékezetből újra begépelné.

Első feltétel: rögzít-e bármi a levélhez

Ha az ügyfelek egy karbantartott CA-ban bíznak és ellenőrzik a nevet, a levél megújítása új kulccsal láthatatlan számukra. Ha bármely ügyfél rögzíti a levél tanúsítványát, annak ujjlenyomatát vagy nyilvános kulcsát, a csere kemény átállású, összehangolt változás, mert a régi rögzítés nem tudja érvényesíteni az új tanúsítványt.

Tudja meg, melyik esetben van, mielőtt bármit rendel. Egy senki által nem dokumentált rögzítés is rögzítés, amikor eltörik.

Második feltétel: hasonlítsa össze a rögzítéseket és a láncot

Az ujjlenyomatok ellenőrizhetővé teszik a rögzítést: openssl x509 -noout -fingerprint -sha256 -in server.crt a régi és az új tanúsítványon, valamint openssl x509 -noout -pubkey a nyilvános kulcsok összehasonlításához. Ha az ügyfél konfigurációja, egy mobilos profil vagy egy eszköz bizalmi tárolója bármelyik értéket tartalmazza, van rögzítése. A mobilos VPN-profilok gyakori rejtekhelyek, mert a profilt egyszer terjesztik ki, és soha többé nem vizsgálják.

Ha a csere ugyanattól a köztes tanúsítványtól származik, és az ügyfél már rendelkezik ezzel a köztessel, vagy be tudja szerezni, semmi sem változik a bizalom oldalán. Egy új köztes, egy másik kibocsátó vagy a rossz sorrendben átadott lánc a megújítást bizalmi változássá alakítja, és a hiba ismeretlen kibocsátónak látszik, nem lejárt tanúsítványnak.

Ellenőrizze a szerver által ténylegesen küldött láncot a openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts segítségével, és helyben is igazolja a openssl verify -CAfile ca.pem -untrusted chain.pem server.crt segítségével. Ha ezt a változtatás előtt megteszi, lesz viszonyítási alapja a későbbi összehasonlításhoz.

Harmadik feltétel: ki más ellenőrzi a nevet

Egy VPN-koncentrátor, egy terheléselosztó, egy monitorozó próba, egy RADIUS- vagy SAML-integráció és egy mobilos profil mind saját példányt tarthat az elvárt névről vagy a bizalmi horgonyról. A megújítás az a pillanat, amikor ezek a példányok eltérnek, mert a tanúsítvány változik, a példányok pedig nem.

A változtatás előtt sorolja fel az összes fogyasztót, és mindegyiknél döntse el, kell-e frissítés. Amelyiket elfelejti, az fogja hívni.

Van egy időzítési csapda is. Vizsgálja meg az érvényesség kezdetét is a lejárat mellett, mert a későbbi aktiválásra előkészített tanúsítványt elutasítják, ha túl korán telepítik, és a hiba óraproblémának látszik, nem előkészítési problémának. A openssl x509 -noout -dates az új fájlon a telepítés előtt két másodperces ellenőrzés. Tartson fenn támogatott helyreállítási útvonalat és ismert jó konfigurációt is, hogy a félresikerült megújítás visszafordítható legyen az előző tanúsítvány és kulcs visszaállításával.

Telepítse, friss hitelesítéssel igazolja, majd vonja ki

Egy létrejött alagút azt a validálást tükrözi, amely a felépítésekor történt, ezért egészségesnek tűnhet, miközben minden új kapcsolat meghiúsul. Teszteljen friss hitelesítéssel, azzal a tényleges szolgáltatásnévvel, amelyet az ügyfelek használnak.

Végezze el az alkalmazásszintű ellenőrzést, amely az ügyfélnek fontos, és igazolja a lánc átadását az ügyfél szemszögéből, nem a szerveréből. Ne nyomja el a név- vagy tanúsítvány-ellenőrzéseket az átállás csendben tartásáért; azzal egy ideiglenes kompatibilitási problémát állandóvá tesz.

Csak az átvezetés igazolása után vonja ki az elavult anyagokat, és a kompromittált kulcsot teljesen más esetként kezelje: a megújítás önmagában semmit nem von vissza, ezért az érintett identitásnak szüksége van az átvezetés visszavonási és munkamenet-kezelési folyamatára. RFC 5280 határozza meg a tanúsítvány- és útvonal-érvényesítési szabályokat mindezek alatt. Tartsa külön a rutinszerű levélmegújítást a CA cseréjétől, hogy ne kérjék az ügyfeleket arra, hogy ok nélkül bízzanak egy új kibocsátóban.