Памылка вэб-сертыфіката Access Server: пусты пакет CA

Пустое значэнне ca_bundle або пашкоджаны PEM спыняе інтэрфейс адміністратара. Праверце сертыфікат, ключ і ланцужок як адзін набор перад перазапускам, а PKI VPN не чапайце.

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

На што сапраўды паказваюць тры ключы

Набор уласнага вэб-сертыфіката апісваецца ключамі cs.cert, cs.priv_key і cs.ca_bundle. Кожны захоўвае шлях да файла, і ўсе тры выкарыстоўваюцца разам вэб-службай. Сертыфікат з няправільным ключом або файл ланцужка, які насамрэч з'яўляецца канцавым сертыфікатам, падае гэтак жа, як пустое значэнне: слухач не можа пабудаваць ланцужок, прыдатны для браўзера.

Гэтыя ключы належаць вэб-інтэрфейсам Admin і Client. Яны аддзеленыя ад PKI, што выдае сертыфікаты кліентам VPN, таму замена не патрабуе кранання кліенцкіх профіляў, ключа сервера або цэнтра сертыфікацыі. Лічыць збой вэб-TLS прычынай перабудаваць усю PKI — самая дарагая памылка тут.

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

Чаму існуючы файл усё роўна не разбіраецца

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

Аглядайце аб'екты, а не пашырэнні. На хасту Linux openssl x509 -noout -subject -issuer -in server.pem і openssl pkey -noout -check -in key.pem адказваюць на два важныя пытанні, а параўнанне модуля або публічнага ключа абодвух даказвае, што яны належаць разам. Трымайце вывад прыватнага ключа па-за тыкетамі і журналамі чатаў; праверцы патрэбны адбітак, а не ключ.

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

Свядома вярніцеся да рэзервовага варыянта

CLI Access Server мае праверку, якая прымае тры шляхі як аргументы і паведамляе, ці прыдатны набор. Шляхі ніжэй — прыклад; заменіце іх абароненымі месцамі на хасту:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

Праверце імя, якое карыстальнікі сапраўды ўводзяць

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

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

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

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

Аднаўленне завяршаецца толькі пасля паспяховага ўваходу

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

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

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