Dva certifikáty CA môžu mať rovnaký verejný kľúč a rovnaký subject a napriek tomu nie sú zameniteľné. Jeden je podpísaný sám sebou, druhý krížovo podpísal starý koreň, a ich mená vydavateľa, sériové čísla a podpisy sa líšia. List sa môže viazať práve na jeden z nich prostredníctvom svojho Authority Key Identifier. Táto väzba zostáva neviditeľná, kým klient nezvolí nesprávny reťazec a handshake nezlyhá bez zjavnej príčiny.

Prejdite týchto päť kontrol v poradí: každá vylučuje iný druh zlyhania.

Kontrola 1: nakreslite oba reťazce, než sa dotknete šablóny

Zapíšte cesty. Stará populácia dôveruje Starému koreňu A, ktorý vydal CA B, ktorá vydala list servera. Nová populácia dôveruje samopodpísanej CA B priamo. Oba certifikáty B nesú rovnaký kľúč a subject, a práve preto človek čítajúci riadok subject vidí jednu CA tam, kde klient vidí dve.

Krížovo podpísaná kópia tiež musí byť skutočný certifikát CA, s basic constraints a key usage, ktoré dovoľujú podpisovať.

Kontrola 2: porovnajte polia AKI, nie iba kľúč

Meno vydavateľa listu musí zodpovedať subjectu B, a táto časť zvyčajne platí. Authority Key Identifier je miesto, kde sa obe kópie rozchádzajú, pretože môže niesť identifikátor kľúča, vydavateľa certifikátu a sériové číslo. Identifikátor kľúča zodpovedá obom kópiám, keďže kľúč je identický. Polia vydavateľ a séria zodpovedajú presne jednej, a preto reťazec stavaný proti samopodpísanej kópii môže zlyhať proti krížovo podpísanej.

Preskúmajte list namiesto hádania: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Potom porovnajte oboch kandidátov pomocou openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" a ten istý príkaz proti samopodpísanej kópii.

Ak list nesie vydavateľa a sériové číslo, reťazec dokončí iba certifikát, ktorý tieto hodnoty opisujú, ktorúkoľvek kópiu klient načítal.

Kontrola 3: meňte politiku vydávania, nikdy podpísané bajty

Rozšírenia žijú vnútri podpisu. Pridať, odobrať alebo upraviť jedno na existujúcom liste nie je oprava, je to iný certifikát a vyžaduje nové vydanie. Zmena patrí do politiky vydávania: authorityKeyIdentifier = keyid,issuer:always spôsobí, že nové listy nesú väzbu špecifickú pre certifikát, zatiaľ čo samotné keyid zachová voľnejšiu formu vhodnú pre úmyselný prechod na krížové podpisovanie. Rozhodnite, ktorú vaša PKI chce, než sa podpíše ďalšia dávka.

Úprava zdieľanej šablóny mení aj každý budúci certifikát, nielen server pred vami.

Kontrola 4: overte každú populáciu dôvery osobitne

Otestujte starú cestu a novú cestu ako samostatné behy. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem precvičuje krížovo podpísanú trasu a ten istý príkaz s novým koreňom a bez untrusted súboru precvičuje samopodpísanú trasu. Zmiešanie oboch koreňov v jednom balíku skryje, ktorý reťazec bol vybraný. Potom to zopakujte so skutočnými klientmi, pretože VPN backend môže uprednostniť reťazec alebo pripnúť certifikát spôsobmi, ktoré openssl nerobí.

Doručte sprostredkujúci certifikát konfiguráciou služby, ktorú klient skutočne číta, nie cez wiki stránku.

Kontrola 5: držte starú cestu na hodinách vyradenia

Krížové podpisovanie drží starú cestu dôvery zámerne živú, čo je zároveň zmysel aj riziko. Neodstraňuje kompromitovaný starý koreň a neodoberá tento koreň žiadnemu klientovi. Zapíšte, kedy stará cesta prestane dávať dôveru, a potvrďte, že ten deň skutočne nastane.

Ak každý klient môže prijať nový koreň skôr, než sa listy pohnú, obyčajné zavedenie dvojitej dôvery je jednoduchšie ako krížové podpisovanie a necháva o jednu vec menej na vyradenie.

Súvisiace články