30
Openvpn Server Umzug Client kann sich nicht verbinden
Guten Abend und schönes neues Jahr!
Ich wollte heute meinen Openvpn Server von Debian 8 nach Ubuntu 18.04 umziehen.
Leider kann ich mich mit den Clients nicht verbinden.
Ich bekomme folgende Fehlermeldungen im Logfile des OPENVPN Servers
Woran kann es liegen? Ich habe alle Zertifikate und Keys kopiert.
Danke und schönen Abend
Ich wollte heute meinen Openvpn Server von Debian 8 nach Ubuntu 18.04 umziehen.
Leider kann ich mich mit den Clients nicht verbinden.
Ich bekomme folgende Fehlermeldungen im Logfile des OPENVPN Servers
Wed Jan 1 17:28:49 2020 us=296405 xx.xxx.xxx.101:54923 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Wed Jan 1 17:28:49 2020 us=296752 xx.xxx.xxx.101:54923 TLS_ERROR: BIO read tls_read_plaintext error
Wed Jan 1 17:28:49 2020 us=296970 xx.xxx.xxx.101:54923 TLS Error: TLS object -> incoming plaintext read error
Wed Jan 1 17:28:49 2020 us=297179 xx.xxx.xxx.101:54923 TLS Error: TLS handshake failed
Wed Jan 1 17:28:49 2020 us=297544 xx.xxx.xxx.101:54923 Fatal TLS error (check_tls_errors_co), restarting
Wed Jan 1 17:28:49 2020 us=297908 xx.xxx.xxx.101:54923 SIGUSR1[soft,tls-error] received, client-instance restarting
Wed Jan 1 17:28:49 2020 us=298270 TCP/UDP: Closing socket
Wed Jan 1 17:28:54 2020 us=343449 MULTI: multi_create_instance called
Wed Jan 1 17:28:54 2020 us=344117 Re-using SSL/TLS context
Wed Jan 1 17:28:54 2020 us=344321 LZO compression initializing
Wed Jan 1 17:28:54 2020 us=344793 Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Wed Jan 1 17:28:54 2020 us=345041 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Wed Jan 1 17:28:54 2020 us=345294 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' Danke und schönen Abend
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 530561
Url: https://administrator.de/contentid/530561
Printed on: April 25, 2024 at 12:04 o'clock
30 Comments
Latest comment
Ahoi,
liegen die Zertifikate im richtigen Verzeichnis wie in der Config angegeben? Stimmen die Rechte, bzw. kann OpenVPN darauf zugreifen?
VG
liegen die Zertifikate im richtigen Verzeichnis wie in der Config angegeben? Stimmen die Rechte, bzw. kann OpenVPN darauf zugreifen?
VG
Der Server sagt
Wed Jan 1 18:33:12 2020 us=137616 Initialization Sequence Completed
Also gehe ich davon aus das Der Server zugreifen kann
Wed Jan 1 18:33:12 2020 us=137616 Initialization Sequence Completed
Also gehe ich davon aus das Der Server zugreifen kann
Servus,
Tante Google spuckt jede Menge zu "error:1417C086:SSL" aus.
Henere
Tante Google spuckt jede Menge zu "error:1417C086:SSL" aus.
Henere
JA aber ich begreife nicht woran es liegt.
Die einen Sagen das es wegen der selbst generierten Zertifikate zu tun hat aber so ganz kapier ich es nicht
Die einen Sagen das es wegen der selbst generierten Zertifikate zu tun hat aber so ganz kapier ich es nicht
Hallo,
normalerweise klappt das .
Schau noch mal nach, daß Rechte und Owner (also die Nummer) passen.
Klappt eigentlich wenn man alle Zertifikate kopiert (incl. Serverzertifikat und Root Zertifikat), gibt max ein Warning wegen "unpassendem Namen".
Ansonsten schau mal wegen der Configuration und openVPN Version.
Klappt auch bei debian8/9/10, IPFire, IPcop . openWRT - sind immer ganz andere Pfade, muß man alles anpassen, dann tut es wieder.
Duu darst natürlich keine neue CA generieren
[bei nicht selbst generierten Zertifikaten hast du ja eine "externe" CA]
Fred
normalerweise klappt das .
Schau noch mal nach, daß Rechte und Owner (also die Nummer) passen.
Klappt eigentlich wenn man alle Zertifikate kopiert (incl. Serverzertifikat und Root Zertifikat), gibt max ein Warning wegen "unpassendem Namen".
Ansonsten schau mal wegen der Configuration und openVPN Version.
Klappt auch bei debian8/9/10, IPFire, IPcop . openWRT - sind immer ganz andere Pfade, muß man alles anpassen, dann tut es wieder.
Duu darst natürlich keine neue CA generieren
[bei nicht selbst generierten Zertifikaten hast du ja eine "externe" CA]Fred
Zitat von @fredmy:
Hallo,
normalerweise klappt das .
Schau noch mal nach, daß Rechte und Owner (also die Nummer) passen.
Klappt eigentlich wenn man alle Zertifikate kopiert (incl. Serverzertifikat und Root Zertifikat), gibt max ein Warning wegen "unpassendem Namen".
Ansonsten schau mal wegen der Configuration und openVPN Version.
Klappt auch bei debian8/9/10, IPFire, IPcop . openWRT - sind immer ganz andere Pfade, muß man alles anpassen, dann tut es wieder.
Duu darst natürlich keine neue CA generieren [bei nicht selbst generierten Zertifikaten hast du ja eine "externe" CA]
Fred
Hallo,
normalerweise klappt das .
Schau noch mal nach, daß Rechte und Owner (also die Nummer) passen.
Klappt eigentlich wenn man alle Zertifikate kopiert (incl. Serverzertifikat und Root Zertifikat), gibt max ein Warning wegen "unpassendem Namen".
Ansonsten schau mal wegen der Configuration und openVPN Version.
Klappt auch bei debian8/9/10, IPFire, IPcop . openWRT - sind immer ganz andere Pfade, muß man alles anpassen, dann tut es wieder.
Duu darst natürlich keine neue CA generieren
[bei nicht selbst generierten Zertifikaten hast du ja eine "externe" CA]Fred
Welche Rechte meinst du im Detail?
Danke für die Hilfe Lisa
Hallo Lisa,
wie geschrieben
Owner/gruppen ID
und Rechte ( rwx)
wobei Rechte passen sollten, bei den Owner/Gruppen-IDs bin ich mir nicht so sicher, (vielleicht auch weil ich Umzüge von IPCop(IPFire zu debian(raspi) gemnacht habe)
Steht aber im Serverlog (falls du eins extra für openVPN eingerichtet hast) ansonsten im Systemlog.
Ich tendiere zum Suchen dazu mittels " tail -f ..." immer aktuell mitzulesen, was da passiert , wenn man mit dem Testclient eine Verbindung aufbaut.
Fred
wie geschrieben
Owner/gruppen ID
und Rechte ( rwx)
wobei Rechte passen sollten, bei den Owner/Gruppen-IDs bin ich mir nicht so sicher, (vielleicht auch weil ich Umzüge von IPCop(IPFire zu debian(raspi) gemnacht habe)
Steht aber im Serverlog (falls du eins extra für openVPN eingerichtet hast) ansonsten im Systemlog.
Ich tendiere zum Suchen dazu mittels " tail -f ..." immer aktuell mitzulesen, was da passiert , wenn man mit dem Testclient eine Verbindung aufbaut.
Fred
Die einen Sagen das es wegen der selbst generierten Zertifikate zu tun hat
Nein, das ist Unsinn...vergiss das ! Damit hat es nichts zu tun.Du hast vermutlich vergessen die CA mitzukopieren, kann das sein ?
den Server hast du mit systemctl restart openvpn... nach dem Kopieren neu gestartet ?
Hilfreich wäre mal die Konfig Datei....
Zitat von @aqui:
Du hast vermutlich vergessen die CA mitzukopieren, kann das sein ?
den Server hast du mit systemctl restart openvpn... nach dem Kopieren neu gestartet ?
Hilfreich wäre mal die Konfig Datei....
Die einen Sagen das es wegen der selbst generierten Zertifikate zu tun hat
Nein, das ist Unsinn...vergiss das ! Damit hat es nichts zu tun.Du hast vermutlich vergessen die CA mitzukopieren, kann das sein ?
den Server hast du mit systemctl restart openvpn... nach dem Kopieren neu gestartet ?
Hilfreich wäre mal die Konfig Datei....
ich habe die Ca mit kopiert. ich habe Openvpn neu gestartet und auch die ganze VPS.
port 443
proto tcp-server
dev tun0
ca /etc/openvpn/keys/blabla/ca.crt
cert /etc/openvpn/keys/blabla/server.crt
key /etc/openvpn/keys/blabla/server.key
dh /etc/openvpn/keys/blabla/dh4096.pem
topology subnet
server 10.1.1.0 255.255.255.0
crl-verify /etc/openvpn/keys/blabla/crl.pem
cipher AES-128-CBC
user nobody
group nogroup
verb 5
mute 20
max-clients 100
local vpn.xxxxxxx.eu
keepalive 10 120
client-config-dir /etc/openvpn/servers/server2/ccd
comp-lzo
persist-key
persist-tun
ccd-exclusive
Alle Dateien im Zertifikatsordner haben -rw-r--r-- 1 root root
Reicht das?
Danke für die Hilfe
Reicht das?
Danke für die Hilfe
Hallo,
gib noch mal den "unteren" Teil der client.config
(also Alles was entfernt mit Auth zu tun hat)
proto, remote, dev usw. kannste weglassen
Und die openVPN Version (ggfs. nochmal)
Fred
gib noch mal den "unteren" Teil der client.config
(also Alles was entfernt mit Auth zu tun hat)
proto, remote, dev usw. kannste weglassen
Und die openVPN Version (ggfs. nochmal)
Fred
Zitat von @fredmy:
Hallo,
gib noch mal den "unteren" Teil der client.config
(also Alles was entfernt mit Auth zu tun hat)
proto, remote, dev usw. kannste weglassen
Und die openVPN Version (ggfs. nochmal)
Fred
Bitte schönHallo,
gib noch mal den "unteren" Teil der client.config
(also Alles was entfernt mit Auth zu tun hat)
proto, remote, dev usw. kannste weglassen
Und die openVPN Version (ggfs. nochmal)
Fred
client
proto tcp-client
dev tun
ca ca.crt
dh dh4096.pem
cert xxx.crt
key xxx.key
remote vpn.xxxxx.eu 443
cipher AES-128-CBC
verb 2
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind
In der Client Konfig fehlen die folgenden Kommandos:
auth-nocache
tls-client
remote-cert-tls server
Das dh dh4096.pem solltest du aus dem Client entfernen, da es überflüssig ist.
Damit sollte es dann eigentlich klappen.
Füge die mal hinzu und poste den Message Ouptut des OVPN Clients hier.
auth-nocache
tls-client
remote-cert-tls server
Das dh dh4096.pem solltest du aus dem Client entfernen, da es überflüssig ist.
Damit sollte es dann eigentlich klappen.
Füge die mal hinzu und poste den Message Ouptut des OVPN Clients hier.
Hallo habe nun versucht in der config des testclient die
einzufügen.
Aber leider funktioniert es immer noch nicht.
Das Log des Client sieht so aus
Das Log des Servers sieht so aus
Ich verstehe es nicht da auf dem anderen Server die Config ohne Probleme läuft.
auth-nocache
tls-client
remote-cert-tls server Aber leider funktioniert es immer noch nicht.
Das Log des Client sieht so aus
Fri Jan 03 15:55:39 2020 us=483839 show_tls_ciphers = DISABLED
Fri Jan 03 15:55:39 2020 us=483839 connect_retry_max = 0
Fri Jan 03 15:55:39 2020 us=483839 Connection profiles :
Fri Jan 03 15:55:39 2020 us=483839 proto = tcp-client
Fri Jan 03 15:55:39 2020 us=483839 local = '[UNDEF]'
Fri Jan 03 15:55:39 2020 us=483839 local_port = '[UNDEF]'
Fri Jan 03 15:55:39 2020 us=483839 remote = 'vpn.xxxxxx.eu'
Fri Jan 03 15:55:39 2020 us=483839 remote_port = '443'
Fri Jan 03 15:55:39 2020 us=483839 remote_float = ENABLED
Fri Jan 03 15:55:39 2020 us=483839 bind_defined = DISABLED
Fri Jan 03 15:55:39 2020 us=483839 bind_local = DISABLED
Fri Jan 03 15:55:39 2020 us=483839 bind_ipv6_only = DISABLED
Fri Jan 03 15:55:39 2020 us=483839 NOTE: --mute triggered...
Fri Jan 03 15:55:39 2020 us=483839 275 variation(s) on previous 20 message(s) suppressed by --mute
Fri Jan 03 15:55:39 2020 us=483839 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Fri Jan 03 15:55:39 2020 us=483839 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Jan 03 15:55:39 2020 us=483839 library versions: OpenSSL 1.1.0j 20 Nov 2018, LZO 2.10
Enter Management Password:
Fri Jan 03 15:55:39 2020 us=484839 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25351
Fri Jan 03 15:55:39 2020 us=484839 Need hold release from management interface, waiting...
Fri Jan 03 15:55:39 2020 us=944023 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25351
Fri Jan 03 15:55:40 2020 us=45213 MANAGEMENT: CMD 'state on'
Fri Jan 03 15:55:40 2020 us=45213 MANAGEMENT: CMD 'log all on'
Fri Jan 03 15:55:40 2020 us=92192 MANAGEMENT: CMD 'echo all on'
Fri Jan 03 15:55:40 2020 us=94175 MANAGEMENT: CMD 'bytecount 5'
Fri Jan 03 15:55:40 2020 us=96196 MANAGEMENT: CMD 'hold off'
Fri Jan 03 15:55:40 2020 us=98195 MANAGEMENT: CMD 'hold release'
Fri Jan 03 15:55:40 2020 us=103194 LZO compression initializing
Fri Jan 03 15:55:40 2020 us=103194 Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Fri Jan 03 15:55:40 2020 us=103194 MANAGEMENT: >STATE:1578063340,RESOLVE,,,,,,
Fri Jan 03 15:55:40 2020 us=108194 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Fri Jan 03 15:55:40 2020 us=109179 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Fri Jan 03 15:55:40 2020 us=109179 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Fri Jan 03 15:55:40 2020 us=109179 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xxx.xxx.xxx:443
Fri Jan 03 15:55:40 2020 us=109179 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Jan 03 15:55:40 2020 us=109179 Attempting to establish TCP connection with [AF_INET]xx.xxx.xxx.xxx:443 [nonblock]
Fri Jan 03 15:55:40 2020 us=109179 MANAGEMENT: >STATE:1578063340,TCP_CONNECT,,,,,,
Fri Jan 03 15:55:41 2020 us=110136 TCP connection established with [AF_INET]xx.xxx.xxx.xxx:443
Fri Jan 03 15:55:41 2020 us=110136 TCP_CLIENT link local: (not bound)
Fri Jan 03 15:55:41 2020 us=110136 TCP_CLIENT link remote: [AF_INET]xx.xxx.xxx.xxx:443
Fri Jan 03 15:55:41 2020 us=110136 MANAGEMENT: >STATE:1578063341,WAIT,,,,,,
Fri Jan 03 15:55:41 2020 us=131404 MANAGEMENT: >STATE:1578063341,AUTH,,,,,,
Fri Jan 03 15:55:41 2020 us=131404 TLS: Initial packet from [AF_INET]xx.xxx.xxx.xxx:443, sid=49e3f7ec 5d32441f
Fri Jan 03 15:55:41 2020 us=242926 VERIFY OK: depth=1, C=IT, ST=BZ, L=Truden, O=My Org, emailAddress=xxxxxx@gmail.com
Fri Jan 03 15:55:41 2020 us=243929 VERIFY KU OK
Fri Jan 03 15:55:41 2020 us=243929 Validating certificate extended key usage
Fri Jan 03 15:55:41 2020 us=243929 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Jan 03 15:55:41 2020 us=243929 VERIFY EKU OK
Fri Jan 03 15:55:41 2020 us=243929 VERIFY OK: depth=0, C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=server2019, emailAddress=xxxxxxx@gmail.com
Fri Jan 03 15:55:41 2020 us=300126 Connection reset, restarting
Fri Jan 03 15:55:41 2020 us=300126 TCP/UDP: Closing socket
Fri Jan 03 15:55:41 2020 us=301063 SIGUSR1[soft,connection-reset] received, process restarting
Fri Jan 03 15:55:41 2020 us=301063 MANAGEMENT: >STATE:1578063341,RECONNECTING,connection-reset,,,,,
Fri Jan 03 15:55:41 2020 us=301063 Restart pause, 5 second(s)
Fri Jan 03 15:55:43 2020 us=302202 SIGTERM[hard,init_instance] received, process exiting
Fri Jan 03 15:55:43 2020 us=302202 MANAGEMENT: >STATE:1578063343,EXITING,init_instance,,,,,Fri Jan 3 15:55:29 2020 us=134301 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Fri Jan 3 15:55:29 2020 us=135323 Could not determine IPv4/IPv6 protocol. Using AF_INET
Fri Jan 3 15:55:29 2020 us=135431 Socket Buffers: R=[87380->87380] S=[16384->16384]
Fri Jan 3 15:55:29 2020 us=135468 Listening for incoming TCP connection on [AF_INET]xx.xxx.xxx.xxx:443
Fri Jan 3 15:55:29 2020 us=137181 TCPv4_SERVER link local (bound): [AF_INET]xx.xxx.xxx.xxx:443
Fri Jan 3 15:55:29 2020 us=137209 TCPv4_SERVER link remote: [AF_UNSPEC]
Fri Jan 3 15:55:29 2020 us=142817 MULTI: multi_init called, r=256 v=256
Fri Jan 3 15:55:29 2020 us=143106 IFCONFIG POOL: base=10.98.1.4 size=62, ipv6=0
Fri Jan 3 15:55:29 2020 us=143226 MULTI: TCP INIT maxclients=100 maxevents=104
Fri Jan 3 15:55:29 2020 us=143334 Initialization Sequence Completed
Fri Jan 3 15:55:40 2020 us=132603 MULTI: multi_create_instance called
Fri Jan 3 15:55:40 2020 us=132867 Re-using SSL/TLS context
Fri Jan 3 15:55:40 2020 us=132914 LZO compression initializing
Fri Jan 3 15:55:40 2020 us=133526 Control Channel MTU parms [ L:1624 D:1210 EF:40 EB:0 ET:0 EL:3 ]
Fri Jan 3 15:55:40 2020 us=133628 Data Channel MTU parms [ L:1624 D:1450 EF:124 EB:406 ET:0 EL:3 ]
Fri Jan 3 15:55:40 2020 us=133726 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Fri Jan 3 15:55:40 2020 us=133746 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Fri Jan 3 15:55:40 2020 us=133856 TCP connection established with [AF_INET]xxx.xxx.xxx.xxx:49467
Fri Jan 3 15:55:40 2020 us=133873 TCPv4_SERVER link local: (not bound)
Fri Jan 3 15:55:40 2020 us=133884 TCPv4_SERVER link remote: [AF_INET]xxx.xxx.xxx.xxx:49467
Fri Jan 3 15:55:41 2020 us=99838 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [14] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Fri Jan 3 15:55:41 2020 us=100086 xxx.xxx.xxx.xxx:49467 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:49467, sid=1ecf7215 d79c102d
Fri Jan 3 15:55:41 2020 us=100204 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [26] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Fri Jan 3 15:55:41 2020 us=120690 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [22] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_ACK_V1 kid=0 [ 0 ]
Fri Jan 3 15:55:41 2020 us=193203 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [174] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=160
Fri Jan 3 15:55:41 2020 us=210410 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [1196] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=1170
Fri Jan 3 15:55:41 2020 us=210666 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [1184] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1170
Fri Jan 3 15:55:41 2020 us=210802 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [1184] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1170
Fri Jan 3 15:55:41 2020 us=210912 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [570] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=556
Fri Jan 3 15:55:41 2020 us=231020 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [22] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_ACK_V1 kid=0 [ 1 ]
Fri Jan 3 15:55:41 2020 us=250281 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [22] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_ACK_V1 kid=0 [ 2 ]
Fri Jan 3 15:55:41 2020 us=250605 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [22] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_ACK_V1 kid=0 [ 3 ]
Fri Jan 3 15:55:41 2020 us=260604 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [1196] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ 4 ] pid=2 DATA len=1170
Fri Jan 3 15:55:41 2020 us=260941 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [22] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_ACK_V1 kid=0 [ 2 ]
Fri Jan 3 15:55:41 2020 us=261203 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [1184] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=1170
Fri Jan 3 15:55:41 2020 us=261553 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER WRITE [22] to [AF_INET]xxx.xxx.xxx.xxx:49467: P_ACK_V1 kid=0 [ 3 ]
Fri Jan 3 15:55:41 2020 us=261738 xxx.xxx.xxx.xxx:49467 TCPv4_SERVER READ [1184] from [AF_INET]xxx.xxx.xxx.xxx:49467: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=1170
Fri Jan 3 15:55:41 2020 us=262362 xxx.xxx.xxx.xxx:49467 VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Fri Jan 3 15:55:41 2020 us=262651 xxx.xxx.xxx.xxx:49467 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Fri Jan 3 15:55:41 2020 us=262806 xxx.xxx.xxx.xxx:49467 TLS_ERROR: BIO read tls_read_plaintext error
Fri Jan 3 15:55:41 2020 us=262960 xxx.xxx.xxx.xxx:49467 TLS Error: TLS object -> incoming plaintext read error
Fri Jan 3 15:55:41 2020 us=263066 xxx.xxx.xxx.xxx:49467 TLS Error: TLS handshake failed
Fri Jan 3 15:55:41 2020 us=263338 xxx.xxx.xxx.xxx:49467 Fatal TLS error (check_tls_errors_co), restarting
Fri Jan 3 15:55:41 2020 us=263458 xxx.xxx.xxx.xxx:49467 SIGUSR1[soft,tls-error] received, client-instance restarting
Fri Jan 3 15:55:41 2020 us=263709 TCP/UDP: Closing socket
Irgendwas ist da beim Kopieren schief gelaufen. Die TLS Errors zeigen ganz klar das irgendwas mit den Zertifikaten nicht stimmt.
Im Zweifel löschen und auf dem Server neu generieren. Das ist eh der sicherste Weg.
Im Zweifel löschen und auf dem Server neu generieren. Das ist eh der sicherste Weg.
Hmm ich habe ein Zip erstellt und auf meinen Pc kopiert und das Zip dann wieder auf den neuen Server geschoben.
Kann es ja mal direkt versuchen.
Ich muss die Daten kopieren denn ich komme nicht an alle Clients ran um die Zertifikate auszutauschen.
Ich vermute auf dem neuen Server stimmt etwas mit dem TLS nicht.
bin so langsam am verzweifeln
Kann es ja mal direkt versuchen.
Ich muss die Daten kopieren denn ich komme nicht an alle Clients ran um die Zertifikate auszutauschen.
Ich vermute auf dem neuen Server stimmt etwas mit dem TLS nicht.
bin so langsam am verzweifeln
noch ein Update.
Habe den Server nochmal neu aufgesetzt und openvpn neu installiert und per Konsole vom Funktionierenden zum neuen Server die Daten kopiert.
Genau der gleiche Mist.
Also ich vermute es muss was mit der Version der Tls zu tun haben
Habe den Server nochmal neu aufgesetzt und openvpn neu installiert und per Konsole vom Funktionierenden zum neuen Server die Daten kopiert.
Genau der gleiche Mist.
Also ich vermute es muss was mit der Version der Tls zu tun haben
Noch ein Update.
Ich habe nun auf dem neuen Server Debian 8 installiert und dort OpenVpn installiert die Konfig kopiert und alles funktioniert.
Irgendwas muss am neuen Betriebssystem anders sein.
Wie finde ich was anders ist?
Ich habe nun auf dem neuen Server Debian 8 installiert und dort OpenVpn installiert die Konfig kopiert und alles funktioniert.
Irgendwas muss am neuen Betriebssystem anders sein.
Wie finde ich was anders ist?
Die Funktionierende Installation ist 2.3.4-5+deb8u2
Hingegen auf Ubuntu 18.04 ist 2.4.4-2ubuntu1.3 installiert
Hat sich da was geändert?
Kann es auch an der Client Version liegen?
Hingegen auf Ubuntu 18.04 ist 2.4.4-2ubuntu1.3 installiert
Hat sich da was geändert?
Kann es auch an der Client Version liegen?
Eigentlich nicht. Relevant ist einzig nur die OpenVPN Version !! Wenn die gleich ist, ist logischerweise auch immer die Konfig Syntax gleich. Das Verhalten hängt dann allein nur von der Konfig ab.
Aktuell ist die Version 2.4.8 Siehe: https://openvpn.net/community-downloads/
DAS hätte das Problem sofort gelöst.
Aktuell ist die Version 2.4.8 Siehe: https://openvpn.net/community-downloads/
Habe den Server nochmal neu aufgesetzt
Was du aber vermutlich NICHT gemacht hast ist zusätzlich zur Neuinstallation auch neue Zertifikate zu generieren, oder ?DAS hätte das Problem sofort gelöst.
Was du aber vermutlich NICHT gemacht hast ist zusätzlich zur Neuinstallation auch neue Zertifikate zu generieren, oder ?
DAS hätte das Problem sofort gelöst.
Ne ich will unbedingt die Zertifikate behalten.DAS hätte das Problem sofort gelöst.
Komme nicht an alle Clients ran.
Wenn ich die Zertifikate manuell prüfe
dann werden auf beiden Servern ok gesagt.
Wie kann das sein
dann werden auf beiden Servern ok gesagt.
Das ergebnis auf beiden Systemen ist das Selbe.
root@xxxxxxx:/# openssl verify -CAfile /etc/openvpn/keys/2019ca/ca.crt /etc/openvpn/keys/2019ca/server.crt
/etc/openvpn/keys/2019ca/server.crt: OK
root@xxxxxxx:/# openssl verify -CAfile /etc/openvpn/keys/2019ca/ca.crt /etc/openvpn/keys/2019ca/client.crt
/etc/openvpn/keys/2019ca/client.crt: OK
root@xxxxxxx:/#Wie kann das sein
Etwas was da noch auffällig ist:
VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Besagt ja das da irgendwas "expired" ist also zeitlich abgelaufen.
Da gibt es zwei Möglichkeiten:
Hast du das mal mit date abgefragt auf dem Server ?
Ubuntu nutzt systemd ! Du solltest also tunlichst dort einen entsprechenden NTP Server https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html in der Datei /etc/systemd/timesyncd.conf einstellen damit der Server (und auch der Client) immer eine korrekte Uhrzeit hat die zu deiner Zeitzone passt in der du die Zertifikate erzeugt hast !!
https://wiki.ubuntuusers.de/systemd/timesyncd/
Z.B.
[Time]
NTP=ntps1-0.cs.tu-berlin.de ntp0.fau.de
FallbackNTP=0.de.pool.ntp.org
VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Besagt ja das da irgendwas "expired" ist also zeitlich abgelaufen.
Da gibt es zwei Möglichkeiten:
- Die Zertifikate sind abgelaufen oder wurden als default übernommen mit falscher Gültigkeit !
- Die Uhrzeit des Servers oder Clients stimmt nicht !
Hast du das mal mit date abgefragt auf dem Server ?
Ubuntu nutzt systemd ! Du solltest also tunlichst dort einen entsprechenden NTP Server https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html in der Datei /etc/systemd/timesyncd.conf einstellen damit der Server (und auch der Client) immer eine korrekte Uhrzeit hat die zu deiner Zeitzone passt in der du die Zertifikate erzeugt hast !!
https://wiki.ubuntuusers.de/systemd/timesyncd/
Z.B.
[Time]
NTP=ntps1-0.cs.tu-berlin.de ntp0.fau.de
FallbackNTP=0.de.pool.ntp.org
Zitat von @aqui:
Etwas was da noch auffällig ist:
VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Besagt ja das da irgendwas "expired" ist also zeitlich abgelaufen.
Nicht "irgendwas", sondern genau gesagt die CRL (Certificate Revocation List) deiner CA ist abgelaufen. Die URL für diese Liste wird im Zertifikat hinterlegt und sollte von Clients und Server gleichermaßen erreichbar und natürlich nicht abgelaufen sein.Etwas was da noch auffällig ist:
VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Besagt ja das da irgendwas "expired" ist also zeitlich abgelaufen.
Also erstelle auf deiner CA eine aktuelle CRL für deine CA und stelle sicher das die URL für diese Liste von den Clients und dem Server erreichbar ist und abgerufen werden kann!
Danke genau das war das Problem.
Jetzt funktioniert es!
Jetzt funktioniert es!
Zitat von @142232:
Also erstelle auf deiner CA eine aktuelle CRL für deine CA und stelle sicher das die URL für diese Liste von den Clients und dem Server erreichbar ist und abgerufen werden kann!
Was macht die CRL genau?Zitat von @aqui:
Etwas was da noch auffällig ist:
VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Besagt ja das da irgendwas "expired" ist also zeitlich abgelaufen.
Nicht "irgendwas", sondern genau gesagt die CRL (Certificate Revocation List) deiner CA ist abgelaufen. Die URL für diese Liste wird im Zertifikat hinterlegt und sollte von Clients und Server gleichermaßen erreichbar und natürlich nicht abgelaufen sein.Etwas was da noch auffällig ist:
VERIFY ERROR: depth=0, error=CRL has expired: C=IT, ST=BZ, L=Truden, O=My Org, OU=Office, CN=xxx, emailAddress=xxxxxxx@gmail.com
Besagt ja das da irgendwas "expired" ist also zeitlich abgelaufen.
Also erstelle auf deiner CA eine aktuelle CRL für deine CA und stelle sicher das die URL für diese Liste von den Clients und dem Server erreichbar ist und abgerufen werden kann!
Wie der Name ja schon sagt. Darin werden die Zertifikate bzw. deren IDs hinterlegt die von der CA zurückgezogen und als ungültig markiert worden sind.
Anhand dieser Liste kann ein Server oder Client feststellen ob ein Zertifikat noch gültig ist oder eben nicht.
Anhand dieser Liste kann ein Server oder Client feststellen ob ein Zertifikat noch gültig ist oder eben nicht.
Ist vermutlich auf dem alten Server vorhanden wurde aber auf dem neuen vergessen zu kopieren oder eine falsche belassen ?!
Zitat von @aqui:
Ist vermutlich auf dem alten Server vorhanden wurde aber auf dem neuen vergessen zu kopieren oder eine falsche belassen ?!
Habe Sie kopiert aber leider hatte sie auf dem neuen Server nicht mehr funktioniert.Ist vermutlich auf dem alten Server vorhanden wurde aber auf dem neuen vergessen zu kopieren oder eine falsche belassen ?!
