Verify error depth 0 error unsupported certificate purpose mikrotik

OpenVPN Support Forum

Community Support Forum

[Solved]Client failed: unsupported certificate purpose

[Solved]Client failed: unsupported certificate purpose

Post by narke » Tue Mar 31, 2015 2:25 pm

My first try failed when open the client to connect my server.

Server and the client are both running 2.3.6. Keys are created using easyrsk tool acoording
to its documents.

Server starts up normall (showing Initialization Sequence Completed)

Client failed in connecting:

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Socket Buffers: R=[87380->131072] S=[16384->131072]
Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options String: ‘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’
Expected Remote Options String: ‘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’
Local Options hash (VER=V4): ‘69109d17’
Expected Remote Options hash (VER=V4): ‘c0103fa8’
Attempting to establish TCP connection with [AF_INET]59.37.26.98:9005 [nonblock]
TCP connection established with [AF_INET]59.37.26.98:9005
TCPv4_CLIENT link local: [undef]
TCPv4_CLIENT link remote: [AF_INET]59.37.26.98:9005
TLS: Initial packet from [AF_INET]59.37.26.98:9005, sid=a9f7fc71 d6c98d10
VERIFY ERROR: depth=0, error=unsupported certificate purpose: CN=lg_server_dc1
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
Fatal TLS error (check_tls_errors_co), restarting
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 5 second(s)

Server config:
cd /etc/openvpn
ort 9090
proto tcp
dev tun
ca certs/ca.crt
cert certs/lg_server_dc1.crt
key keys/lg_server_dc1.key # This file should be kept secret
dh dh.pem
server 10.11.27.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 5

Client config:
cd /etc/openvpn
client
dev tun
proto tcp
remote 1.2.3.4 9090
resolv-retry infinite
nobind
persist-key
persist-tun
ca certs/ca.crt
cert certs/lg_cp978.crt
key keys/lg_cp978.key
comp-lzo
verb 4

Could you please have look at my case and guess what’ s the possible cause? Thanks in advance!

Источник

Verify error depth 0 error unsupported certificate purpose mikrotik

Fri Nov 13, 2020 11:11 am

I’ve got a router set-up as OVPN server with all the corresponding certificates (which I created locally on the router) and I’ve connected about 20 remote routers to it successfully.
I’m now trying to configure my Windows 10 machine to also use OpenVPN but it refuses to connect, complaining about the certificates. I’ve created new certificates and also tried existing ones but it’s not happy.

Connection looks good till it starts with this .
2020-11-13 10:51:26 VERIFY ERROR: depth=0, error=unsupported certificate purpose: CN=MY-CA, serial=01234567890123456789
2020-11-13 10:51:26 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-11-13 10:51:26 TLS_ERROR: BIO read tls_read_plaintext error
2020-11-13 10:51:26 TLS Error: TLS object -> incoming plaintext read error
2020-11-13 10:51:26 TLS Error: TLS handshake failed
2020-11-13 10:51:26 Fatal TLS error (check_tls_errors_co), restarting

Windows config .
tls-client
pull
remote 1.2.3.4
nobind
dev tun
proto tcp-client
port 1194
ca C:\Users\someone\OpenVPN\config\cert_export_MY-CA.crt
key C:\Users\someone\OpenVPN\config\cert_export_MY-CA.key
cert C:\Users\someone\OpenVPN\config\cert_export_Office.crt
key C:\Users\someone\OpenVPN\config\cert_export_Office.key
;comp-lzo
persist-tun
persist-key
cipher AES-128-CBC
verb 3
#verify-x509-name server name
remote-cert-tls server
#ns-cert-type server
auth SHA1
auth-user-pass
auth-nocache

Re: OVPN Certificate Issue

Fri Nov 13, 2020 11:20 am

the output of `openssl x509 -in C:\Users\someone\OpenVPN\config\cert_export_MY-CA.crt -text` would be helpful, to see what attributes are set in the certificate.

Re: OVPN Certificate Issue

Fri Nov 13, 2020 11:44 am

the output of `openssl x509 -in C:\Users\someone\OpenVPN\config\cert_export_MY-CA.crt -text` would be helpful, to see what attributes are set in the certificate.

Re: OVPN Certificate Issue

Fri Nov 13, 2020 11:52 am

In the meantime opening the certificate from the router, it’s the bare basics .

Key Type: RSA
Key Size: 2048
Trusted
Key Usage: key cert. sign
and a very long fingerprint number.

Re: OVPN Certificate Issue

Fri Nov 13, 2020 2:20 pm

openssl is included with most linux distributions, there will be windows ports available. Alternatively if you double-click a file with a .crt extension on a Windows PC it should launch the crypto shell extensions handler — select the details tab, in the ‘Field’ list find and click on ‘Key Usage’ which should display the usage options in the lower box.

You should not distribute the .key files to clients as anyone possessing them can generate any other certificates they wish signed by your CA.

Re: OVPN Certificate Issue

Fri Nov 13, 2020 3:17 pm

openssl is included with most linux distributions, there will be windows ports available. Alternatively if you double-click a file with a .crt extension on a Windows PC it should launch the crypto shell extensions handler — select the details tab, in the ‘Field’ list find and click on ‘Key Usage’ which should display the usage options in the lower box.

You should not distribute the .key files to clients as anyone possessing them can generate any other certificates they wish signed by your CA.

Opened it via Windows Certificate handler . Key Usage: Certificate Signing (04)

The key files are needed to unlock the certificates, aren’t they? I normally import them, unlock and then delete them.

Re: OVPN Certificate Issue

Fri Nov 13, 2020 4:15 pm

That is OK for the CA certificate itself, the child certificate used by the OVPN server should have encipherment usages present.

No, the private key is used only used by the server. You can encrypt certificates and keys but that is not the same as the private key.

If a certificate is exported from the mikrotik with export-passphrase=MYPASSPHRASE the certificate and corresponding private key are exported encrypted by the passphrase — this should be used to make a backup of certificates if the Mikrotik needs reinstalling.

If a certificate is exported from the mikrotik with no export-passphrase specified only the certificate is exported — this should be distributed to any clients which need to verify the authenticity of the server.

Re: OVPN Certificate Issue

Mon Nov 16, 2020 1:47 pm

That is OK for the CA certificate itself, the child certificate used by the OVPN server should have encipherment usages present.

No, the private key is used only used by the server. You can encrypt certificates and keys but that is not the same as the private key.

If a certificate is exported from the mikrotik with export-passphrase=MYPASSPHRASE the certificate and corresponding private key are exported encrypted by the passphrase — this should be used to make a backup of certificates if the Mikrotik needs reinstalling.

If a certificate is exported from the mikrotik with no export-passphrase specified only the certificate is exported — this should be distributed to any clients which need to verify the authenticity of the server.

Ah ok, the key thing makes more sense now 😅

As for the child certificate having encipherment, I recreated the client certificate to have both key & data encipherment but it still gives me the same error. Do I need to add this to the CA cert also? If so that probably means I’ll have to redo all 30 of my other connections as well, hey?

Re: OVPN Certificate Issue

Mon Nov 16, 2020 2:58 pm

Let me try to explain it in different words.

The whole concept of certificates is based on a cryptographic scheme where encoding and decoding keys are different and the private one cannot be derived from the public one. The public key is part of the certificate data; the private key is normally only available to the certificate holder, which proves its ownership of the certificate by encrypting some random data, provided by the other party, using that key; the other party then uses the public key in the certificate to decrypt those data and find the expected contents.

The key usage is a different thing, and the name is a bit misleading. It is a list of purposes for which the certificate can be used for authentication of its holder. The idea was probably good but the real world implementation is a bit chaotic. For the Windows client to accept the certificate, you apparently need tls-server to be listed in the key-usage list. So it should be sufficient to recreate the server certificate.

The proper way of creating a certificate is to create a CSR (certificate signing request) at the certificate holder device, which also creates the private key as a separate piece of data. Then you deliver the CSR (which does not contain the private key) to the certificate authority, which signs it using its own private key, and delivers the result back to the certified entity. The certified entity then imports the signed certificate, and in the process of import, it links it with the private key generated when creating the CSR. So the private key data never leave the certified entity. The other two pieces of data (the CSR and the signed certificate) may be transported using open channels as their leakage constitutes no compromise of security; the only risk here is that a man in the middle would replace the CSR by an own one, so it would get certified instead of the actual applicant.

When generating the certificate along with the key on another device than the certificate holder, the strong security provided by non-symmetric cryptography becomes dependent on a typically much weaker security of the passphrase used to protect the private key. So every possible effort needs to be taken that the information wouldn’t leak in transport.

Re: OVPN Certificate Issue

Mon Nov 16, 2020 3:54 pm

Let me try to explain it in different words.

The whole concept of certificates is based on a cryptographic scheme where encoding and decoding keys are different and the private one cannot be derived from the public one. The public key is part of the certificate data; the private key is normally only available to the certificate holder, which proves its ownership of the certificate by encrypting some random data, provided by the other party, using that key; the other party then uses the public key in the certificate to decrypt those data and find the expected contents.

The key usage is a different thing, and the name is a bit misleading. It is a list of purposes for which the certificate can be used for authentication of its holder. The idea was probably good but the real world implementation is a bit chaotic. For the Windows client to accept the certificate, you apparently need tls-server to be listed in the key-usage list. So it should be sufficient to recreate the server certificate.

The proper way of creating a certificate is to create a CSR (certificate signing request) at the certificate holder device, which also creates the private key as a separate piece of data. Then you deliver the CSR (which does not contain the private key) to the certificate authority, which signs it using its own private key, and delivers the result back to the certified entity. The certified entity then imports the signed certificate, and in the process of import, it links it with the private key generated when creating the CSR. So the private key data never leave the certified entity. The other two pieces of data (the CSR and the signed certificate) may be transported using open channels as their leakage constitutes no compromise of security; the only risk here is that a man in the middle would replace the CSR by an own one, so it would get certified instead of the actual applicant.

When generating the certificate along with the key on another device than the certificate holder, the strong security provided by non-symmetric cryptography becomes dependent on a typically much weaker security of the passphrase used to protect the private key. So every possible effort needs to be taken that the information wouldn’t leak in transport.

Thanks Sindy, that definitely puts it into perspective.

I am starting to wonder whether my current setup is politically correct. So I have a CA (because I cheated and I’m making/signing my own certificates), Server and Client (actually have a few). So when configuring my OVPN server on my main Mikrotik router, do I specify the CA or the Server certificate (currently have CA selected because if I select Server the clients don’t want to connect)? And on the client side, am I supposed to have only the Client certificate selected under the OVPN client setup (currently have the CA loaded this side too but I see using the Client cert also works)?

The guide I followed was either dodgy or I didn’t understand it at all 🙈😅

Источник

Проблема с настройкой OpenVPN. Что делать?

Здравствуйте. Мне необходима помощь с OpenVPN. Приму любые пинки, сам понимаю что у меня не хватает опыта с этим разобраться (может потому что ещё студент).
Пытаюсь поднять OpenVPN тунель около недели. Было нескольких самостоятельных попыток настроить OpenVPN Server на Mikrotik. Потом всё же решил прибегнуть к гайдам и воспользовался этим:
[url]https://habr.com/ru/post/269679/[/url]
Следовал 2tun и, всё равно не работает, я понимаю что проблема скорее всего с сертификатом (уже гуглил). Но на микротике я несколько раз его пересоздавал. Даже больше. Я где-то вычитал что на Mikrotik есть проблема с сертификатами,то что после неправильной настройки надо начинать заного писать конфиг до начала создания сертификатов.

Tue Dec 13 10:49:57 2022 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=RU, O=XX, OU=IT, CN=ca, serial=7128323427042980667
Tue Dec 13 10:49:57 2022 OpenSSL: error:0A000086:SSL routines::certificate verify failed
Tue Dec 13 10:49:57 2022 TLS_ERROR: BIO read tls_read_plaintext error
Tue Dec 13 10:49:57 2022 TLS Error: TLS object -> incoming plaintext read error
Tue Dec 13 10:49:57 2022 TLS Error: TLS handshake failed
Tue Dec 13 10:49:57 2022 Fatal TLS error (check_tls_errors_co), restarting

Ниже показаны команды настройки на клиенте:

Фаервол настроен. Пробовал так же конфиг с UDP, тоже мимо. PCKS12 вместо PEM не предлагать, ведь данный конфиг надо будет протестировать на Keenetik Start (а туда файл не загрузить).

Источник

Hi,

My first try failed when open the client to connect my server.

Server and the client are both running 2.3.6. Keys are created using easyrsk tool acoording
to its documents.

Server starts up normall (showing Initialization Sequence Completed)

Client failed in connecting:

WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Socket Buffers: R=[87380->131072] S=[16384->131072]
Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Local Options String: ‘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’
Expected Remote Options String: ‘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’
Local Options hash (VER=V4): ‘69109d17’
Expected Remote Options hash (VER=V4): ‘c0103fa8’
Attempting to establish TCP connection with [AF_INET]59.37.26.98:9005 [nonblock]
TCP connection established with [AF_INET]59.37.26.98:9005
TCPv4_CLIENT link local: [undef]
TCPv4_CLIENT link remote: [AF_INET]59.37.26.98:9005
TLS: Initial packet from [AF_INET]59.37.26.98:9005, sid=a9f7fc71 d6c98d10
VERIFY ERROR: depth=0, error=unsupported certificate purpose: CN=lg_server_dc1
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
Fatal TLS error (check_tls_errors_co), restarting
TCP/UDP: Closing socket
SIGUSR1[soft,tls-error] received, process restarting
Restart pause, 5 second(s)

Server config:
cd /etc/openvpn
ort 9090
proto tcp
dev tun
ca certs/ca.crt
cert certs/lg_server_dc1.crt
key keys/lg_server_dc1.key # This file should be kept secret
dh dh.pem
server 10.11.27.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 5

Client config:
cd /etc/openvpn
client
dev tun
proto tcp
remote 1.2.3.4 9090
resolv-retry infinite
nobind
persist-key
persist-tun
ca certs/ca.crt
cert certs/lg_cp978.crt
key keys/lg_cp978.key
comp-lzo
verb 4

Could you please have look at my case and guess what’ s the possible cause? Thanks in advance!

-woody

On May 15, 2020, at 4:27 PM, Martin Mokrejš ***@***.***> wrote:

Hi,
I cannot help myself but the certificates created by easy-rsa (3.0.5 and 3.0.7) cannot be used by openvpn-2.4.9. I see depth=0, error=unsupported certificate purpose: CN=myserver1 error message on the client side logged by openvpn into syslog.

I think some of the required features are not set in teh certificates. Please check the following pages mentioning required attributes:

https://superuser.com/questions/1446201/openvpn-certificate-does-not-have-key-usage-extension <https://superuser.com/questions/1446201/openvpn-certificate-does-not-have-key-usage-extension>
https://superuser.com/questions/738612/openssl-ca-keyusage-extension/1248085#1248085 <https://superuser.com/questions/738612/openssl-ca-keyusage-extension/1248085#1248085>
I think nonRepudiation and keyEncipherment are missing in the client certificate from keyUsage. I have no idea what to hack in easy-rsa scripts to include these.

What I ended up with is:

$ openssl x509 -in myclient1.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a9:80:1b:cc:0e:39:f3:59:d4:b6:0f:c9:f3:19:cb:8c
Signature Algorithm: ecdsa-with-SHA512
Issuer: CN = Easy-RSA CA
Validity
Not Before: May 15 20:38:41 2020 GMT
Not After : May 13 20:38:41 2030 GMT
Subject: CN = myclient1
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:65:86:ec:b4:51:e5:0e:1d:db:67:f9:13:e8:ad:
a5:3a

🆎

f9:9e:c9:ee:6e:90:e6:6a:0f:61:f9:a0:
63:10:60:71:12:ae:1b:6c:6a:d6:2f:61:81:dc:71:
d5:f2:aa:af:1f:1e:c9:67:5f:1a:e9:15:52:0a:92:
c0:27:51:2f:39:2d:9c:a0:2b:6c:6b:93:04:08:6d:
4f:89:c8:97:13:bd:2d:13:ac:6a:d8:89:77:52:e5:
05:fa:28:65:25:d9:f8
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
98:D3:C3:20:C3:10:A4:75:CA:FF:5D:FC:35:55:70:9F:C6:81:13:94
X509v3 Authority Key Identifier:
keyid:ED:FA:C7:67:6D:00:B2:D9:34:A5:61:6A:8C:C4:AB:3B:82:CB:29:1C
DirName:/CN=Easy-RSA CA
serial:FA:82:1F:E7:7B:DC:23:A2

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: ecdsa-with-SHA512
30:65:02:31:00:92:b7:08:4d:08:16:10:8c:12:7c:b9:87:6e:
10:17:cb:e6:9b:f1:c6:11:a8:b0:ce:f1:0e:c9:77:0b:2a:ec:
13:36:df:63:66:49:79:93:4b:3c:1e:29:e4:2c:c2:30:ac:02:
30:4b:09:cb:ee:21:cc:d4:cb:ba:cf:69:a9:d2:24:6a:92:66:
58:76:1c:7d:ba:7e:43:dc:a3:39:13:5f:48:f5:1a:11:ec:35:
6c:2c:04:cb:c5:7b:45:d1:6a:86:e8:54:33
No matter if I use RSA or EC keys.

$ openssl x509 -in myclient1.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
34:3a:96:12:fb

🆎

2c:2d:88:70:12:c7:34:ac:2a:8d
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = Easy-RSA CA
Validity
Not Before: May 15 07:55:42 2020 GMT
Not After : Apr 30 07:55:42 2023 GMT
Subject: CN = myclient1
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:a7:16:d5:d6:f4:7f:7f:98:61:f9:17:69:b9:5e:
b7:3d:b9:9d:b0:9d:81:d5:bf:31:e4:c4:2b:5f:ca:
ac:07:ef:93:ec:7f:20:f2:b5:22:a9:b8:f2:f4:08:
b2:b8:16:67:f7:19:27:40:01:4b:2d:00:fb:91:02:
74:80:3b:bc:93:e3:a9:11:37:86:c6:b1:08:2f:39:
e8:8c:16:2c:18:dc:bf:1c:33:35:4c:f6:90:87:32:
08:5d:04:a5:40:79:7d:b0:fd:69:a2:f1:75:39:8f:
a7:bf:b4:89:f4:4a:99:d5:ce:6a:e4:da:da:4b:a4:
1c:4a:0b:ed:bf:39:91:42:e4:f3:6a:dd:c2:41:98:
fa:9f:13:a1:4a:b2:ad:00:19:33:4c:e9:2b:96:25:
ae:ec:62:a5:f7:18:85:6a:12

🇩🇪

48:42:c9:47:66:
f0:87:42:da:3f:31:33:7a

🆎

5a:75:31:e2:65:80:
aa:eb:69:b9:18:51:e8:4e:b0:12:30:64:31:12:4d:
c0:ee:85:71:4d:56:4b:c0:0d:67:10:33:e9:5d:f8:
dd:fc:f2:ad:47:6e:c1:e6:64:ca:15:c5:86:af:f1:
8e:1e:4a:d9:c0

🇩🇪

04:4c:c0:c4:f3:e3:f9:a9:f6:
61:8e:3c:51:82:23:37:5c:3f:0a

🇩🇪

f5:57:ff:64:
9e:cf
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
C5:81:50:74:25:55:36:AE:58:90:5F:EF:75:94:76:0A:4C:11:9D:3F
X509v3 Authority Key Identifier:
keyid:AC:A8:ED:6E:AB:16:0A:3B:B8:B2:03:79:ED:01:59:F9:15:3F:A1:95
DirName:/CN=Easy-RSA CA
serial:AB:C6:74:86:C4:11:19:1F

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha256WithRSAEncryption
5b:ce:96:00:3c:7c:41

💿

65:32:1d:83:a6:7e:be:f0:88:95:
f2:f2:14:2e:89:4a:61:f1:8b:e2:08:04:d8:c0:6e:0a:2e:6c:
2a:ff:e4:8a:12

🆎

4f:26:dc:cf:69:69:83:b2:46:bf:55:bd:
98:4d:b1:03:19:31:17:ee:a1:03:42:5f:77:c0:4b:5a:ac:e3:
ee:7b:11:8e

🇩🇪

49:45:ec:3c:9f:97:0b:7e:8c:52:76:84:32:
f2:83:1b:be:5c:6c:03:26:d2:2a:4c:2e:4d:60:c0:3a:8d:cc:
2d:4e:9a:bf:48:6c:51:41:88:37:e0:c5:9b:e1:a6:e9:1c:2f:
1e:c3:6c:e7:7d:96:a8:ce:d6:59:a5:26:12:45:d2:85:97:af:
78:7b:6a:37:24:37:3f:ac:87:55:9c:f4:15:8e:fb:34:62:f8:
23:08:b8:01:84:67:9c:e6:76:1d:8c:3d:b2:ba:97:d1:52:3f:
82

💿

a9:e7:84:79:af:8c:11:46:11:1b:71:f6:ca:6e:92:47:
bf:f4:40:b1:9c:0d:d9:86:df:85:55:e0:3d:f6:c0:59:c4:2c:
ab:7d:54:85:97:87:d7:a6:4e:2e:bc:73:86:c0:54:3f:9d:77:
e3:fd:15:4f:a9:d5:ff:52:cf:51:60:5d:f3:98:02:3d:f8:e9:
f2:3b:e9:b7
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#385>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANXQP3BRZC75MSCK5O3ZT3RRWXU3ANCNFSM4NCSOWYQ>.

I have installed a windows 2008 R2 server with OpenVPN with a configuration here attached, and with a mobile client it’s connecting to the server.

When I try to connect a InHand 3G router, I have a TLS error like this post as you can see in the log file attached.

https://forums.openvpn.net/viewtopic.php?t=18550

Tue Jan 29 14:00:43 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018

Tue Jan 29 14:00:43 2019 Windows version 6.1 (Windows 7) 64bit

Tue Jan 29 14:00:43 2019 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10

Enter Management Password:

Tue Jan 29 14:00:43 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343

Tue Jan 29 14:00:43 2019 Need hold release from management interface, waiting…

Tue Jan 29 14:00:44 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343

Tue Jan 29 14:00:44 2019 MANAGEMENT: CMD ‘state on’

Tue Jan 29 14:00:44 2019 MANAGEMENT: CMD ‘log all on’

Tue Jan 29 14:00:44 2019 MANAGEMENT: CMD ‘echo all on’

Tue Jan 29 14:00:44 2019 MANAGEMENT: CMD ‘bytecount 5’

Tue Jan 29 14:00:44 2019 MANAGEMENT: CMD ‘hold off’

Tue Jan 29 14:00:44 2019 MANAGEMENT: CMD ‘hold release’

Tue Jan 29 14:00:44 2019 Diffie-Hellman initialized with 2048 bit key

Tue Jan 29 14:00:44 2019 Outgoing Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication

Tue Jan 29 14:00:44 2019 Incoming Control Channel Authentication: Using 160 bit message hash ‘SHA1’ for HMAC authentication

Tue Jan 29 14:00:44 2019 interactive service msg_channel=0

Tue Jan 29 14:00:44 2019 ROUTE_GATEWAY 10.10.10.1/255.255.255.0 I=11 HWADDR=00:50:56:87:6b:0d

Tue Jan 29 14:00:44 2019 open_tun

Tue Jan 29 14:00:44 2019 TAP-WIN32 device [Connessione alla rete locale (LAN) 2] opened: \.Global{515D7AF9-2A09-48D4-BC61-1553AB97135A}.tap

Tue Jan 29 14:00:44 2019 TAP-Windows Driver Version 9.21

Tue Jan 29 14:00:44 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.1/255.255.255.252 on interface {515D7AF9-2A09-48D4-BC61-1553AB97135A} [DHCP-serv: 10.8.0.2, lease-time: 31536000]

Tue Jan 29 14:00:44 2019 Sleeping for 10 seconds…

Tue Jan 29 14:00:54 2019 Successful ARP Flush on interface [13] {515D7AF9-2A09-48D4-BC61-1553AB97135A}

Tue Jan 29 14:00:54 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

Tue Jan 29 14:00:54 2019 MANAGEMENT: >STATE:1548766854,ASSIGN_IP,,10.8.0.1,,,,

Tue Jan 29 14:00:54 2019 MANAGEMENT: >STATE:1548766854,ADD_ROUTES,,,,,,

Tue Jan 29 14:00:54 2019 C:Windowssystem32route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2

Tue Jan 29 14:00:54 2019 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4

Tue Jan 29 14:00:54 2019 Route addition via IPAPI succeeded [adaptive]

Tue Jan 29 14:00:54 2019 Socket Buffers: R=[8192->8192] S=[8192->8192]

Tue Jan 29 14:00:54 2019 Listening for incoming TCP connection on [AF_INET][undef]:443

Tue Jan 29 14:00:54 2019 TCPv4_SERVER link local (bound): [AF_INET][undef]:443

Tue Jan 29 14:00:54 2019 TCPv4_SERVER link remote: [AF_UNSPEC]

Tue Jan 29 14:00:54 2019 MULTI: multi_init called, r=256 v=256

Tue Jan 29 14:00:54 2019 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0

Tue Jan 29 14:00:54 2019 MULTI: TCP INIT maxclients=60 maxevents=64

Tue Jan 29 14:00:54 2019 Initialization Sequence Completed

Tue Jan 29 14:00:54 2019 MANAGEMENT: >STATE:1548766854,CONNECTED,SUCCESS,10.8.0.1,,,,

Tue Jan 29 14:00:57 2019 TCP connection established with [AF_INET]x.y.w.z:12482

Tue Jan 29 14:00:58 2019 x.y.w.z:12482 TLS: Initial packet from [AF_INET]x.y.w.z:12482, sid=dd09e913 aae7af21

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=IT, ST=GE, L=Genova, O=XXX, OU=changeme, CN=server, name=server, emailAddress=xxx@xxx.com

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 TLS_ERROR: BIO read tls_read_plaintext error

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 TLS Error: TLS object -> incoming plaintext read error

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 TLS Error: TLS handshake failed

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 Fatal TLS error (check_tls_errors_co), restarting

Tue Jan 29 14:01:02 2019 x.y.w.z:12482 SIGUSR1[soft,tls-error] received, client-instance restarting

The server configuration file is :

port 443

proto tcp4

dev tun

ca «C:\Program Files\OpenVPN\config\ca.crt»

cert «C:\Program Files\OpenVPN\config\server.crt»

key «C:\Program Files\OpenVPN\config\server.key»

dh «C:\Program Files\OpenVPN\config\dh2048.pem»

server 10.8.0.0 255.255.255.0

push «route 10.8.0.1 255.255.255.255»

push «route 10.8.0.0 255.255.255.0»

push «dhcp-option DNS 8.8.8.8»

client-to-client

duplicate-cn

keepalive 10 120

tls-auth ta.key 0 # This file is secret

cipher AES-256-CBC

persist-key

persist-tun

status openvpn-status.log

verb 3

With the following client configuration is working

client

dev tun

proto tcp4

remote <my.public.ip> 443

resolv-retry infinite

nobind

persist-key

persist-tun

remote-cert-tls server

cipher AES-256-CBC

key-direction 1

verb 3

<tls-auth>

#

# 2048 bit OpenVPN static key

#

——BEGIN OpenVPN Static key V1——

…

——END OpenVPN Static key V1——

</tls-auth>

<ca>

——BEGIN CERTIFICATE——

…

——END CERTIFICATE——

</ca>

<cert>

——BEGIN CERTIFICATE——

…

——END CERTIFICATE——

</cert>

<key>

——BEGIN PRIVATE KEY——

…

——END PRIVATE KEY——

</key>

I tryed to generate a new client key with no success.

Thanks

StewBla