Ristallkirjastatud CA: võti klapib, AKI seos mitte

Kaks CA-sertifikaati võivad kanda sama avalikku võtit ja sama subjekti ning olla ikkagi mitte vahetatavad. Üks on iseallkirjastatud, teise on ristallkirjastanud vana juur, ning nende väljaandja nimed, seerianumbrid ja allkirjad erinevad. Leht saab siduda end konkreetselt ühega neist oma Authority Key Identifieri kaudu. See seos jääb nähtamatuks seni, kuni klient valib vale ahela ja handshake ebaõnnestub ilma nähtava põhjuseta.

Tehke need viis kontrolli järjekorras: igaüks välistab erineva tõrke.

Kontroll 1: joonistage mõlemad ahelad enne mallile käe panemist

Kirjutage teed üles. Vana populatsioon usaldab Vana juurt A, mis andis välja CA B, mis andis välja serveri lehe. Uus populatsioon usaldab iseallkirjastatud CA B-d otse. Mõlemad B-sertifikaadid kannavad sama võtit ja subjekti, mistõttu subjekti rida lugev inimene näeb ühte CA-d seal, kus klient näeb kahte.

Ristallkirjastatud koopia peab samuti olema ehtne CA-sertifikaat, millel on basic constraints ja key usage, mis lubavad allkirjastada.

Kontroll 2: võrrelge AKI välju, mitte ainult võtit

Lehe väljaandja nimi peab vastama B subjektile ja see osa tavaliselt kehtib. Authority Key Identifier on koht, kus kaks koopiat lahknevad, sest see võib kanda võtme identifikaatorit, väljaandja sertifikaati ja seerianumbrit. Võtme identifikaator vastab mõlemale koopiale, kuna võti on identne. Väljaandja ja seerianumbri väljad vastavad täpselt ühele, mistõttu iseallkirjastatud koopia vastu ehitatud ahel võib ristallkirjastatud koopia vastu ebaõnnestuda.

Uurige lehte selle asemel, et oletada: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Seejärel võrrelge mõlemat kandidaati käsuga openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" ja sama käsku iseallkirjastatud koopia vastu.

Kui leht kannab väljaandjat ja seerianumbrit, lõpetab ahela ainult see sertifikaat, mida need väärtused kirjeldavad, ükskõik millise koopia klient laadis.

Kontroll 3: muutke väljaandmispoliitikat, mitte kunagi allkirjastatud baite

Laiendused elavad allkirja sees. Ühe lisamine, eemaldamine või muutmine olemasoleval lehel ei ole parandus, see on teine sertifikaat ja nõuab uuesti väljaandmist. Muudatus kuulub väljaandmispoliitikasse: authorityKeyIdentifier = keyid,issuer:always paneb uued lehed kandma sertifikaadipõhist seost, samas kui üksi keyid hoiab lõdvemat vormi, mis sobib teadliku ristallkirjastamise ülemineku jaoks. Otsustage, millist teie PKI tahab, enne kui järgmine partii allkirjastatakse.

Jagatud malli muutmine muudab ka iga tulevast sertifikaati, mitte ainult teie ees olevat serverit.

Kontroll 4: kontrollige iga usalduspopulatsiooni eraldi

Testige vana teed ja uut teed eraldi jooksudena. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem harjutab ristallkirjastatud marsruuti ja sama käsk uue juurega ning ilma untrusted-failita harjutab iseallkirjastatud marsruuti. Mõlema juure segamine ühte kimpu varjab, milline ahel valiti. Korrake seejärel päris klientidega, sest VPN-taust võib eelistada ahelat või sertifikaati kinnitada viisidel, mida openssl ei tee.

Toimetage vahesertifikaat kohale teenusekonfiguratsiooni kaudu, mida klient tegelikult loeb, mitte wiki lehe kaudu.

Kontroll 5: hoidke vana teed kasutuselt kõrvaldamise kellal

Ristallkirjastamine hoiab vana usaldustee projekteeritult elus, mis on ühtaegu mõte ja risk. See ei kõrvalda kompromiteeritud vana juurt ega eemalda seda juurt ühestki kliendist. Kirjutage üles, millal vana tee enam usaldust ei anna, ja kinnitage, et see päev tõesti saabub.

Kui iga klient suudab uue juure vastu võtta enne, kui lehed liiguvad, on tavaline kahekordse usalduse kasutuselevõtt lihtsam kui ristallkirjastamine ja jätab ühe asja vähem kasutuselt kõrvaldada.