Obnova potrdila VPN brez spreminjanja njegove identitete

Obnova potrdila, ki spremeni identiteto, ni obnova, to je selitev v delovni nalog za vzdrževanje. Odjemalec preveri ime, verigo in včasih določen ključ, vsi trije pa se lahko spremenijo brez spremembe datuma poteka. Preden zahtevate zamenjavo, zapišite, kaj odjemalec v resnici preverja: ime gostitelja ali identiteto partnerja, namen potrdila, politiko ključev in izdajateljsko verigo. Obnova je rutinska ali usklajena glede na to, kaj od tega zamenjava spremeni.

Trije pogoji odločijo o obliki obnove

Trije pogoji so: ali kaj pripne list, ali se veriga spremeni in kdo še preverja ime. Odgovorite z odjemalčeve strani in ne zaradi udobja CA, ker odjemalec je tisti, ki odpove ob treh zjutraj.

Začnite s pregledom potrdila, ki ga imate. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName izpiše subjekt, izdajatelja, okno veljavnosti in imena, za katera je potrdilo res veljavno. Zadnje polje je najpomembnejše in najpogosteje predpostavljeno: zahteva za obnovo, ki izpusti SAN, na katerega se odjemalec zanaša, ustvari potrdilo, ki je tehnično veljavno, a funkcionalno napačno. Kopirajte seznam SAN iz starega potrdila v zahtevo, namesto da bi ga znova vtipkali po spominu.

Prvi pogoj: ali kaj pripne list

Če odjemalci zaupajo vzdrževanemu CA in preverjajo ime, je obnova lista z novim ključem zanje nevidna. Če kateri koli odjemalec pripne potrdilo lista, njegov odtis ali njegov javni ključ, je zamenjava usklajena sprememba s trdim prehodom, ker staro pripetje ne more preveriti novega potrdila.

Ugotovite, v katerem primeru ste, preden kar koli naročite. Pripetje, ki ga nihče ni dokumentiral, je še vedno pripetje, ko se zlomi.

Drugi pogoj: primerjajte pripetja in verigo

Odtisi naredijo pripetje preverljivo: openssl x509 -noout -fingerprint -sha256 -in server.crt na starem in novem potrdilu ter openssl x509 -noout -pubkey za primerjavo javnih ključev. Če konfiguracija odjemalca, mobilni profil ali shramba zaupanja naprave vsebuje katero od vrednosti, imate pripetje. Mobilni profili VPN so pogosto skrivališče, ker se profil razdeli enkrat in se nikoli več ne pregleda.

Če zamenjava pride iz istega vmesnega in ga odjemalec že ima ali ga lahko pridobi, se na strani zaupanja nič ne spremeni. Nov vmesni, drug izdajatelj ali veriga, dostavljena v napačnem vrstnem redu, spremenijo obnovo v spremembo zaupanja in napaka je videti kot neznan izdajatelj, ne kot poteklo potrdilo.

Preverite verigo, ki jo strežnik dejansko pošlje, z openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts in jo potrdite lokalno z openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Če to storite pred spremembo, dobite osnovno črto za poznejšo primerjavo.

Tretji pogoj: kdo še preverja ime

Koncentrator VPN, razporejevalnik obremenitve, nadzorna sonda, integracija RADIUS ali SAML in mobilni profil lahko vsak hrani svojo kopijo pričakovanega imena ali sidra zaupanja. Obnova je trenutek, ko se te kopije razhajajo, ker se potrdilo spremeni, kopije pa ne.

Pred spremembo naštejte vsakega porabnika in za vsakega odločite, ali potrebuje posodobitev. Tisti, ki ga pozabite, je tisti, ki vas pokliče.

Obstaja tudi časovna past. Preverite začetek veljavnosti in potek, ker je potrdilo, pripravljeno za poznejšo aktivacijo, zavrnjeno, če je nameščeno prezgodaj, in napaka je videti kot težava z uro, ne kot težava s pripravo. openssl x509 -noout -dates na novi datoteki pred namestitvijo je dvosekundni pregled. Ohranite tudi podprto pot obnovitve in znano dobro konfiguracijo, da je neuspešno obnovo mogoče razveljaviti z obnovitvijo prejšnjega potrdila in ključa.

Namestite, preverite s svežo avtentikacijo in nato umaknite

Vzpostavljen tunel odraža preverjanje, ki se je zgodilo ob gradnji, zato je lahko videti zdrav, medtem ko vsaka nova povezava spodleti. Preizkusite s svežo avtentikacijo z dejanskim imenom storitve, ki ga uporabljajo odjemalci.

Dokončajte preverjanje na ravni aplikacije, ki je uporabniku pomembno, in potrdite dostavo verige z vidika odjemalca, ne strežnika. Ne zatirajte preverjanj imena ali potrdila, da bi prehod ostal tih; to spremeni začasno težavo s združljivostjo v trajno.

Zastarel material umaknite šele po tem, ko je namestitev preverjena, kompromitirani ključ pa obravnavajte kot povsem drug primer: obnova sama po sebi ničesar ne prekliče, zato prizadeta identiteta potrebuje postopek preklica in upravljanja sej te namestitve. RFC 5280 opredeljuje pravila potrdil in preverjanja poti, na katerih stoji vse to. Rutinsko obnovo lista hranite ločeno od zamenjave CA, da od odjemalcev ne bi zahtevali zaupanja novemu izdajatelju brez razloga.