OpenVPN proti Windows

[Rudolf Dvořák]

Pěkný den,
může tady někdo pastnout funkční konfiguraci openvpn serveru na mikrotiku a openvpn clienta na widlich?

Prosim pekne!

[zvukarmiso]

Chces to s pouzitim certifikatu alebo bez neho ?

[telleke]

Klient windows

Kód: Vybrat vše

dev tap
proto tcp-client
remote 111.222.111.222 1194
ca ca.crt
cert client.crt
key client.key
tls-client
port 1194
script-security 2 system
ping 15
ping-restart 45
ping-timer-rem
persist-tun
persist-key
mute-replay-warnings
verb 6
cipher AES-256-CBC
auth SHA1
pull
route 192.168.1.0 255.255.255.0 172.16.1.1 1

Poslední řádek přidává routu do sítě za mikrotikem. 172.16.1.1 je adresa ovpn serveru. Klient má nastavenou adresu 172.16.1.20

V mikrotiku stačí nahrát a "podepsat" certifikáty, nastavit server a v secrets vytvořit profil. Hotovo. Pro přidání routy u Win7 je potřeba spouštět klienta OVPN jako správce.

Bez názvu1.png (66.78 KiB) Zobrazeno 6203 x

[Petr S.]

To Require-client-certificate dělá co? V dokumentech jsem našel, že, aby tohle fungovalo, tak musí mít jak klient, tak i server jak serverový, tak i klientský certifikát. Mě nicméně, když to zapnu, vpn přestane jít.

Mám do mikrotiku nahraný serverový certifikát a svítí u něj "KT". u nahraného CA mi tam ale svítí jen "T", může to být tím, proč mi to nefunguje s tím nastavení require....?

Ještě jedna věc - VPN mi funguje bez problémů z Linuxu na MK, který dělá server. Jakmile dám ale certifikáty na Windows do OVPN GUI klienta, ani se to nespojí, a začne to hlásit, že certifikát neodpovídá. Nechápu. Kdyby byl přece špatný certifikát, neběží to ani v Linuxu ne?

[code]Thu Nov 27 14:01:36 2014 TLS: Initial packet from 82.14.15.9:5000, sid=efcd05cd 7027acfa
Thu Nov 27 14:01:36 2014 VERIFY ERROR: depth=1, error=certificate signature failure: /C=CZ/ST=CA/L=CZ/OU=NET/CN=CZ_CA/name=E ... petr@jk.cz
Thu Nov 27 14:01:36 2014 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Thu Nov 27 14:01:36 2014 TLS Error: TLS object -> incoming plaintext read error
Thu Nov 27 14:01:36 2014 TLS Error: TLS handshake failed
Thu Nov 27 14:01:36 2014 Fatal TLS error (check_tls_errors_co), restarting
Thu Nov 27 14:01:36 2014 TCP/UDP: Closing socket
Thu Nov 27 14:01:36 2014 SIGUSR1[soft,tls-error] received, process restarting
Thu Nov 27 14:01:36 2014 Restart pause, 5 second(s)
Thu Nov 27 14:01:41 2014 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Thu Nov 27 14:01:41 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Nov 27 14:01:41 2014 Re-using SSL/TLS context
Thu Nov 27 14:01:41 2014 Control Channel MTU parms [ L:1559 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Nov 27 14:01:41 2014 Data Channel MTU parms [ L:1559 D:1450 EF:59 EB:4 ET:0 EL:0 ]
Thu Nov 27 14:01:41 2014 Local Options hash (VER=V4): '5cb3f8dc'
Thu Nov 27 14:01:41 2014 Expected Remote Options hash (VER=V4): '898ae6c6'

[Petr Bačina]

Dělá to to, že se musí klient prokázat platným certifikátem a nestačí jenom přihlášení pomocí hesla. Pravděpodobně máš špatný klientský certifikát. Svítící T u CA certifikátu je správně, protože CA je tzv. samopodpisové a není potřeba k němu nahrávat klíč k jeho podepsání.

Tahle konfigurace funguje na
MK server - MK klient
MK server - Win klient
MK server - Linux klient (testováno na debianu)

OpenVPN je vlastně jednoduché nastavit. Jenom je potřeba mít správné certifikáty a pak to jede v pohodě.

[Petr S.]

Certifikáty jsem generoval v linuxu přes openrsa (build-ca, build-dh, build-key-server, build-key). V linuxu mi to pak i jede. Stejne certifikaty jako z linuxu jsem pak prekopiroval i do virtualu s wxp, a tady uz mi to nejede. A hlásí to tu chybu s certifikátem.

Přihlášení pomocí hesla? Takže i bez toho, že bych v konfiguráku nastavil cestu k certifikátům, měl bych se připojit? Takže vlastně klientské certifikáty nepotřebuji? To je trošku zvláštní ne?

Jinak je nutné do CN serverového certifikátu dávat veřejnou IP MK?

[Petr S.]

Tak jsem vygeneroval nové certifikáty a dělá mi to to samé. V linuxu to běhá, ve windows to hlásí špatný certifikát. Netuším už, kde by mohla být chyba.

[Petr Bačina]

A máš ve windows nastavenou správně cestu k cerifikátům?

[Majklik]

Dle toho " error=certificate signature failure" odhad:
Budeš mít ten ceetrifkát podepsán s pomocí MD5 hashe. Klient ve Windows má už aktualizovanou OpenSSL knihovnu, která má používání MD5 zakázanou jako nedostatečnou a brzo bude zakázán i SHA1. Aktuálně frčí při podepisování jen SHA256 a výše.
Stejně to přestane fungovat i na novějších linuxech.

[Petr S.]

Tady by asi mohl být zakopaný pes... Algoritmus podpisu u toho certifikátu co nejde je 1.2.840.113549.1.1.11. U jiných, co mi z Windows jedou, tak je to u některých SHA1RSA, u jiného md5RSA.

Generoval jsem to standardním nastavením OpenSSL po instalaci z EasyRSA. Zkoušel jsem to ze svého starého VirtualBoxu s Windows XP.

EDIT: Tak jsem ještě zjistil, že to číslo nahoře, co tam píšu, tak to hlásí z těch Windows, ale přímo v těle certifikátu je uvedeno sha256withRSAEncryption.

[Majklik]

1.2.840.113549.1.1.11 je SHA256WithRSA. Problém je v tom klientu pro Windows XP, že je starý a nemá SHA256 podporu.
Ty certifikáty s MD5 je lépe už zklikvidovat, novější OpenSSL je odmítají validovat, třeba v RHEL/CentOS6 to jde, v RHEL/CentOS7 už ne (jde si zatím pomocí přes proměnné NSS_HASH_ALG_SUPPORT=+MD5; OPENSSL_ENABLE_MD5_VERIFY=1). A od příštího roku začne postupně eliminace SHA1.
Pokud máš ještě dost WinXP klientů, tak je zatím možno udělat krok zpět a používat SHA1. Existuje i nějaký build OpenVPN pro XPčka s novějším OpenSSL, kde je podporováné SHA256~512, ale netestoval jsem, OpenVPN nepoužívám.

[Petr S.]

Jj, tak je to tím.

Jinak tedy nevíš jak je to s tím ověřováním se certifikátem? Ať už vygeneruju certifikáty jak chci, tak stejně se mi vpn při zaškrtnutí políčka require client certificate nespojí. Když budu chtít, aby více klientů mohlo používat jeden certifikát v jeden okamžik, jde to? Nezávisí to právě na tomhle políčku?

Jinak je nutné do CN serverového certifikátu dávat veřejnou IP MK nebo jeho hostname?

Díky.

[Majklik]

Dokumentace OpenVPN uvádí, že při použití certifikátů musí mít každý klient svůj certifikát. Respektive je můžeš sdílet, ale nesmí se připojit víc klientů naráz.
Při tom požadavku na certifikát klienta se bude ais kontrolovat účel použití, že je to klientský certifikát, takže je třeba si ho vygenerovat s tím účelem. Mrkni, co ti certifikát hlásí u položek X509v3 Key Usage, X509v3 Extended Key Usage, Netscape Cert Type. Asi to bude chtít, aby ten netscape type byl client.
Klientům je jedno, co má server jako CN jméno certifikátu, dokud v klientu nezapneš kontrolu, takže je zvykem jako CN dát to, co mají klienti jako cíl, pokud IP, tak IP, když jméno, tak DNS jméno. A pak je slušnost uvést všechny DNS jmé=na a IP adresy do X509v3 Subject Alternative Name, pak se tne certifikát dá s úspěchem použít i pro jiné serverovské služby. Stejně tak serverový certifikát by měl tvrdit, že je určen pro server, opět jde kontrola v klientu zapnout.
Pokud máš jako klienty Windows a necheš z uživatelů tahat certifikáty pak je jendodušší použít SSTP, klient je součástí Windows Vistaa výše.

[mytrix]

Zdravím, trochu oživím toto téma.

Při konfiguraci OpenVPN na Mikrotiku jsem narazil na problém s certifikáty, který bohužel neumím vyřešit. Jedná se o to, že pokud certifikát obsahuje informace o CRL, pak se nelze vůbec připojit. Jakmile vytvořím certifikáty, které tento údaj neobsahují, pak to funguje.

Podobný problém jsem našel zde https://forum.mikrotik.com/viewtopic.php?t=88372 nicméně nějaké řešení jsem tam nenalezl. Má to někdo zprovozněno v praxi? Díky.