Адкліканне сертыфікатаў не ўдаецца: які хост куды не дацягваецца

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

Шлях атрымання належыць таму, хто правярае

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

Запішыце сертыфікат, таго, хто правярае, час спробы і дакладны код стану, перш чым нешта змяняць.

Прачытайце пункт публікацыі з сертыфіката

Сертыфікат называе, дзе знаходзіцца яго статус. Чытайце гэтыя палі замест здагадак пра адрас CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

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

Праверце атрыманне з прылады, якая правярае

Выканайце тэст атрымання ў асяроддзі, якое фактычна выконвае праверку, з ухваленымі матэрыяламі сертыфіката і без прыватных ключоў.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

Запуск certutil правярае ланцуг і паведамляе, якія выбаркі URL удаліся або не ўдаліся, а выклік curl тэстуе адзін адрас публікацыі з таго ж хоста і вяртае толькі код стану. Няўдалая выбарка з дасяжнага адраса ўказвае на праблемы змесціва або подпісу; памылка злучэння ўказвае на маршрутызацыю, DNS або проксі. Захавайце абодва вынікі, бо адна паспяховая выбарка не даказвае, што ўвесь ланцуг прыдатны. Змяніце прыкладны хост і шлях на пункт размеркавання, знойдзены ў сертыфікаце.

Аддзяліце адсутныя даныя ад статусу адклікання

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

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