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

Похожие статьи