Помилка вебсертифіката в 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, тож заміна не потребує чіпати профілі, ключ сервера чи центр сертифікації. Перебудова всієї 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-адресою легко покаже не той сертифікат, який отримують користувачі. Виправте й перевірте набір для імені, що зазнало невдачі, і повторіть перевірку входу, перш ніж закривати інцидент.

Схожі статті