Крос-падпісаны CA: ключ супадае, прывязка AKI — не

Два сертыфікаты CA могуць мець адзін і той жа публічны ключ і адзін і той жа суб'ект і ўсё ж не быць узаемазаменнымі. Адзін самападпісаны, другі крос-падпісаны старым коранем, і іх імёны выдаўца, серыйныя нумары і подпісы розныя. Ліст можа прывязацца менавіта да аднаго з іх праз свой Authority Key Identifier. Гэтая прывязка застаецца нябачнай, пакуль кліент не выбера няправільны ланцуг і handshake не праваліцца без відавочнай прычыны.

Выканайце гэтыя пяць праверак па парадку: кожная выключае свой тып збою.

Праверка 1: намалюйце абодва ланцугі, перш чым кранаць шаблон

Запішыце шляхі. Старая папуляцыя давярае Старому Корану A, які выдаў CA B, які выдаў серверны ліст. Новая папуляцыя давярае самападпісанаму CA B напрамую. Абодва сертыфікаты B нясуць адзін ключ і суб'ект, і менавіта таму чалавек, які чытае радок суб'екта, бачыць адзін CA там, дзе кліент бачыць два.

Крос-падпісаная копія таксама павінна быць сапраўдным сертыфікатам CA, з basic constraints і key usage, якія дазваляюць подпіс.

Праверка 2: параўнайце поля AKI, а не толькі ключ

Імя выдаўца ліста павінна супадаць з суб'ектам B, і гэтая частка звычайна супадае. 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-бэкенд можа аддаць перавагу ланцугу або замацаваць сертыфікат спосабамі, якіх openssl не робіць.

Дастаўляйце прамежкавы сертыфікат праз канфігурацыю сэрвісу, якую кліент фактычна чытае, а не праз вікі-старонку.

Праверка 5: трымайце стары шлях на гадзінніку вываду з эксплуатацыі

Крос-подпіс па задуме трымае стары шлях даверу жывым, і гэта адначасова і мэта, і рызыка. Ён не ліквідуе скомпраметаваны стары корань і не выдаляе гэты корань з любога кліента. Запішыце, калі стары шлях перастане даваць давер, і пацвердзіце, што гэты дзень сапраўды настане.

Калі кожны кліент можа прыняць новы корань да пераезду лістоў, звычайнае разгортванне з двайным даверам прасцейшае за крос-подпіс, і яно пакідае на адну рэч менш для вываду.