Neshoda certifikátu SSTP: jaké jméno musí server předložit

SSTP klient SSTP přijme server až po úspěšném ověření TLS a tato kontrola porovnává jméno, řetěz a účel. Jméno pochází z profilu připojení, ne z adresy, kterou náhodou můžete pingnout. Když jedna ze tří položek nesedí, klient ohlásí problém s certifikátem a nikdy nedojde k výzvě k přihlášení.

Jméno v profilu určuje, co se kontroluje

SSTP běží na TLS přes TCP 443, takže se klient chová jako každý jiný TLS klient: vezme název hostitele z profilu, vyžádá tento název a porovná s ním certifikát. Pokud do profilu zadáte IP adresu, porovnání se změní na porovnání IP adres, které většina certifikátů serveru nesplňuje.

Test v prohlížeči proto může uspět, zatímco VPN selže, protože prohlížeč použil jiné jméno než profil. Stejné rozdělení se objeví, když split-horizon DNS přeloží název hostitele VPN na interní adresu, zatímco prohlížeč dosáhl veřejné. Nejprve sjednoťte profil s dokumentovaným názvem hostitele, potom porovnávejte certifikáty. Cokoli jiného změníte předtím, je hádání.

Co musí certifikát serveru obsahovat

Moderní klienti porovnávají s rozšířením alternativních jmen subjektu, takže název hostitele tam musí být jako záznam DNS. Pouhé obecné jméno pro současné ověřovací sady nestačí a zástupný znak pokrývá jednu část, nikoli libovolnou subdoménu, kterou vymyslíte. Tři certifikáty ukazují hranici: správné jméno se špatným účelem ověří identitu a potom selže při kontrole účelu, správné jméno i účel s chybějícím zprostředkujícím certifikátem selžou na řetězu a jméno, které je jen v obecném jménu, selže dřív, než na kterémkoli z těch dvou záleží.

Certifikát také potřebuje účel ověřování serveru, hodnotu rozšířeného použití klíče uvedenou v specifikaci SSTP od Microsoftu, tedy serverAuth s identifikátorem objektu 1.3.6.1.5.5.7.3.1. Použití klíče a platný řetěz doplňují sadu. Certifikát, který na serveru existuje, je vydán pro správné jméno, ale pouze pro ověřování klienta, stále selže.

Před přihlašovacími údaji ověřte řetěz a hodiny

Selhání času a důvěry dávají stejný viditelný výsledek jako neshoda jména a obojí se diagnostikuje levněji než problém s heslem. Zkontrolujte hodiny serveru a hodiny klienta a potom přečtěte řetěz tak, jak ho vidí klient:

# 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

První příkaz vypíše jméno, dobu platnosti a alternativní jména, se kterými bude klient porovnávat. Druhý hlásí chyby ověření s předloženým řetězem a právě tam se objeví chybějící zprostředkující certifikát. Ve Windows vám dotaz na časovou službu řekne, zda se hodiny opravují, nebo se jen rozešly.

Interní CA přidává další podmínku: klient musí této CA důvěřovat. Nainstalujte organizační kořenový certifikát schváleným distribučním kanálem, ne ze stránky nabízející náhradní certifikát, protože toto rozhodnutí je celý model důvěry v miniatuře.

Ověření serveru a autentizace uživatele jsou po sobě jdoucí fáze s odlišnými selháními. Chyba certifikátu znamená, že klient serveru nikdy nedůvěřoval, zatímco odmítnuté heslo znamená, že mu důvěřoval a údaje byly špatné. Vypnutí ověřování certifikátu, abyste se dostali k výzvě k heslu, záruku odstraňuje, místo aby ji opravilo. Chcete-li prokázat, že zbytek cesty funguje, otestujte stejný název hostitele a port z klienta, který řetězu už důvěřuje, a nasazený profil nechte být.

Opravte jméno nebo certifikát a zkuste to znovu

Opravu určují tři podmínky. Pokud je jméno v profilu špatné, opravte profil nebo přidejte chybějící jméno do certifikátu. Pokud je řetěz neúplný, nainstalujte zprostředkující certifikát na server. Pokud je účel špatný, vystavte nový certifikát, místo abyste to obcházeli záplatou.

Po změně se znovu připojte podporovaným klientem a potvrďte, že se objeví výzva k přihlášení a potom že tunel naskočí. Do tiketu poznamenejte použitý název hostitele, vydavatele a datum vypršení. Právě tento záznam dělá z příští obnovy plánovaný úkol místo dalšího výpadku a také ukáže dalšímu člověku, která ze tří podmínek byla skutečně porušená.