Мэта сертыфіката сервера выглядае правільнай, ключ супадае, даты ў парадку, а злучэнне ўсё роўна не ўсталёўваецца з памылкай unsupported certificate purpose. Дэталь, якая гэта вырашае, звычайна знаходзіцца ў тым жа радку, што і памылка: значэнне глыбіні і суб'ект, якія называюць сертыфікат вышэй у ланцугу. Выконваюцца два розныя тэсты, і толькі адзін з іх датычыцца канчатковага сертыфіката. Іх параўнанне тлумачыць, чаму замена сертыфіката сервера нічога не змяняе.

Які сертыфікат насамрэч адхіліў правяральнік

Ланцуг — гэта не адзін аб'ект, паўтораны тры разы. Канчатковы сертыфікат нясе імя і ключ сервера, прамежкавыя звязваюць яго з коранем, і кожны мае свой тэрмін дзеяння, абмежаванні і прызначэнні. Калі памылка называе глыбіню, гэты лік пазначае пазіцыю ў ланцугу, які пабудаваў правяральнік, і яна можа не супадаць з чаканай, калі сервер дасылае нечаканы ланцуг.

Чытайце палі сертыфіката на гэтай глыбіні, а не сертыфіката, які вы лічылі вінаватым. Запытайце два пашырэнні, якія абмяжоўваюць выпуск, замест таго каб выгружаць усе палі, бо адказ амаль заўсёды ў адным з іх. Вывад пашырэнняў бяспечна дзяліцца; прыватныя ключы — ніколі.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Калі названы сертыфікат — прамежкавы, чыё пашырэнне выкарыстання ключа згадвае нешта не звязанае з аўтэнтыфікацыяй сервера TLS, астатняя частка збою вынікае механічна. Ланцуг нельга выкарыстаць для мэты, якую запытаў OpenVPN.

Мэта канчатковага сертыфіката і палітыка ланцуга — два тэсты

Тэст канчатковага сертыфіката ставіць вузкае пытанне: ці дазваляе гэты сертыфікат канечнага аб'екта аўтэнтыфікацыю сервера для гэтага імені? Тэст ланцуга ставіць шырэйшае: ці можа кожны сертыфікат у шляху служыць гэтай мэце? Цэнтр сертыфікацыі, якому дазволена выпускаць толькі кліенцкія сертыфікаты, пройдзе ўласныя праверкі подпісу і ўсё роўна не пройдзе другі тэст, бо шлях, які ён дазваляе, не ўключае мэту, патрэбную праграме. Абодва тэсты правальваюцца з аднолькавымі словамі і маюць цалкам розныя выпраўленні.

Менавіта таму шчыра выдадзены канчатковы сертыфікат, правільны ва ўсіх бачных палях, можа адразу не прайсці. І менавіта таму выпраўленне звычайна адносіцца да профілю цэнтра выпуску, а не да канфігурацыі VPN.

Адсутнае EKU — не абмежавальнае EKU

RFC 5280 робіць пашырэнне выкарыстання ключа неабавязковым і, калі яно ёсць, абмежавальным. Таму сертыфікат CA без пашырэння не сказаў «не» аўтэнтыфікацыі сервера, а той, што пералічвае толькі незвязаную мэту, сказаў нешта вельмі канкрэтнае. Калі лічыць гэтыя два станы раўназначнымі, атрымаецца няправільны дыягназ і, што горш, няправільнае выпраўленне. Гэта адрозненне таксама тлумачыць, чаму два цэнтры, падобныя ў кансолі, паводзяць сябе цалкам па-рознаму ў ланцугу.

Паводзіны бібліятэк тут таксама неаднолькавыя. Дакумент параметраў праверкі OpenSSL апісвае ўласную трактоўку праверкі мэты для сертыфікатаў CA, і гэтая трактоўка — палітыка рэалізацыі, а не правіла, якому ўсе стэкі TLS ідуць аднолькава. Апішыце, што робіць ваш правяральнік, потым пацвердзіце гэта на версіі, якую вы насамрэч запускаеце.

Аднавіце збой афлайн перад перавыпускам

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

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain важны, бо друкуе шлях, які пабудаваў інструмент, а ён часта не такі, як парадак файлаў, што вы падалі. Гэты вывад — найхутчэйшы спосаб выявіць, што другі прамежкавы сертыфікат бярэцца са сховішча даверу, што сервер дасылае перакрыжавана падпісаны варыянт, якога вы не мелі на ўвазе, або што сцяжок мэты, скапіяваны з падручніка, належыць іншай ролі, чым тая, якой служыць сервер.

Выпраўляйце палітыку выпуску, а не выклік праверкі

Трывалае выпраўленне — прамежкавы сертыфікат, выдадзены па палітыцы, якая дазваляе мэты, якім ён павінен служыць, з запісаным і перагледжаным абмежаваннем. Дадаванне кожнай мэты кожнаму цэнтру — не палітыка; яно прыбірае абмежаванне, што надавала пашырэнню сэнс, і звычайна перажывае інцыдэнт, які яго выклікаў. Кароткая нататка ў профілі, якая апісвае, якія ролі цэнтр можа сертыфікаваць, не дае наступнаму перавыпуску паўтарыць тую ж спрэчку.

Адключэнне праверкі — іншы спакуслівы кароткі шлях, і ён ператварае праблему сертыфіката ў праблему даверу. Пакіньце праверку мэты на месцы, выпраўце ланцуг і паўтарыце тую ж афлайн-праверку, каб пераканацца, што шлях цяпер служыць патрэбнай ролі, перш чым зноў кранаць сэрвіс.

Падобныя артыкулы