Navzkrižno podpisana CA: ključ se ujema, vezava AKI ne

Dva potrdila CA imata lahko isti javni ključ in isti subject, pa vendar nista zamenljivi. Eno je samopodpisano, drugo je navzkrižno podpisal stari koren, njuna imena izdajatelja, serijske številke in podpisi pa se razlikujejo. List se lahko specifično veže na eno od njiju prek svojega Authority Key Identifier. Ta vezava ostane nevidna, dokler odjemalec ne izbere napačne verige in handshake ne spodleti brez očitnega razloga.

Izvajajte teh pet preverjanj po vrsti: vsako izključi drugačno napako.

Preverjanje 1: narišite obe verigi, preden se dotaknete predloge

Zapišite poti. Stara populacija zaupa Staremu korenu A, ki je izdal CA B, ta pa je izdala list strežnika. Nova populacija zaupa samopodpisani CA B neposredno. Oba potrdila B nosita isti ključ in subject, in prav zato oseba, ki bere vrstico subject, vidi eno CA tam, kjer odjemalec vidi dve.

Navzkrižno podpisana kopija mora biti tudi pravo potrdilo CA, z basic constraints in key usage, ki dovoljujeta podpisovanje.

Preverjanje 2: primerjajte polja AKI, ne le ključa

Ime izdajatelja lista se mora ujemati s subjectom B, in ta del običajno drži. Authority Key Identifier je mesto, kjer se kopiji razideta, ker lahko nosi identifikator ključa, izdajateljevo potrdilo in serijsko številko. Identifikator ključa se ujema z obema kopijama, saj je ključ enak. Polji izdajatelj in serija se ujemata točno z eno, zato lahko veriga, zgrajena proti samopodpisani kopiji, spodleti proti navzkrižno podpisani.

Preglejte list, namesto da ugibate: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Nato primerjajte oba kandidata z openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" in isti ukaz proti samopodpisani kopiji.

Če list nosi izdajatelja in serijsko številko, verigo zaključi samo potrdilo, ki ga ti vrednosti opisujeta, ne glede na to, katero kopijo je odjemalec naložil.

Preverjanje 3: spreminjajte politiko izdajanja, nikoli podpisanih bajtov

Razširitve živijo znotraj podpisa. Dodajanje, odstranjevanje ali urejanje ene na obstoječem listu ni popravilo, to je drugo potrdilo in zahteva ponovno izdajo. Sprememba spada v politiko izdajanja: authorityKeyIdentifier = keyid,issuer:always poskrbi, da novi listi nosijo vezavo, specifično za potrdilo, medtem ko samo keyid ohrani ohlapnejšo obliko, primerno za namerni prehod na navzkrižno podpisovanje. Odločite se, katero želi vaša PKI, preden bo podpisana naslednja serija.

Urejanje deljene predloge spremeni tudi vsako prihodnje potrdilo, ne le strežnika pred vami.

Preverjanje 4: preverite vsako populacijo zaupanja ločeno

Preizkusite staro pot in novo pot kot ločena zagona. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem vadi navzkrižno podpisano pot, isti ukaz z novim korenom in brez untrusted datoteke pa vadi samopodpisano pot. Mešanje obeh korenov v en sveženj skrije, katera veriga je bila izbrana. Nato ponovite z resničnimi odjemalci, ker lahko VPN backend daje prednost verigi ali pripne potrdilo na načine, ki jih openssl ne počne.

Posredujte vmesno potrdilo prek konfiguracije storitve, ki jo odjemalec dejansko bere, ne prek wikija.

Preverjanje 5: držite staro pot na uri upokojitve

Navzkrižno podpisovanje po zasnovi ohranja staro pot zaupanja živo, kar je hkrati namen in tveganje. Ne odpravi kompromitiranega starega korena in tega korena ne odstrani iz nobenega odjemalca. Zapišite, kdaj bo stara pot prenehala dajati zaupanje, in potrdite, da ta dan res pride.

Če lahko vsak odjemalec prevzame novi koren, preden se listi premaknejo, je preprosta uvedba dvojnega zaupanja enostavnejša od navzkrižnega podpisovanja in pusti eno stvar manj za upokojitev.