Šķērssertificēta CA: atslēga sakrīt, AKI saistījums ne

Divi CA sertifikāti var saturēt vienu un to pašu publisko atslēgu un vienu un to pašu subject, un tomēr nebūt aizvietojami. Viens ir pašparakstīts, otrs ir šķērssertificēts ar veco sakni, un to izdevēju nosaukumi, sērijas numuri un paraksti atšķiras. Lapa var saistīties tieši ar vienu no tiem, izmantojot tās Authority Key Identifier. Šis saistījums paliek neredzams, līdz klients izvēlas nepareizo ķēdi un handshake neizdodas bez acīmredzama iemesla.

Veiciet šīs piecas pārbaudes pēc kārtas: katra izslēdz citu kļūmi.

Pārbaude 1: uzzīmējiet abas ķēdes, pirms pieskaraties veidnei

Pierakstiet ceļus. Vecā populācija uzticas Vecajai saknei A, kas izdeva CA B, kas izdeva servera lapu. Jaunā populācija uzticas pašparakstītajai CA B tieši. Abi B sertifikāti satur vienu un to pašu atslēgu un subject, un tieši tāpēc cilvēks, kas lasa subject rindu, redz vienu CA tur, kur klients redz divus.

Šķērssertificētajai kopijai arī jābūt īstam CA sertifikātam ar basic constraints un key usage, kas pieļauj parakstīšanu.

Pārbaude 2: salīdziniet AKI laukus, ne tikai atslēgu

Lapas izdevēja nosaukumam jāatbilst B subject, un šī daļa parasti iztur. Authority Key Identifier ir vieta, kur abas kopijas atšķiras, jo tas var saturēt atslēgas identifikatoru, izdevēja sertifikātu un sērijas numuru. Atslēgas identifikators atbilst abām kopijām, jo atslēga ir identiska. Izdevēja un sērijas lauki atbilst tieši vienai, un tāpēc ķēde, kas veidota pret pašparakstīto kopiju, var neizdoties pret šķērssertificēto.

Pārbaudiet lapu, nevis miniet: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Pēc tam salīdziniet abus kandidātus ar openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", un to pašu komandu pret pašparakstīto kopiju.

Ja lapa satur izdevēju un sērijas numuru, ķēdi pabeidz tikai tas sertifikāts, ko apraksta šīs vērtības, lai kuru kopiju klients būtu ielādējis.

Pārbaude 3: mainiet izsniegšanas politiku, nekad parakstītos baitus

Paplašinājumi dzīvo paraksta iekšienē. Viena pievienošana, noņemšana vai rediģēšana esošā lapā nav labojums, tas ir cits sertifikāts, un tam vajadzīga atkārtota izsniegšana. Izmaiņa pieder izsniegšanas politikai: authorityKeyIdentifier = keyid,issuer:always liek jaunajām lapām saturēt sertifikātam raksturīgo saistījumu, bet keyid viens pats saglabā brīvāko formu, kas piemērota apzinātai šķērssertificēšanas pārejai. Izlemiet, kuru vēlas jūsu PKI, pirms tiek parakstīta nākamā partija.

Kopīgas veidnes rediģēšana maina arī katru nākamo sertifikātu, ne tikai serveri jums priekšā.

Pārbaude 4: pārbaudiet katru uzticības populāciju atsevišķi

Pārbaudiet veco ceļu un jauno ceļu kā atsevišķus palaidienus. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem trenē šķērssertificēto maršrutu, un tā pati komanda ar jauno sakni un bez untrusted faila trenē pašparakstīto maršrutu. Abu sakņu sajaukšana vienā komplektā noslēpj, kura ķēde tika izvēlēta. Pēc tam atkārtojiet ar īstiem klientiem, jo VPN backend var dot priekšroku ķēdei vai piespraust sertifikātu veidos, kādos openssl to nedara.

Piegādājiet starpposma sertifikātu caur pakalpojuma konfigurāciju, ko klients patiešām lasa, nevis caur wiki lapu.

Pārbaude 5: turiet veco ceļu ekspluatācijas pārtraukšanas pulkstenī

Šķērssertificēšana pēc projekta uztur veco uzticības ceļu dzīvu, un tas ir gan mērķis, gan risks. Tā nelabo apdraudētu veco sakni un neizņem to sakni no neviena klienta. Pierakstiet, kad vecais ceļš pārstās dot uzticību, un apstipriniet, ka tā diena patiešām pienāk.

Ja katrs klients var pieņemt jauno sakni, pirms lapas pārvietojas, vienkārša divkāršas uzticības ieviešana ir vienkāršāka par šķērssertificēšanu, un atstāj par vienu lietu mazāk, kas jāpārtrauc.