Keresztben aláírt CA: a kulcs egyezik, az AKI-kötés nem

Két CA-tanúsítvány ugyanazt a nyilvános kulcsot és ugyanazt a subjectet hordozhatja, mégsem cserélhetők fel. Az egyik önaláírt, a másikat a régi gyökér írta alá keresztben, és a kibocsátónevek, sorszámok és aláírások eltérnek. Egy levél kifejezetten az egyikhez kötődhet az Authority Key Identifierén keresztül. Ez a kötés láthatatlan marad, amíg egy kliens a rossz láncot nem választja, és a handshake nyilvánvaló ok nélkül meg nem bukik.

Végezze el ezt az öt ellenőrzést sorrendben: mindegyik más hibát zár ki.

1. ellenőrzés: rajzolja fel mindkét láncot, mielőtt a sablonhoz nyúl

Írja le az útvonalakat. A régi populáció a Régi gyökér A-ban bízik, amely kiadta a CA B-t, amely kiadta a szerver levelét. Az új populáció közvetlenül az önaláírt CA B-ben bízik. Mindkét B tanúsítvány ugyanazt a kulcsot és subjectet hordozza, és éppen ezért lát a subject sort olvasó ember egy CA-t ott, ahol a kliens kettőt lát.

A keresztben aláírt példánynak is valódi CA-tanúsítványnak kell lennie, basic constraints és key usage kiterjesztéssel, amelyek engedélyezik az aláírást.

2. ellenőrzés: hasonlítsa össze az AKI mezőket, ne csak a kulcsot

A levél kibocsátónevének egyeznie kell B subjectjével, és ez a rész általában teljesül. Az Authority Key Identifier az a pont, ahol a két példány elválik, mert hordozhat kulcsazonosítót, kibocsátó-tanúsítványt és sorszámot. A kulcsazonosító mindkét példánnyal egyezik, mivel a kulcs azonos. A kibocsátó és a sorszám mező pontosan egy példánnyal egyezik, ezért az önaláírt példány ellen épülő lánc elbukhat a keresztben aláírt ellen.

Vizsgálja meg a levelet a találgatás helyett: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Ezután hasonlítsa össze mindkét jelöltet a openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier" paranccsal, és ugyanezt az önaláírt példány ellen.

Ha a levél kibocsátót és sorszámot hordoz, csak az a tanúsítvány egészíti ki a láncot, amelyet ezek az értékek leírnak, bármelyik példányt töltötte is be a kliens.

3. ellenőrzés: a kibocsátási szabályzatot módosítsa, soha az aláírt bájtokat

A kiterjesztések az aláíráson belül élnek. Egy meglévő levélen hozzáadni, eltávolítani vagy szerkeszteni nem javítás, hanem más tanúsítvány, és újrakibocsátást igényel. A változás a kibocsátási szabályzatba tartozik: a authorityKeyIdentifier = keyid,issuer:always hatására az új levelek hordozzák a tanúsítvány-specifikus kötést, míg az önmagában álló keyid megtartja a lazább formát, amely egy szándékos keresztaláírási átálláshoz illik. Döntse el, melyiket akarja a PKI-ja, mielőtt a következő köteget aláírják.

Egy megosztott sablon szerkesztése minden jövőbeli tanúsítványt is megváltoztat, nem csak az előtted álló szervert.

4. ellenőrzés: minden bizalmi populációt külön ellenőrizzen

Tesztelje a régi utat és az új utat külön futásként. A openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem a keresztben aláírt útvonalat gyakorolja, és ugyanez a parancs az új gyökérrel, untrusted fájl nélkül az önaláírt útvonalat gyakorolja. Mindkét gyökér egy kötegbe keverése elrejti, melyik láncot választották. Ismételje meg utána valódi kliensekkel, mert egy VPN backend előnyben részesíthet egy láncot, vagy rögzíthet egy tanúsítványt olyan módokon, ahogy az openssl nem teszi.

A köztes tanúsítványt a kliens által ténylegesen olvasott szolgáltatáskonfiguráción keresztül szállítsa, ne wikioldalon.

5. ellenőrzés: tartsa a régi utat kivezetési órán

A keresztaláírás tervezés szerint életben tart egy régi bizalmi utat, ami egyszerre a cél és a kockázat. Nem orvosol egy kompromittált régi gyökeret, és nem távolítja el azt a gyökeret egyetlen kliensből sem. Írja le, mikor szűnik meg a régi út bizalmat adni, és erősítse meg, hogy az a nap valóban eljön.

Ha minden kliens át tudja venni az új gyökeret, mielőtt a levelek elmozdulnak, egy egyszerű kettős bizalmi bevezetés egyszerűbb a keresztaláírásnál, és egy dologgal kevesebb marad kivezetni.