Несъответствие на сертификата при SSTP: името, което сървърът ви трябва да представи

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

Проверката на сървъра и удостоверяването на потребителя са последователни етапи с различни откази. Грешка в сертификата означава, че клиентът никога не се е доверил на сървъра, докато отхвърлена парола означава, че се е доверил и данните са били грешни. Изключването на проверката на сертификата, за да стигнете до подканата за парола, премахва гаранцията, вместо да я поправи. За да докажете, че останалата част от пътя работи, тествайте същото име на хост и порт от клиент, който вече се доверява на веригата, и оставете внедрения профил непокътнат.

Поправете името или сертификата и тествайте отново

Три условия решават поправката. Ако името в профила е грешно, поправете профила или добавете липсващото име към сертификата. Ако веригата е непълна, инсталирайте междинния сертификат на сървъра. Ако предназначението е грешно, издайте наново, вместо да заобикаляте с кръпки.

След промяната се свържете отново с поддържания клиент и потвърдете, че се появява подканата за вход, а след това че тунелът се вдига. Запишете в тикета името на хоста, издателя и датата на изтичане. Този запис превръща следващото подновяване в планирана задача, а не в поредно прекъсване, и показва на следващия човек кое от трите условия всъщност е било нарушено.