Несовпаѓање на сертификатот 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. Инсталирајте го организацискиот корен преку неговиот одобрен канал за дистрибуција, а не од страница што нуди заменски сертификат, бидејќи таа одлука е целиот модел на доверба во минијатура.

Валидацијата на серверот и автентикацијата на корисникот се последователни фази со различни неуспеси. Грешка во сертификатот значи дека клиентот никогаш не му верувал на серверот, додека одбиена лозинка значи дека му верувал и податоците биле погрешни. Исклучувањето на валидацијата на сертификатот за да се стигне до барањето за лозинка ја отстранува гаранцијата наместо да ја поправи. За да докажете дека остатокот од патот работи, тестирајте ги истото име на домаќин и порта од клиент што веќе му верува на синџирот, и оставете го распоредениот профил на мира.

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

Три услови ја одлучуваат поправката. Ако името во профилот е погрешно, поправете го профилот или додајте го името што недостасува во сертификатот. Ако синџирот е нецелосен, инсталирајте го посредниот сертификат на серверот. Ако намената е погрешна, издајте нов наместо да крпите околу тоа.

По промената, поврзете се повторно со поддржаниот клиент и потврдете дека се појавува барањето за најава, а потоа дека тунелот се подигнува. Забележете во тикетот користеното име на домаќин, издавачот и датумот на истекување. Токму тој запис го прави следното обновување планирана задача наместо уште еден прекин, и му покажува на следниот човек кој од трите услови навистина бил прекршен.