Почему OpenConnect отклоняет шлюз после замены сертификата?

Шлюзы заменяют сертификаты, и клиент, который вчера ещё подключался, начинает останавливаться на первом обмене TLS. Сообщение называет причину проверки, а не сетевую неисправность, и сама машина не изменилась, и это полезная зацепка. Сломалось отношение между сертификатом, который теперь предъявляется, и корнями, которые клиент готов рассматривать. Починить это — решение о доверии, поэтому примите его, прежде чем вводить параметр.

Прочитайте сбой, прежде чем менять любую настройку доверия

Ошибка вида «отсутствует подписывающий» означает, что цепочка заканчивается на чём-то, чего клиент не принимает. Это может быть обновлённый сертификат внутреннего удостоверяющего центра, замена от публичного центра или устройство посередине, предъявляющее собственный сертификат. Одна лишь формулировка не позволяет различить эти случаи, поэтому посмотрите на издателя, прежде чем решать.

Запустите соединение один раз на переднем плане и дайте ему завершиться ошибкой, потому что интерактивный вывод содержит имя сервера, цепочку издателя и отпечаток, вычисленный клиентом. Сравните этого издателя с центром, который ваша организация действительно использует. Если отпечаток изменился, а издатель нет, считайте это подозрительным, пока обновление не подтвердится по каналу, которому вы уже доверяете. Гадать в этот момент — это путь, на котором человек в итоге закрепляет ключ перехватчика.

Запишите версию клиента в ту же заметку. Значительная часть сбоев, похожих на проблемы доверия, происходит из-за старого клиента, который сталкивается с более новым обменом шлюза.

Выберите между доверием издателю и закреплением одного ключа

Оба варианта позволяют соединению работать. Позже они ломаются противоположными способами, поэтому выбор относится к сбою, который вы можете перенести.

Берите файл CA, когда сертификат приходит от центра, который вы можете проверить независимо, потому что тогда обновления продолжают работать без правки аргументов клиента. Соедините его с переключателем, отключающим системные корни, иначе публичный центр сможет выполнить проверку за вас. Вместо этого закрепляйте ключ, когда у шлюза нет CA, который можно получить, или когда целью является максимально узкое исключение. Ни один путь не безопаснее в абстракции: CA масштабируется на обновления, закрепление проще проверить.

Что бы вы ни выбрали, доверенное значение должно прийти по каналу, который был доверенным до изменения. Администратор, консольная сессия на шлюзе или заранее снятая копия — все подходят. Копирование любого отпечатка, который показывает запрос, удобно и является именно тем, на что надеется перехватчик.

Поместите значение в команду, которую вы действительно запускаете

Закрепление передаётся в параметре сертификата сервера, и его префикс определяет кодирование: шестнадцатеричные дайджесты открытого ключа под sha1 или sha256 и закрепление ключа в base64 под pin-sha256. Его указание также отключает системное доверие для этого запуска, поэтому закреплённый ключ становится всем решением.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Клиент сопоставляет усечённый дайджест, принимая всего четыре символа после префикса, что является ловушкой, а не удобством. Сокращённое значение проходит локально и всё равно не идентифицирует нужный шлюз. Скопируйте полную строку, которую клиент напечатал при первой попытке, вместо того чтобы перепечатывать её из сообщения. Затем перенесите готовый параметр в скрипт-обёртку, unit-файл или профиль, который запускает соединение, чтобы решение о доверии можно было пересмотреть, а поздние правки были осознанными.

Рабочие столы и плагин NetworkManager хранят собственную копию аргументов соединения. Скрипт, отредактированный на диске, не доходит до ранее импортированного профиля, поэтому сохранённое значение продолжает побеждать.

Обработайте смену, не заперев себя снаружи

Параметр можно указать более одного раза, поэтому запланированное изменение может принять уходящий и входящий ключи вместе. Добавьте новое закрепление до переключения шлюза, держите оба в списке, пока сессии мигрируют, и уберите выведенный из эксплуатации, когда старый ключ исчезнет. Этому окну нужен владелец, потому что забытое двойное закрепление оставляет ключ доверенным без присмотра. Пересборка, порождающая новую пару ключей, ломает чистое закрепление, и восстановление — та же процедура в обратную сторону.

Напишите дату изменения рядом с закреплением. Закрепление без даты проверки — это будущий сбой с запутанным сообщением об ошибке.

Исключите версию клиента, прежде чем редактировать доверие

Устаревший клиент может сбойнуть при разборе ответа аутентификации, который шлюз с тех пор изменил, и поверхностное сообщение всё ещё говорит о соединении, а не о парсере. Сравните установленную версию с тем, что документирует шлюз, и перед изменением любой настройки доверия проверьте текущий пакет в одноразовом профиле.

openconnect --version

После починки проверьте две вещи, а не одну: портал загружается через туннель, и обычный внутренний адрес отвечает. Завершённое рукопожатие доказывает лишь то, что решение о доверии было принято.