Křížově podepsaná CA: klíč sedí, vazba AKI ne

Dva certifikáty CA mohou mít stejný veřejný klíč i stejný subjekt, a přesto nejsou zaměnitelné. Jeden je podepsaný sám sebou, druhý křížově podepsal starý kořen, a jejich jména vydavatele, sériová čísla a podpisy se liší. List se může svázat právě s jedním z nich prostřednictvím svého Authority Key Identifier. Tato vazba zůstává neviditelná, dokud klient nezvolí špatný řetěz a handshake neselže bez zjevné příčiny.

Projděte těchto pět kontrol v pořadí: každá vylučuje jiný druh selhání.

Kontrola 1: nakreslete oba řetězy, než se dotknete šablony

Zapište cesty. Stará populace důvěřuje Starému kořeni A, který vydal CA B, která vydala serverový list. Nová populace důvěřuje samopodepsané CA B přímo. Oba certifikáty B nesou stejný klíč a subjekt, a právě proto člověk čtoucí řádek subjektu vidí jednu CA tam, kde klient vidí dvě.

Křížově podepsaná kopie také musí být skutečný certifikát CA, s basic constraints a key usage, které dovolují podepisování.

Kontrola 2: porovnejte pole AKI, ne jen klíč

Jméno vydavatele listu musí odpovídat subjektu B a tato část obvykle platí. Authority Key Identifier je místo, kde se obě kopie rozcházejí, protože může nést identifikátor klíče, vydavatele certifikátu a sériové číslo. Identifikátor klíče odpovídá oběma kopiím, jelikož klíč je totožný. Pole vydavatele a sériového čísla odpovídají přesně jedné, a proto řetěz, který se staví proti samopodepsané kopii, může selhat proti křížově podepsané.

Prohlédněte list místo hádání: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Poté porovnejte oba kandidáty s openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" a stejný příkaz proti samopodepsané kopii.

Pokud list nese vydavatele a sériové číslo, řetěz dokončí jen certifikát, který tyto hodnoty popisují, ať klient načetl kteroukoli kopii.

Kontrola 3: měňte politiku vydávání, nikdy podepsané bajty

Rozšíření žijí uvnitř podpisu. Přidat, odebrat nebo upravit některé na existujícím listu není oprava, je to jiný certifikát a vyžaduje nové vydání. Změna patří do politiky vydávání: authorityKeyIdentifier = keyid,issuer:always způsobí, že nové listy nesou vazbu specifickou pro certifikát, zatímco samotné keyid zachová volnější formu vhodnou pro záměrný přechod na křížové podepisování. Rozhodněte, kterou vaše PKI chce, než se podepíše další dávka.

Úprava sdílené šablony také mění každý budoucí certifikát, nejen server před vámi.

Kontrola 4: ověřte každou populaci důvěry zvlášť

Otestujte starou cestu a novou cestu jako samostatné běhy. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem procvičí křížově podepsanou trasu a stejný příkaz s novým kořenem a bez untrusted souboru procvičí samopodepsanou trasu. Smíchání obou kořenů do jednoho svazku skryje, který řetěz byl vybrán. Poté to zopakujte se skutečnými klienty, protože VPN backend může upřednostnit řetěz nebo připnout certifikát způsoby, které openssl nedělá.

Doručte zprostředkující certifikát konfigurací služby, kterou klient skutečně čte, ne přes wiki stránku.

Kontrola 5: držte starou cestu na hodinách vyřazení

Křížové podepisování drží starou cestu důvěry záměrně živou, což je zároveň smysl i riziko. Neodstraňuje kompromitovaný starý kořen a neodebírá tento kořen žádnému klientovi. Zapište, kdy stará cesta přestane dávat důvěru, a potvrďte, že ten den skutečně nastane.

Pokud každý klient může přijmout nový kořen dřív, než se listy pohnou, prosté zavedení dvojí důvěry je jednodušší než křížové podepisování a nechává o jednu věc méně k vyřazení.