Brauche Hilfe mit OpenVPN SSL Zertifikaten

S

Serow

0
Hi,

ich habe einen OpenVPN Server zu dem ich nicht verbinden kann. Hier erstmal die Server und Client Konfiguration:

server-split.conf
Code: 
dev tun-split 
proto tcp-server
port 1194
server 10.12.53.0 255.255.255.0 
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/CA_cert.cer
cert /etc/openvpn/keys/openvpn.cer
key /etc/openvpn/keys/openvpn.pem
comp-lzo
keepalive 10 30
persist-tun
tun-mtu 1225
push "route 10.0.0.0 255.255.255.0"

client-split.conf
Code: 
client
proto tcp
port 1194
dev tun-nbgsplit
remote ***********************
ca openvpn.cer
cert mathias-ewald.cer
key mathias-ewald.pem
comp-lzo
keepalive 10 30
persist-tun
tun-mtu 1225
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Auf dem Server habe ich folgende Dateien hinterlegt:
Code: 
-rw-r--r-- 1 root root 2074 2010-12-29 10:18 CA_cert.cer
-rw-r--r-- 1 root root  245 2010-12-29 10:38 dh1024.pem
-rw-r--r-- 1 root root  804 2010-12-29 10:25 dsa_params
-rw-r--r-- 1 root root 1009 2010-12-29 10:19 openvpn.cer
-rw-r--r-- 1 root root 1743 2010-12-29 10:19 openvpn.pem

Auf dem Client habe ich folgende Dateien hinterlegt:
Code: 
-rwx------ 1 mathias mathias 1306 2010-12-29 10:45 mathias-ewald.cer
-rwx------ 1 mathias mathias 1743 2010-12-29 10:45 mathias-ewald.pem
-rw-r--r-- 1 mathias mathias 1009 2010-12-29 10:46 openvpn.cer

CA_Cert.cer ist der Public Key der Root CA. openvpn.cer und openvpn.pem sind Public und Private Keys des OpenVPN Servers welche von der Root CA signiert sind. So jedenfalls mein Verständnis, das ich mir gerade über SSL Zertifikate angelesen habe.

Wenn ich nun auf dem Client eine Verbindung um Server aufbaue sieht das so aus:
Code: 
mathias@x61t:~/openvpn/spiderman$ sudo openvpn --config client-split.conf
Wed Dec 29 11:11:01 2010 OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 12 2010
Wed Dec 29 11:11:01 2010 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Dec 29 11:11:01 2010 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Enter Private Key Password:
Wed Dec 29 11:11:06 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Dec 29 11:11:06 2010 /usr/bin/openssl-vulnkey -q -b 2048 -m <modulus omitted>
Wed Dec 29 11:11:06 2010 LZO compression initialized
Wed Dec 29 11:11:06 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1225)
Wed Dec 29 11:11:06 2010 Attempting to establish TCP connection with [AF_INET]188.98.2.139:1194 [nonblock]
Wed Dec 29 11:11:07 2010 TCP connection established with [AF_INET]188.98.2.139:1194
Wed Dec 29 11:11:07 2010 TCPv4_CLIENT link local: [undef]
Wed Dec 29 11:11:07 2010 TCPv4_CLIENT link remote: [AF_INET]188.98.2.139:1194
Wed Dec 29 11:11:09 2010 Connection reset, restarting [0]
Wed Dec 29 11:11:09 2010 SIGUSR1[soft,connection-reset] received, process restarting
Wed Dec 29 11:11:14 2010 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Dec 29 11:11:14 2010 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Dec 29 11:11:14 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Dec 29 11:11:14 2010 /usr/bin/openssl-vulnkey -q -b 2048 -m <modulus omitted>
Wed Dec 29 11:11:14 2010 LZO compression initialized
Wed Dec 29 11:11:14 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1225)
Wed Dec 29 11:11:14 2010 Attempting to establish TCP connection with [AF_INET]188.98.2.139:1194 [nonblock]
Wed Dec 29 11:11:15 2010 TCP connection established with [AF_INET]188.98.2.139:1194
Wed Dec 29 11:11:15 2010 TCPv4_CLIENT link local: [undef]
Wed Dec 29 11:11:15 2010 TCPv4_CLIENT link remote: [AF_INET]188.98.2.139:1194
Wed Dec 29 11:11:17 2010 Connection reset, restarting [0]
Wed Dec 29 11:11:17 2010 SIGUSR1[soft,connection-reset] received, process restarting

Dabei erzählt der Server das hier:
Code: 
Wed Dec 29 11:10:31 2010 OpenVPN 2.1_rc11 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008
Wed Dec 29 11:10:40 2010 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Dec 29 11:10:40 2010 WARNING: file '/etc/openvpn/keys/openvpn.pem' is group or others accessible
Wed Dec 29 11:10:40 2010 /usr/bin/openssl-vulnkey -q -b 2048 -m <modulus omitted>
Wed Dec 29 11:10:40 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1225)
Wed Dec 29 11:10:40 2010 TUN/TAP device tun-split opened
Wed Dec 29 11:10:40 2010 /sbin/ifconfig tun-split 10.12.53.1 pointopoint 10.12.53.2 mtu 1225
Wed Dec 29 11:10:40 2010 Listening for incoming TCP connection on [undef]:1194
Wed Dec 29 11:10:40 2010 TCPv4_SERVER link local (bound): [undef]:1194
Wed Dec 29 11:10:40 2010 TCPv4_SERVER link remote: [undef]
Wed Dec 29 11:10:40 2010 Initialization Sequence Completed
Wed Dec 29 11:11:07 2010 Re-using SSL/TLS context
Wed Dec 29 11:11:07 2010 LZO compression initialized
Wed Dec 29 11:11:07 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1225)
Wed Dec 29 11:11:07 2010 TCP connection established with 91.9.117.250:37965
Wed Dec 29 11:11:07 2010 TCPv4_SERVER link local: [undef]
Wed Dec 29 11:11:07 2010 TCPv4_SERVER link remote: 91.9.117.250:37965
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 VERIFY ERROR: depth=0, error=self signed certificate: /C=DE/ST=Bavaria/L=Nuremberg/O=Mathias_Ewald/CN=Mathias_Ewald/emailAddress=mathias@mathias-ewald.de
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 TLS Error: TLS handshake failed
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 Fatal TLS error (check_tls_errors_co), restarting
Wed Dec 29 11:11:15 2010 Re-using SSL/TLS context
Wed Dec 29 11:11:15 2010 LZO compression initialized
Wed Dec 29 11:11:15 2010 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1225)
Wed Dec 29 11:11:15 2010 TCP connection established with 91.9.117.250:37192
Wed Dec 29 11:11:15 2010 TCPv4_SERVER link local: [undef]
Wed Dec 29 11:11:15 2010 TCPv4_SERVER link remote: 91.9.117.250:37192
Wed Dec 29 11:11:17 2010 91.9.117.250:37192 VERIFY ERROR: depth=0, error=self signed certificate: /C=DE/ST=Bavaria/L=Nuremberg/O=Mathias_Ewald/CN=Mathias_Ewald/emailAddress=mathias@mathias-ewald.de
Wed Dec 29 11:11:17 2010 91.9.117.250:37192 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Wed Dec 29 11:11:17 2010 91.9.117.250:37192 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 29 11:11:17 2010 91.9.117.250:37192 TLS Error: TLS handshake failed
Wed Dec 29 11:11:17 2010 91.9.117.250:37192 Fatal TLS error (check_tls_errors_co), restarting

Der interssante Teil ist wohl der hier:

Code: 
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 VERIFY ERROR: depth=0, error=self signed certificate: /C=DE/ST=Bavaria/L=Nuremberg/O=Mathias_Ewald/CN=Mathias_Ewald/emailAddress=mathias@mathias-ewald.de
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 TLS Error: TLS object -> incoming plaintext read error
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 TLS Error: TLS handshake failed
Wed Dec 29 11:11:09 2010 91.9.117.250:37965 Fatal TLS error (check_tls_errors_co), restarting

Nagut das Zertifikat ist self-signed - was ja an sich kein Problem sein sollte oder?

ciao
serow
 
Ich habs grad nur überflogen, aber soweit ich weiß und das sehe fehlt im Client das CA_cert.cer..
 
Hi,

bist du dir sicher? Eigentlich ist das CA_cert.cer doch der Public Key der Root CA. Die Root CA hat ein Server Zertifikat ausgestellt (openvpn.cer) von dem aus alle client Zertifikate ausgegeben werden. Dann sollte man doch das der Root CA garnicht brauchen oder?

Grüße
serow
 
Wie hast du die Zertifikate denn erstellt?
Soweit ich mich erinnere hatte ich vor einiger Zeit auch mal Probleme mit OpenVPN und Zertifikaten. Ich habe mir dann mal in der OVPN-Doku den PKI-Teil zu Gemüte geführt und die mitgelieferten build-ca- und build-key-*-Scripte benutzt. Danach hat es afair bei mir geklappt.

Warum verwendest du eigentlich ein TCP-Tunnel und das TUN-Device?
Momentan würden deine Pakete auf IP-Ebene geroutet werden und die TCP-Verbindungen werden ineinander gekapselt. Aufgrund der nun doppelt vorhandenen Fehlerkorrekturfunktionalität von TCP kann das zu Delays und Resets führen.
Wenn du also TCP als Tunnel-Protokoll verwendest, solltest du sicherstellen, dass ein Großteil des Traffics UDP-basierend ist. Zudem würde es dann auch mehr Sinn machen auf Ethernet-Routing umzusteigen, wenn du schon alles in TCP kapselst. ;)
Da ich aber mal davon ausgehe, dass du überwiegend TCP-Dienste (HTTP,FTP,SMTP,usw.) nutzt, wäre es schlauer einen UDP-Tunnel und IP-Routing (also TUN-Device) zu verwenden, damit die gestackten Protkolle sich nicht gegenseitig stören.

Siehe auch hier: http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
 
bist du dir sicher? Eigentlich ist das CA_cert.cer doch der Public Key der Root CA. Die Root CA hat ein Server Zertifikat ausgestellt (openvpn.cer) von dem aus alle client Zertifikate ausgegeben werden. Dann sollte man doch das der Root CA garnicht brauchen oder?
Zum Vergrößern anklicken....

Bei meinem VPN funzt der Client ohne CA_cert.cer jedenfalls nicht.

Du könntest den Verweis aus der Client-Config ändern in CA_cert.cer statt openvpn.cer und die Datei darein kopieren (und bei der server-split.conf openvpn.cer und openvpn.pem entfernen) und den Server nicht zusätzlich mit Public- und Privat-Key versorgen. Teste mal, so funktionierts bei mir zumindest.
 
Hi,

ich versuche mal zurückzuverfolgen, welche Kommandos ich benutzt habe:

Code: 
openssl genrsa -aes256 -out private/cakey.pem 2048
openssl req -new -x509 -days 3650 -key private/cakey.pem -out ca.pem -set_serial 1
touch index.txt && echo "01" > serial
openssl req -new -newkey rsa:2048 -out openvpn_csr.pem -nodes -keyout private/openvpn_key.pem -days 365
openssl x509 -req -in openvpn_csr.pem -out certs/openvpn_cert.pem -CA ca.pem -CAkey private/cakey.pem -CAserial serial -days 365
openssl req -new -newkey rsa:2048 -out mathias.ewald_csr.pem -keyout private/mathias.ewald_key.pem -days 365
openssl x509 -req -in mathias.ewald_csr.pem -out mathias.ewald_cert.pem -CA ca.pem -CAkey private/cakey.pem -CAserial serial -days 365
openssl dhparam -out dh2048.pem 2048

Bitte nicht wunder, dass die Namen plötzlich andere sind als im ersten Posting. Ich habe viel rumgespielt seit dem. Allerdings immernoch derselbe Fehler. In der client.conf habe ich jetzt allerdings das ca.pem drin:

Code: 
tls-client
pull
proto tcp-client
port 1194
dev tun-nbgsplit
remote *******************
resolv-retry infinite
nobind
ca ca.pem
cert mathias.ewald_cert.pem
key mathias.ewald_key.pem
cipher AES-256-CBC
auth SHA1
persist-key
comp-lzo
keepalive 10 30
persist-tun
mute 20
tun-mtu 1225
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Das mit UDP statt TCP werde ich mir mal anschaun. Ich hab beim ersten lesen nicht 100%ig verstanden was du meinst, aber das kommt noch :) Erstmal die Zertifikatsgeschichte ...

ciao
serow
 
In der client.conf habe ich jetzt allerdings das ca.pem drin:
Zum Vergrößern anklicken....

Welches ca.pem? In deinem Ausgangspost finde ich das nicht.
Ich meinte die CA_cert.cer, die auch in der server-split.conf benutzt wird.

Das Serverzertifikat bleibt auch auf dem Server liegen, aber gehört nicht in den Client.

Ein Beispiel meinerseits:
Der Benutzer nick bekommt von mir die Dateien
Code: 
nick_cert.pem
nick_key.pem
vpn-ca.pem

und die Config die so aussieht (die Datei Verweise sind fett markiert):
Code: 
client
float
dev tap

tun-mtu 1500
mssfix

proto udp

#Server:
remote ip port

#WICHTIG: Common Name d. Servercerts
tls-remote vpnserver

[B]ca vpn-ca.pem
cert nick_cert.pem
key nick_key.pem[/B]

auth SHA1
nobind
comp-lzo
persist-key
persist-tun

verb 3

Während der Server folgende Dateien kennt:
Code: 
dh1024.pem
servercert.pem
serverkey.pem
vpn-ca.pem

Seine Config könnte wie folgt aussehen (wieder sind Verweise fett):
Code: 
port portnummer

proto udp
mode server
tls-server

dev tap

#Server IP im VPN
ifconfig 10.0.0.1 255.255.255.0
#Client IPs aus folgendem Pool wählen
ifconfig-pool 10.0.0.2 10.0.0.254

tun-mtu 1500
mssfix

[B]ca vpn-ca.pem
cert servercert.pem
key serverkey.pem[/B]

client-to-client
dh dh1024.pem

ifconfig-pool-persist ipp.txt

keepalive 10 120

auth SHA1

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

verb 3

Ich hoffe das hilft dir.
Diese beiden Configs waren fast 1:1 (halt nur mit echter Serveradresse und echten Portangaben) bis vor kurzem im Einsatz und funktionieren wunderbar unter Linux und Windows (bei letzterem mit entsprechenden Einstellungen im TAP-Adapter).
 
Hi,

ich habe jetzt alle Zertifikate etc gelöscht und nochmal von vorne angefangen (zum 3ten Mal). Wie von geisterhand funktionierts jetzt. Ich hab den Fehler leider nicht gefunden ... Naja ...

ciao
serow
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben