Hi All

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

Any ideas?

Thanks,
R

error=unsupported certificate purpose

this.

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.

error=unsupported certificate purpose

this.

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.

Where/how do I run this query?

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.

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.

Where/how do I run this query?

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.

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.

Where/how do I run this query?

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.

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

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

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

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.

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

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

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

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?

Thanks,
R

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 🙈😅

The OVPN server should have its own server certificate, not the self-signed CA, selected. The private key for the server certificate must also be present.

The CA certificate, and any intermediate certificates if used, must also exist on the server Mikrotik. They will be present if you generated the certificates on that Mikrotik, otherwise they should be imported, without private keys, from wherever they were generated.

An important setting on OVPN clients is verify-server-certificate=yes as unless the server certificate is what you expect man-in-the-middle attacks are trivial. The CA certificate, again without private key, should be imported to the client Mikrotik - this allows the client to verify the server before handing over the username and password.

Client certificates are optional, they permit the server to check the client has both a valid certificate and username/password. If used, they must each be installed on the client Mikrotiks with with their private key and the server told to require client certificates.

The majority of third-party websites / videos are often outdated and/or present less than optimal / insecure suggestions. Stick to the Mikrotik help pages / wiki, MUM presentations and the forum.

Ok, I'm getting my head around this, thanks 😉

So my setup is like this now ...

Create CA certificate, key usage “crl sign”, “key cert sign”. Sign certificate. Make trusted.
Create Server certificate, key usage “digital signature”, “key enchipherment”, “tls server”. Sign with CA certificate. Make Trusted.
Create Client certificate, key usage “tls client”. Sign with CA certificate. Make trusted.

Set Server certificate on OVPN server.
Import the CA & Client (with key) certificates into client. Set Client certificate in client connection.


This setup works Mikrotik to Mikrotik but still getting this when trying from Windows ....

2020-11-18 10:15:57 Validating certificate extended key usage
2020-11-18 10:15:57 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2020-11-18 10:15:57 VERIFY EKU OK
2020-11-18 10:15:57 VERIFY OK: depth=0, CN=Server
2020-11-18 10:16:12 Connection reset, restarting [0]
2020-11-18 10:16:12 SIGUSR1[soft,connection-reset] received, process restarting
2020-11-18 10:16:12 MANAGEMENT: >STATE:1605687372,RECONNECTING,connection-reset,,,,,
2020-11-18 10:16:12 Restart pause, 5 second(s)

Finally occurred to me to check the logs 🤦‍♂️ ended up being a TUN / TAP conflict, all working now 👍

Thanks again 😉

I would never have guessed that this might be the problem.