Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#907 closed Bug / Defect (notabug)

OpenVPN server is rejecting clients due to self signed cert error

Reported by: darksky Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.4.3 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger, plaishtos

Description

I am unable to connect to my openvpn server on a new box (client and server both run Arch x86_64). I believe that OpenVPN is rejecting a self-signed CA signature now whereas it did not in the past. Around November of 2016 when Arch Linux was running on openssl-1.0.2j, I did not experience this issue generating my openvpn files under that version. For example, multiple servers I created then still works to this day using the identical procedure with Easy-RSA to generate the key/certs documented here.

Excerpt from openvpn client trying to connect:

VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: CN=ease CA
OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

I am not knowledgeable enough to pinpoint the cause of this error fully recognizing that multiple factors might be to blame (me, openvpn, openssl, something else, or a combo of these).

Complete logs as well as server and client conf file attached to help with debugging.

Attachments (5)

client.log (1.8 KB) - added by darksky 3 years ago.
server.log (2.5 KB) - added by darksky 3 years ago.
myserver.conf (9.7 KB) - added by darksky 3 years ago.
myclient.conf (307 bytes) - added by darksky 3 years ago.
openvpn-files.tar.gz (13.0 KB) - added by darksky 3 years ago.
sample certs and keys for server and client

Download all attachments as: .zip

Change History (16)

Changed 3 years ago by darksky

Attachment: client.log added

Changed 3 years ago by darksky

Attachment: server.log added

Changed 3 years ago by darksky

Attachment: myserver.conf added

Changed 3 years ago by darksky

Attachment: myclient.conf added

comment:1 Changed 3 years ago by darksky

Accidentally assigned to v2.2.2 when in fact it is v2.4.3 but I am not clear on how I can change it.

comment:2 Changed 3 years ago by tincantech

CC

comment:3 Changed 3 years ago by Gert Döring

Cc: Steffan Karger plaishtos added
Version: 2.2.22.4.3

Well, arch is using openssl 1.1.0, which we did not support before 2.4.3 - and I wouldn't be surprised if their certificate checking rules changed between 1.0.x and 1.1.x

What happens if you use a certificate set (ca, client, server) generated on an openssl 1.0.x box on the 1.1.x client/server pair, or vice versa? Read: is openssl now generating funny stuff, or is the check much stricter but the certificates itself are no worse than previously...?

Copying in @syzzer and @plaisthos, they are rumored to understand OpenSSL.

comment:4 Changed 3 years ago by darksky

I have a certificate set (/etc/openvpn/server/ and a client.ovpn) that I generated back in Nov of 2016 that was under openssl-1.0.2 in use on a currently up-to-date box (ie openssl-1.1.0). Everything works as expected. I tried to downgrade openssl but it was not possible without risking some breakage as multiple packages are now providing some of the files the original one did. What is clear is that the older versions worked as expected but the new version does not when I follow the same procedure.

It has we wondering if Easy RSA needs an update or if there is some other steps I need to perform in light of the new version, or if there is a legit bug upstream (openssl or openvpn). Quite a few variables indeed :)

I guess the first think to check is whether or not someone else running an update-to-date Arch is able to reproduce what I reported (although I have done it so many times, I am pretty confident that I didn't omit a step), and then work to figure out the exact nature of the failure.

comment:5 Changed 3 years ago by Steffan Karger

Could you maybe generate a failing certificate set (with keys), and share that with us? Or, less but still helpful, share the failing certificates (without keys)?

This reeks liek more strict checks in OpenSSL, but having a certificate set would help pin down the issue.

comment:6 Changed 3 years ago by eworm

For me this looks like the server certificate self-signed, not signed by CA.

Can you please give output of these commands:

openssl x509 -noout -text -in /etc/openvpn/server/ca.crt
openssl x509 -noout -text -in /etc/openvpn/server/myserver.crt

Changed 3 years ago by darksky

Attachment: openvpn-files.tar.gz added

sample certs and keys for server and client

comment:7 Changed 3 years ago by darksky

@syzzer - I just created new certs and keys and verified that they give the same errors as I reported above. I tarred them up and attached (openvpn-files.tar.gz)

@eworm - Might be redundant given the attachment, no?

comment:8 Changed 3 years ago by eworm

Your client configuration holds a wrong ca certificate. If you copy the content from ca.crt to the <ca>-block of your client.conf file everything works.

comment:9 Changed 3 years ago by darksky

@eworm - I tried changing out the entire section of <ca> with the contents of ca.crt as well as just the part after '-----BEGIN CERTIFICATE-----' but both times, I get the same 'VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: CN=Fresh CA' ... would you be kind enough to post the functional client.conf here so I can test it and if it works, diff it against my bad ones? Thank you.

EDIT: no, wait, I am able to connect now replacing it as you suggested. Thank you very much for the time to inspect. I need to review how the ovpngen script I used in the past successfully is no longing functional to generate my client.conf.

Last edited 3 years ago by darksky (previous) (diff)

comment:10 Changed 3 years ago by Steffan Karger

Resolution: notabug
Status: newclosed

This makes sense: if OpenSSL no longer accepts the peer certificate to be equal to the supplied CA certificate (which actually is the server cert), it will try to traverse the chain supplied by the server, and end up at the real CA cert, which is indeed self-signed.

Problem solved, case closed. Thanks eworm!

comment:11 Changed 3 years ago by darksky

I believe it is safe to close. Thank you all.

Note: See TracTickets for help on using tickets.