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

Имя в профиле определяет, что проверяется

SSTP запускает TLS поверх TCP 443, поэтому клиент ведёт себя как любой другой TLS-клиент: берёт имя хоста из профиля, запрашивает это имя и сравнивает с ним сертификат. Если вписать в профиль IP-адрес, сравнение станет сравнением IP-адресов, которому большинство серверных сертификатов не соответствует.

Поэтому тест в браузере может пройти, а VPN — нет: браузер использовал другое имя, не то, что в профиле. То же расхождение возникает, когда split-horizon DNS разрешает имя хоста VPN во внутренний адрес, а браузер попал на публичный. Сначала согласуйте профиль с документированным именем хоста, а уже потом сравнивайте сертификаты. Всё остальное, что вы измените до этого, — догадка.

Что должен содержать сертификат сервера

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

Сертификату нужно и назначение аутентификации сервера — значение расширенного использования ключа, названное в спецификации Microsoft по SSTP, то есть serverAuth с идентификатором объекта 1.3.6.1.5.5.7.3.1. Использование ключа и действительная цепочка завершают набор. Сертификат, который есть на сервере, выдан на правильное имя, но только для аутентификации клиента, всё равно не проходит.

Проверьте цепочку и часы до учётных данных

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

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Первая команда печатает имя, период действия и альтернативные имена, с которыми будет сравнивать клиент. Вторая сообщает об ошибках проверки вместе с предъявленной цепочкой, и именно там появляется отсутствующий промежуточный сертификат. В Windows запрос к службе времени скажет, корректируются часы или просто ушли.

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

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

Исправьте имя или сертификат и повторите тест

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

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

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