SparkLabs Forum.

Community Help.


OpenVPN with Let's Encrypt certificate

While I am trying to connect to the server it disconnects midway stating that it cannot find the certificate of the Server. I am using a Let's Encrypt CA which issues certificate from an Intermediate CA. Is there a workaround or solution for this. My log file is as below

Nov 26 19:02:55: State changed to Connecting
Nov 26 19:02:55: Viscosity Windows 1.7.5 (1530)
Nov 26 19:02:55: Running on Microsoft Windows 10 Pro
Nov 26 19:02:55: Running on .NET Framework Version 4.7.02556.461308
Nov 26 19:02:55: Bringing up interface...
Nov 26 19:02:56: Checking reachability status of connection...
Nov 26 19:02:56: Connection is reachable. Starting connection attempt.
Nov 26 19:02:57: OpenVPN 2.4.4 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 27 2017
Nov 26 19:02:57: library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.09
Nov 26 19:03:07: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Nov 26 19:03:07: TCP/UDP: Preserving recently used remote address: [AF_INET]99.11.68.146:1194
Nov 26 19:03:07: UDP link local (bound): [AF_INET][undef]:0
Nov 26 19:03:07: UDP link remote: [AF_INET]99.11.68.146:1194
Nov 26 19:03:07: State changed to Authenticating
Nov 26 19:03:07: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Nov 26 19:03:08: VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Nov 26 19:03:08: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Nov 26 19:03:08: TLS_ERROR: BIO read tls_read_plaintext error

Nov 26 19:03:08: TLS Error: TLS object -> incoming plaintext read error
Nov 26 19:03:08: TLS Error: TLS handshake failed
Nov 26 19:03:08: SIGUSR1[soft,tls-error] received, process restarting
Nov 26 19:03:08: State changed to Connecting
Nov 26 19:03:18: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Nov 26 19:03:18: TCP/UDP: Preserving recently used remote address: [AF_INET]99.11.68.146:1194
Nov 26 19:03:18: UDP link local (bound): [AF_INET][undef]:0
Nov 26 19:03:18: UDP link remote: [AF_INET]99.11.68.146:1194
Nov 26 19:03:18: State changed to Authenticating
Nov 26 19:03:18: VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Nov 26 19:03:18: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Nov 26 19:03:18: TLS_ERROR: BIO read tls_read_plaintext error
Nov 26 19:03:18: TLS Error: TLS object -> incoming plaintext read error
Nov 26 19:03:18: TLS Error: TLS handshake failed
Nov 26 19:03:18: SIGUSR1[soft,tls-error] received, process restarting
Nov 26 19:03:18: State changed to Connecting
Nov 26 19:03:29: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Nov 26 19:03:29: TCP/UDP: Preserving recently used remote address: [AF_INET]99.11.68.146:1194
Nov 26 19:03:29: UDP link local (bound): [AF_INET][undef]:0
Nov 26 19:03:29: UDP link remote: [AF_INET]99.11.68.146:1194
Nov 26 19:03:29: State changed to Authenticating
Nov 26 19:03:29: VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Nov 26 19:03:29: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Nov 26 19:03:29: TLS_ERROR: BIO read tls_read_plaintext error
Nov 26 19:03:29: TLS Error: TLS object -> incoming plaintext read error
Nov 26 19:03:29: TLS Error: TLS handshake failed
Nov 26 19:03:29: SIGUSR1[soft,tls-error] received, process restarting
Nov 26 19:03:29: State changed to Connecting
Nov 26 19:03:34: State changed to Disconnecting
Nov 26 19:03:34: State changed to Disconnected
Hi kaduva,

Using a proper SSL certificate like Let's Encrypt is quite pointless as OpenVPN doesn't do any of the normal checks (like CA checks or domain name checks) like HTTPS does. Using something like Let's Encrpyt specifically isn't great either as from memory the server certificate will expire every three months at maximum.

The main problem though is every certificate issued by Let's Encrypt would be seen as valid by the OpenVPN server, meaning anyone could generate a set of certificates from Let's Encrypt and connect to your server, as well as opening you up to MITM attacks from servers simply using a Let's Encrypt certificate.

We have a guide here for generating certificates for your server - https://sparklabs.com/support/kb/articl ... pn-server/

Regards,
Eric
Hello,

I know this is an old thread but it's the exact problem I am having, and I can't believe how untrue your statements about Let's Encrypt are.

I've just set up my own VPN at home using the OpenVPN service on my OPNSense firewall. I generated my certificates and then generated the profile file so I could set up the official OpenVPN client on my Android phone. All works perfectly.

Because of the recommendation on the OPNSense firewall about Viscosity I decided to give it a go on my Windows 10 machine, so generated the "Viscosity Bundle" as OPNSense calls it, using the same details as I did for OpenVPN on Android, but when it tries to connect it fails with the above reported error:

Code: Select all

Aug 17 13:45:34: VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Aug 17 13:45:34: OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed


There is no way to MITM the certificates from LE any longer, their validation process prevents this. To generate a certificate for my domain for example, they'd have to also divert the IP used by the DNS record for my domain to their own IP, which unless they have also hacked that will never work. Also OpenVPN does fully do CA checks just as any other application does, including all the major browsers;

Yes there's the small inconvenience of the certificate expiring every three months, but they are generated automatically by the firewall and it's taken care of - I need not worry about it.

So please, fix the problem as it's supported by OpenVPN and Let's Encrypt is a great service that's helping us all get more securely connected.
Hi Taomyn,

I'm afraid it appears you don't understand how OpenVPN's peer validation works: it differs significantly from something like a web browser. Using a Let's Encrypt certificate, or any public certificate authority issued SSL certificate, is insecure by default.

Why It's Insecure

First and foremost, OpenVPN does not do any domain validation. For example, when you go to a HTTPS website in your web browser, your browser makes sure that the certificate is valid and that it matches the domain/IP you're accessing the server on. If you were to go to https://example.com, your web browser would make sure the certificate presented is actually for "example.com". OpenVPN does not do this.

For example, if your server's address is vpn.example.com, but the server presented an otherwise valid certificate only for the domain vpn.example2.com, a web browser would reject it, but OpenVPN would accept it. If it were a man-in-the-middle (MITM) attack, at this point you're connected to a malicious server and you would have no idea.

This is important when it comes to public certificate authorities like Let's Encrypt, because anyone can get a valid certificate from the same authority. So, if you generate a Let's Encrypt SSL certificate for vpn.myserver.com, and a hacker generates a Let's Encrypt certificate for a completely different domain they control, say mitmhacker.com, they can launch a MITM attack against you and OpenVPN will still happily see the certificate as valid because it's from the same authority.

Secondly, OpenVPN does not perform any other validation checks like a web browser does, such as revocation checks, removal/blacklist checks, etc.

Can It Be Made Secure?

OpenVPN provides a number of commands that allow you to do custom validation of a server certificate. So if you really want the server to use a Let's Encrypt (or other public SSL certificate authority) certificate, you could set up a number of advanced commands to validate the server against your own rules. This isn't recommend (using your own certificate authority is the recommended approach and considered the most secure), however theoretically you could do something like so:
- Set the client's CA file to be Let's Encrypt's CA certificate (or certificate chain)
- Make sure the "Require certificate was signed for server use" option is ticked
- Add the "verify-x509-name" advanced command to your configuration with the server's address, e.g. "verify-x509-name vpn.example.com name". For Subject Alternative Names (SANs), wildcards, etc. you'll need to adjust this rule and the field it uses. https://www.sparklabs.com/support/kb/ar ... -x509-name
- Download a copy of Let's Encrypt's CRL, and add the "crl-verify" advanced command to your configuration, and point it to the CRL file. This should be updated regularly. A certificate may be revoked either by yourself (for example the private key got compromised), or by the CA (for example they realised they mistakenly issued a certificate for your domain). https://www.sparklabs.com/support/kb/ar ... crl-verify

Again, I encourage you and anyone reading this to create their own CA and server/client certificate/key files. OPNSense makes it fairly easy, and we even have a handy tool for it as well: https://www.sparklabs.com/blog/openvpn- ... generator/

More Information

To generate a certificate for my domain for example, they'd have to also divert the IP used by the DNS record for my domain to their own IP, which unless they have also hacked that will never work.

I think you're confusing MITM attacks against how Let's Encrypt validates that you're the owner/operator of a domain, vs MITM attacks against your VPN connection itself. The latter is very possible if using a public CA issued SSL certificate in a typical OpenVPN setup.

Also OpenVPN does fully do CA checks just as any other application does, including all the major browsers;

This is incorrect. OpenVPN does nothing of the sort. It doesn't compare the server's certificate against the system's set of trusted CA root certificates. It doesn't do domain validation. It doesn't check the CA's revocation list. By default it's going to simply check that the server's certificate was issued by the CA certificate and nothing more.

I generated my certificates and then generated the profile file so I could set up the official OpenVPN client on my Android phone. All works perfectly.

If the steps in the section above aren't being taken then this is likely an insecure connection as it is vulnerable to MITM attacks.

Log Output

The "VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3" error indicates that OpenVPN is unable to find the "Let's Encrypt Authority X3" certificate (when attempting to validate the server's certificate). This like likely due to Let's Encrypt cross-signing which can create a complex certificate chain.

If you want to use Let's Encrypt you'll need to ensure that all certificates needed to validate the server's certificate are include in the client-side CA file in the proper order. OpenSSL (used by desktop clients like Viscosity) also process chained certificates somewhat differently to the OpenVPN-Connect mobile clients, and it's possible the ordering of the certificates may need to be changed. Failing that, you may need to consider using the "extra-certs" option.
https://community.openvpn.net/openvpn/w ... ate_Chains

Sorry for the wall of text, but security concepts such as these can be tricky, and I want to make sure that anyone who reads this thread isn't mislead into accidentally creating an insecure OpenVPN setup.

Cheers,
James
Hello James,

Thank-you for taking the time to respond, and to fully explain the whole matter. I was basing much on what I wrote on the advice of someone else from some time back and it was obviously at fault with regards to VPNs - I did some further research on what you stated and it all holds up. I suppose I should have done this beforehand.

I have of course now dropped using LE for the VPN certificates and so far Viscosity is working fine - well except from one location which is blocking any VPNs which leads on to my next question. I will post this via another thread.

Again, thank-you for the advice.

Cheers,
Taomyn
5 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy