Хоёр CA гэрчилгээ ижил нийтийн түлхүүр, ижил subject-той байж болох ч сольж болохгүй. Нэг нь өөрөө гарын үсэг зурсан, нөгөө нь хуучин үндэсээр хөндлөн гарын үсэг зурсан бөгөөд олгогчийн нэр, серийн дугаар, гарын үсэг нь өөр байна. Навч нь өөрийн Authority Key Identifier-ээр дамжуулан яг аль нэгэнд нь холбогдож болно. Энэ холбоос нь клиент буруу гинжийг сонгож, handshake тодорхой шалтгаангүйгээр бүтэлгүйтэх хүртэл үл үзэгдэх байна.

Эдгээр таван шалгалтыг дарааллаар нь хий: тус бүр өөр бүтэлгүйтлийг үгүйсгэдэг.

Шалгалт 1: загварт хүрэхээс өмнө хоёр гинжийг зур

Замүудыг бичиж ав. Хуучин популяци Хуучин үндэс A-д итгэдэг, тэр CA B-г олгосон, тэр серверийн навчийг олгосон. Шинэ популяци өөрөө гарын үсэг зурсан CA B-д шууд итгэдэг. Хоёр B гэрчилгээ ижил түлхүүр, subject-той, яг ийм учраас subject мөрийг уншиж буй хүн клиент хоёрыг харж байгаа газарт нэг CA хардаг.

Хөндлөн гарын үсэг зурсан хувилбар нь ч жинхэнэ CA гэрчилгээ байх ёстой, basic constraints болон key usage нь гарын үсэг зурахыг зөвшөөрөх ёстой.

Шалгалт 2: зөвхөн түлхүүр биш, AKI талбаруудыг харьцуул

Навчны олгогчийн нэр B-ийн subject-той таарах ёстой, энэ хэсэг ихэвчлэн биелдэг. Хоёр хувилбар салдаг газар нь Authority Key Identifier, учир нь энэ нь түлхүүрийн танихуй, олгогч гэрчилгээ, серийн дугаарыг агуулж болно. Түлхүүрийн танихуй нь түлхүүр ижил тул хоёр хувилбартай ч таарна. Олгогч, серийн талбарууд яг нэгтэй л таардаг, тиймээс өөрөө гарын үсэг зурсан хувилбарын эсрэг барьсан гинж хөндлөн гарын үсэг зурсан хувилбарын эсрэг бүтэлгүйтэж болно.

Таамаглахын оронд навчийг шалга: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Дараа нь хоёр нэр дэвшигчийг openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier"-ээр харьцуул, мөн ижил командыг өөрөө гарын үсэг зурсан хувилбарын эсрэг ажиллуул.

Хэрэв навч олгогч, серийн дугаарыг агуулж байвал тэдгээр утгыг тодорхойлсон гэрчилгээ л гинжийг гүйцээж, клиент аль хувилбарыг ачаалсан ч хамаагүй.

Шалгалт 3: олголтын бодлогыг өөрчил, гарын үсэг зурсан байтыг хэзээ ч биш

Өргөтгөлүүд гарын үсгийн дотор амьдардаг. Одоо байгаа навч дээр нэгийг нэмэх, хасах, засах нь засвар биш, энэ нь өөр гэрчилгээ бөгөөд дахин олголт шаардана. Өөрчлөлт нь олголтын бодлогод хамаарна: authorityKeyIdentifier = keyid,issuer:always шинэ навчид гэрчилгээнд тусгай холбоосыг агуулуулдаг бол зөвхөн keyid санаатай хөндлөн гарын үсгийн шилжилтэд тохирох сул хэлбэрийг хадгална. Дараагийн багц гарын үсэг зурагдахаас өмнө таны PKI алийг нь хүсэж байгааг шийд.

Хуваалцсан загварыг засах нь зөвхөн өмнө чинь байгаа сервер биш, бүх ирээдүйн гэрчилгээг өөрчилдөг.

Шалгалт 4: итгэлцлийн популяци бүрийг тусад нь баталгаажуул

Хуучин зам, шинэ замыг тусдаа ажиллагаа болгон турш. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem хөндлөн гарын үсэг зурсан замыг дасгалжуулж, шинэ үндэс болон untrusted файлгүй ижил команд өөрөө гарын үсэг зурсан замыг дасгалжуулна. Хоёр үндсийг нэг багцад холих нь аль гинж сонгогдсоныг нуудаг. Дараа нь бодит клиентүүдтэй давтаж үз, учир нь VPN backend гинжийг илүүд үзэх эсвэл гэрчилгээг бэхлэх боломжтой, openssl-ийн хийдэггүй аргаар.

Завсрын гэрчилгээг клиентийн үнэхээр уншдаг үйлчилгээний тохиргоогоор хүргэ, вики хуудсаар биш.

Шалгалт 5: хуучин замыг ашиглалтаас гаргах цаг дээр бари

Хөндлөн гарын үсэг нь хуучин итгэлцлийн замыг зохион бүтээлтээрээ амьд байлгадаг бөгөөд энэ нь зорилго ба эрсдэл хоёулаа юм. Энэ нь эвдэрсэн хуучин үндсийг засдаггүй, тэр үндсийг аль ч клиентээс хасдаггүй. Хуучин зам хэзээ итгэл өгөхөө болихыг бичиж, тэр өдөр үнэхээр ирэхийг батал.

Хэрэв клиент бүр навчнууд шилжихээс өмнө шинэ үндсийг хүлээж авах боломжтой бол энгийн давхар итгэлцлийн нэвтрүүлэлт хөндлөн гарын үсгээс хялбар бөгөөд ашиглалтаас гаргах нэг зүйлээр бага үлддэг.

Холбоотой нийтлэлүүд