Kryžminiu būdu pasirašyta CA: raktas sutampa, AKI susiejimas ne

Du CA sertifikatai gali turėti tą patį viešąjį raktą ir tą patį subject ir vis tiek nebūti keičiami. Vienas yra pasirašytas pats save, kitas kryžminiu būdu pasirašytas senosios šaknies, o jų išdavėjų vardai, serijos numeriai ir parašai skiriasi. Lapas gali susieti būtent su vienu iš jų per savo Authority Key Identifier. Tas susiejimas lieka nematomas, kol klientas pasirenka netinkamą grandinę ir handshake nepavyksta be aiškios priežasties.

Atlikite šiuos penkis patikrinimus iš eilės: kiekvienas pašalina skirtingą gedimą.

Patikrinimas 1: nubrėžkite abi grandines prieš liesdami šabloną

Užrašykite kelius. Sena populiacija pasitiki Sena šaknimi A, kuri išdavė CA B, kuri išdavė serverio lapą. Nauja populiacija pasitiki savimi pasirašyta CA B tiesiogiai. Abu B sertifikatai turi tą patį raktą ir subject, ir būtent todėl žmogus, skaitantis subject eilutę, mato vieną CA ten, kur klientas mato du.

Kryžminiu būdu pasirašyta kopija taip pat turi būti tikras CA sertifikatas su basic constraints ir key usage, leidžiančiais pasirašyti.

Patikrinimas 2: palyginkite AKI laukus, o ne tik raktą

Lapo išdavėjo vardas turi atitikti B subject, ir ši dalis paprastai galioja. Authority Key Identifier yra vieta, kur dvi kopijos išsiskiria, nes jis gali turėti raktų identifikatorių, išdavėjo sertifikatą ir serijos numerį. Raktų identifikatorius atitinka abi kopijas, nes raktas identiškas. Išdavėjo ir serijos laukai atitinka tiksliai vieną, todėl grandinė, statoma prieš savimi pasirašytą kopiją, gali nepavykti prieš kryžminiu būdu pasirašytą.

Tikrinkite lapą, o ne spėliokite: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Tada palyginkite abu kandidatus su openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", ir tą pačią komandą prieš savimi pasirašytą kopiją.

Jei lapas turi išdavėją ir serijos numerį, grandinę užbaigia tik tas sertifikatas, kurį aprašo šios reikšmės, nesvarbu, kurią kopiją klientas įkėlė.

Patikrinimas 3: keiskite išdavimo politiką, niekada pasirašytų baitų

Plėtiniai gyvena parašo viduje. Vieno pridėjimas, pašalinimas ar redagavimas esamame lape nėra taisymas, tai kitas sertifikatas, ir jam reikia išdavimo iš naujo. Pakeitimas priklauso išdavimo politikai: authorityKeyIdentifier = keyid,issuer:always leidžia naujiems lapams turėti sertifikatui būdingą susiejimą, o vien keyid išlaiko laisvesnę formą, tinkančią sąmoningam kryžminio pasirašymo perėjimui. Nuspręskite, kurio nori jūsų PKI, prieš pasirašant kitą partiją.

Bendro šablono redagavimas keičia ir kiekvieną būsimą sertifikatą, ne tik serverį priešais jus.

Patikrinimas 4: patikrinkite kiekvieną pasitikėjimo populiaciją atskirai

Išbandykite seną kelią ir naują kelią kaip atskirus paleidimus. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem praktikuoja kryžminiu būdu pasirašytą maršrutą, o ta pati komanda su nauja šaknimi ir be untrusted failo praktikuoja savimi pasirašytą maršrutą. Abiejų šaknų sumaišymas viename pakete paslepia, kuri grandinė buvo pasirinkta. Po to pakartokite su tikrais klientais, nes VPN backend gali teikti pirmenybę grandinei arba prisegti sertifikatą būdais, kurių openssl nedaro.

Pristatykite tarpinį sertifikatą per paslaugos konfigūraciją, kurią klientas iš tikrųjų skaito, o ne per wiki puslapį.

Patikrinimas 5: laikykite seną kelią eksploatavimo nutraukimo laikrodyje

Kryžminis pasirašymas pagal projektą palaiko seną pasitikėjimo kelią gyvą, ir tai yra ir tikslas, ir rizika. Jis neištaiso pažeistos senos šaknies ir nepašalina tos šaknies iš jokio kliento. Užrašykite, kada senas kelias nustos duoti pasitikėjimą, ir patvirtinkite, kad ta diena tikrai ateis.

Jei kiekvienas klientas gali priimti naują šaknį prieš lapams judant, paprastas dvigubo pasitikėjimo diegimas yra paprastesnis nei kryžminis pasirašymas ir palieka vienu dalyku mažiau nutraukti.