Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Řešení potíží SSTP VPN připojení s certifikátem serveru
říjen 18
Řešení potíží SSTP VPN připojení s certifikátem serveru

V dnešní době, kdy už máte všichni alespoň Windows 7 a Windows Server 2008, si můžete dovolit naprosto luxusní TLS/SSL VPN připojení protokolem SSTP (Secure Socket Tunneling Protocol). Oproti PPTP se šifruje náhodným klíčem a je to standardní TLS (PPTP šifruje slaboučkným heslem uživatele). Oproti různým druhům IPSec VPN, jako je L2TP nebo IKEv2 a DirectAccess, nepotřebujete klientský certifikát. Takže pohoda, uživatel zadá heslo a přitom je to o hodně lepší, než zastaralá PPTP.

Jenže ne pohoda. Na SSTP VPN serveru (RRAS) potřebujete mít správný a platný a důvěryhodný TLS/SSL HTTPS certifikát webového serveru. Každý s tím vždycky laboruje a nikdy se neví, co uživatel vidí a proč mu to selhává.

Jak to vyzkoušet z klienta

SSTP VPN je normální HTTPS. Takže z klienta prostě zadejte do prohlížeče jenom jeho URL:

https://prahavpn.gopas.cz/sra{BA195980-CD49-458b-9E23-C84EE0ADCD75}

Sice neuvidíte v prohlížeči žádnou stránku, ale měli byste dostat poměrně srozumitelnou odpověď:

Response = HTTP/1.1 401 
Server = Microsoft-HTTPAPI/2.0
Date = Sun, 18 Oct 2015 08:22:52 GMT
Connection = close
Content-Length = 0

Ale hlavně uvidíte, jestli je certifikát v pořádku, nebo není:


Pokud se na první pohled zdá být v pořádku, uložte si ho do souboru. Možná nepůjde uložit na první pokus, musíte mít to URL umístěno v Trusted Sites (nebo v Local Intranet) zóně Internet Exploreru. No a potom už musíte jenom z příkazové řádky zkontrolovat certifikát kompletně. Tedy hlavně jeho CRL nebo OCSP revocation list (seznam zneplatnění). Protože SSTP vyžaduje kontrolu CRL, bez toho se nepřipojí. Nepřípojí se ani když to CRL jenom nejde stáhnout. Certifikát nemusí být neplatný, stačí že to nejde ověřit přes CRL nebo OCSP (detailnější návod v angličtině mám i zde):

certutil -urlfetch -verify c:\public\gopas.cer

Ve výstupu musí být úplně na konci napsáno, že Certificate revocation check passed. Pokud to tam není, bude tam nějaká chyba. O trošku více nahoře uvidíte detaily a například informaci které URL nelze stáhnout. Jednoduchou stahovačku CRL a OCSP máte také takto - pozor, tohle ale jenom stahuje, nekontroluje to ten certifikát:

certutil -url c:\public\gopas.cer

Třeba právě v tomto mém případě to píše, že The revocation function was not able to check revocation because the revocation server was offline. 0x80092013. Revocation check skipped - server offline. Takže nefunguje CRL, nelze se připojit.

Příkladem je třeba vnitřní certifikační autorita, která nemá CRL dostupné na veřejné HTTP adrese bez ověřování uživatele. Ve výchozím stavu publikují jenom na LDAP, kam se z internetu určitě nedostanete (alespoň doufám :-)). Viz poslední obrázek dnešního dne:

Prostě to jinak nepůjde, než že to CRL rozchodíte i z venku. Na HTTP cestě. Nebo si kupte veřejný certifikát a nemusíte to řešit.

Jak zakázat CRL kontrolu na SSTP klinetovi

No dobrá, tak vám to tedy řeknu. Na klientech je samozřejmě možné vypnout CRL kontrolu. Ne, že byste to chtěli udělat na trvalo, ale když už, tak alespoň na vyzkoušení se to může hodit:

HKLM\System\CurrentControlSet\Services\SSTPSvc\Parameters
NoCertRevocationCheck = DWORD = 1

No a to je už snad úplně všechno :-)

Comments

verejny cert pro interni ucely (napr: .local)

pekny...

https://www.digicert.com/internal-names.htm
All publicly trusted SSL Certificates issued to internal names and reserved IP addresses will expire before November 1, 2015.

It will be impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified after 2015.

Update: Since this post was written, there has been a major new development with fabricated TLDs. The CA/Browser forum, which is a consortium of web browser vendors and public CAs has released a document titled:  Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum. It can be found here (warning: direct link to PDF).
VasekB on 19.10.2015 22:56

Komentář ke komentáři ke článku

Nějak mi ten komentář k článku nesedí. VPN server bude dost těžko používat interní TLD, to už by musela být super extra paranoia využívající třeba HOSTS resolving :)
A zrovna pro VPN server docela rád používám firemní interní CA. Horší je to u Exchange serverů a úplně v pytli je to v kombinaci s Office 365.
Každopádně už řadu let se snažím ve svém okolí šířit osvětu, že hned po instalaci interní CA je třeba vytvořit veřejný web např. crl.firma.tld nebo raději dva, na jiných FQDN, serverech, ideálně i v jiné síti.
Radek Doležel on 3.11.2015 23:22

No mazec - špek s revocation checkem

Teď jsem pěkně vykysnul na SSTP a interní CA (a to ještě není konec)
1) nová CA, CDP a AIA vystrčené do internetu, certutil -verify ověří cert v pořádku
2) url SSTP VPN (sra_{ba1..... - důvěryhodný certifikát a CA OK, je v computer store, server cert není (jinde mi to naprosto v pohodě funguje)
3) vytočím VPN a …The revocation function was not able to check revocation because the revocation server was offline

sranda nastává, když to zkusí kolega ze svého PC a tam mu to normálně funguje… (mě vlastně taky, ale jen v certutil, nebo browseru. u SSTP klienta již nikoliv :-(

už nevím, co mám hledat. Asi wireshark...

už nevím co s tím
 
Honza Vošta on 4.9.2018 10:54

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments