OCSP супраць CRL: як насамрэч працуе кожная праверка адклікання

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

Крок 1: Што вяртае кожная праверка і колькі яна застаецца прыдатнай

CRL публікуецца як адзін падпісаны аб’ект, які ахоплівае ўсе сертыфікаты, адкліканыя эмітэнтам, таму правяральнік атрымлівае яго адзін раз і паўторна выкарыстоўвае, пакуль не міне nextUpdate спіса. Адказ OCSP вузнейшы: ён адказвае роўна пра адзін сертыфікат і нясе thisUpdate, producedAt і звычайна таксама nextUpdate. Менавіта гэтая розніца вызначае ўсё астатняе. Закэшаваны CRL старэе незаўважна, бо файл усё яшчэ разбіраецца і яго подпіс усё яшчэ правяраецца, а пратэрмінаваны адказ OCSP відавочна нічога не варты ў той момант, калі вы чытаеце яго часовыя адзнакі.

Таму кэшаванне — гэта першае, што трэба вызначыць: які кампанент трымае копію і якой мяжы гэтая копія падпарадкоўваецца. На шлюзе мяжой павінен быць nextUpdate мінус запас бяспекі, а не тое, што выпадкова прапануе загаловак HTTP-кэша. openssl crl -in issuer.crl -noout -lastupdate -nextupdate друкуе абедзве даты, а спіс, у якога nextUpdate ужо ў мінулым, трэба лічыць адсутным, а не проста старым.

Крок 2: Куды сертыфікат накіроўвае кліента

Канцавы сертыфікат звычайна нясе дзве падказкі: пашырэнне пункта размеркавання CRL і запіс доступу да інфармацыі цэнтра сертыфікацыі для OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints друкуе першае, а другое знаходзіцца ў раздзеле AIA вываду openssl x509 -in client.pem -noout -text. Любое з гэтых пашырэнняў — гэта ўказальнік, а не абавязак. Кліент, які ніколі не рэалізуе праверку адклікання, цалкам паспяхова злучыцца з сертыфікатам, пашырэнні якога называюць рэспандэр, які мёртвы ўжо год.

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

Крок 3: Выберыце fail-closed або fail-open да збою

Недасяжны рэспандэр або пратэрмінаваны спіс прымушаюць да рашэння: адмовіць у злучэнні або прыняць яго і зафіксаваць прабел. Падкаманда verify у OpenSSL робіць строгі выбар відавочным, бо даданне -crl_check ператварае недаступны CRL у unable to get certificate CRL і няўдалую праверку. Мяккі збой у большасці стэкаў — гэта наогул не сцяг, а адсутнасць праверкі, і менавіта таму ён трапляе ў практыку выпадкова.

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

Крок 4: Дакажыце, што праверка працуе там, дзе трафік дапускаецца

Знайдзіце працэс, які завяршае або аўтарызуе злучэнне, і запытайце ў яго радок канфігурацыі, які ўключае праверку адклікання. Шлюз, які правярае ланцужок, але ніколі не пытаецца пра адкліканне, ужывае іншую палітыку, чым тая, што ў вашай дакументацыі, і ніякі здымак экрана ланцужка сертыфікатаў не даказвае адваротнае. OpenVPN запісвае гэтую опцыю як crl-verify; strongSwan трымае пошук CRL і OCSP у канфігурацыі CA, дзе задаюцца crl_uris або ocsp_uris. Калі вы не можаце паказаць ні на адно, лічыце, што праверкі няма.

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

Крок 5: Адклічце адзін сертыфікат наўмысна

Вазьміце тэставы сертыфікат, адклічце яго праз той жа канал, які выкарыстоўвае практыка, і звярніцеся да рэспандэра напрамую. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text павінен паведаміць Cert Status: revoked разам з часам адклікання, а адказ good азначае, што вашае адкліканне не дасягнула рэспандэра, які запытваюць вашыя кліенты. Затым выканайце openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, каб убачыць тое ж рашэнне праз шлях спіса. Чытайце радок прычыны, а не код выхаду, бо адмова праз адкліканне і памылка ланцужка абодва заканчваюцца няўдачай.

Сапраўды важны крок — апошні: падключыцеся зноў са старым профілем да рэальнага пункта прымянення і пераканайцеся, што адмова ідзе ад адклікання. Затым падключыцеся зноў з свежым, сапраўдным сертыфікатам, каб даказаць, што вы не проста зламалі слухача. Выдаленне профілю на кліенце нічога не даказвае пра рашэнне сервера, як і паспяховы запуск openssl verify на машыне, якая ніколі не завяршае тунэль. RFC 6960 вызначае, што ўтрымлівае адпаведны адказ OCSP, уключаючы значэнні статусу, якія чытае гэты тэст.