Project

General

Profile

Bug #4329

OpenVPN Server returns an error message while validating selfsigned certificate with a deep of 2

Added by Armin Tueting over 4 years ago. Updated over 3 years ago.

Status:
Not a Bug
Priority:
Normal
Category:
OpenVPN
Target version:
-
Start date:
01/28/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2
Affected Architecture:
i386

Description

Hello,

I've recently upgraded from 2.1.5 to 2.2 and getting an error message:-

Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 Incoming Ciphertext -> TLS
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 TLS: executing verify command: /usr/local/sbin/ovpn_auth_verify tls xxxxx.dyndns.org 2 2 C=XX, ST=XX, L=XXXX, O=XXXXX, OU=Root Certificate Authority, CN=XXXXX RootCA, emailAddress=pki@XXXXXXXXXX
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 WARNING: Failed running command (--tls-verify script): external program exited with error status: 1
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 VERIFY SCRIPT ERROR: depth=2, C=XX, ST=XX, L=XXXXX, O=XXXX, OU=Root Certificate Authority, CN=XXXX RootCA, emailAddress=pki@XXXXXXXXXXXXXXXXX
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 SSL alert (write): fatal: certificate unknown
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 TLS_ERROR: BIO read tls_read_plaintext error: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 TLS Error: TLS object -> incoming plaintext read error
Jan 28 09:39:23 pfsense openvpn4214: XX.XX.XX.XX:9674 TLS Error: TLS handshake failed

Regards,
Armin.

Associated revisions

Revision ed56ce5a (diff)
Added by Ermal Luçi over 4 years ago

Fixes #4329, Fix even tls.auth script by using proper isset() test as the fixes for other authentication scripts.

Revision 22bca296 (diff)
Added by Ermal Luçi over 4 years ago

Fixes #4329, Fix even tls.auth script by using proper isset() test as the fixes for other authentication scripts.

History

#1 Updated by Phillip Davis over 4 years ago

Is that related to the "Certificate Depth" setting on the OpenVPN Server GUI page?
Do you have that already set to "Two" or more?
Maybe 2.1.5 did not enforce that well and 2.2 does? or?

#2 Updated by Armin Tueting over 4 years ago

Phillip Davis wrote:

Is that related to the "Certificate Depth" setting on the OpenVPN Server GUI page?

I didn't change anything at all on the GUI!
As part of my upgrade here is the partly oOutput from diff:-
2940d3014
< <digest>SHA1</digest>
2951d3024
< <verbosity_level>3</verbosity_level>

Do you have that already set to "Two" or more?

Yes - I've set it "Two".

Maybe 2.1.5 did not enforce that well and 2.2 does? or?

Are you saying I should disable and try again?

#3 Updated by Phillip Davis over 4 years ago

"Two" should be good. I just checked a road warrior server of mine. I changed Certificate Depth to "Two" and it changed in /var/etc/openvpn/server1.conf

tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'My-Remote-Server' 2"

The "2" came at the end of the line (was previously "1").

/usr/local/sbin/ovpn_auth_verify and /etc/inc/openvpn.tls-verify.php have not had any change in 2.2 that looks like it would break this.

So it could be a problem in OpenVPN itself if the current cert depth is not getting passed through also for comparison checking or...

#4 Updated by Armin Tueting over 4 years ago

Phillip Davis wrote:

"Two" should be good. I just checked a road warrior server of mine. I changed Certificate Depth to "Two" and it changed in /var/etc/openvpn/server1.conf

tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'My-Remote-Server' 2"

The "2" came at the end of the line (was previously "1").

I've removed my "Two" and went with the Default! It's working - but it's a workaround. I'm trusting a certificate which I don't know if it matches...

/usr/local/sbin/ovpn_auth_verify and /etc/inc/openvpn.tls-verify.php have not had any change in 2.2 that looks like it would break this.

Yes, pfSense 2.2 breaks it - I'm afraid! I think pfSense doesn't provide the full swing of certificates over to this script!

So it could be a problem in OpenVPN itself if the current cert depth is not getting passed through also for comparison checking or...

No - it's a bug in pfSense rather than OpenVPN as the workaround has shown that it works!

May I kindly request to get it fixed in the next dot release 2.2.1 as it impact all immediate certificates around!

#5 Updated by Ermal Luçi over 4 years ago

diff --git a/etc/inc/openvpn.inc b/etc/inc/openvpn.inc
index 3bdb5a6..060a435 100644
--- a/etc/inc/openvpn.inc
+++ b/etc/inc/openvpn.inc
@@ -630,7 +630,7 @@ function openvpn_reconfigure($mode, $settings) {
                                $cert = lookup_cert($settings['certref']);
                                /* XXX: Seems not used at all! */
                                $servercn = urlencode(cert_get_cn($cert['crt']));
-                               $conf .= "tls-verify \"/usr/local/sbin/ovpn_auth_verify tls '{$servercn}' {$settings['cert_depth']}\"\n";
+                               $conf .= "tls-verify /usr/local/sbin/ovpn_auth_verify tls '{$servercn}' {$settings['cert_depth']}\n";
                        }
                }

Can you try this patch and let me know if it works for you?

#6 Updated by Armin Tueting over 4 years ago

Ermal Luçi wrote:

[...]

Can you try this patch and let me know if it works for you?

The patch creates an error when starting OpenVPN :( I'll back out the patch.

Jan 29 09:37:40 pfsense openvpn[92467]: Options error: the --tls-verify directive should have at most 1 parameter.  To pass a list of arguments as one of the parameters, try enclosing them in double quotes ("").
Jan 29 09:37:40 pfsense openvpn[92467]: Use --help for more information.

#7 Updated by Ermal Luçi over 4 years ago

  • Status changed from New to Feedback

Ok i pushed the proper fix for this.
Can you confirm it works for you as well?

#8 Updated by Ermal Luçi over 4 years ago

  • % Done changed from 0 to 100

#9 Updated by Ermal Luçi over 4 years ago

#10 Updated by Armin Tueting over 4 years ago

WARNING: Failed running command (--tls-verify script): external program exited with error status: 1

Ok i pushed the proper fix for this.
Can you confirm it works for you as well?

Nop - I'm afraid.

#11 Updated by Chris Buechler over 4 years ago

  • Assignee set to Chris Buechler

#12 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2.1 to 2.2.2

#13 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2.2 to 2.2.3

#14 Updated by Armin Tueting over 4 years ago

Any progress so far
Will it go into GA 2.2.3

#15 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2.3 to 2.3

#16 Updated by Dan Journo about 4 years ago

Has this one stalled? It is affecting me too.
Is there a safe workaround?

#17 Updated by Armin Tueting about 4 years ago

I've disabled the certificate check and went with the default "Do not check".

#18 Updated by Jim Thompson almost 4 years ago

  • Assignee changed from Chris Buechler to Matthew Smith

Assigned to Matt, because of the lack of progress here.

#19 Updated by Renato Botelho over 3 years ago

  • Status changed from Feedback to Assigned

Based on user reports, it's not fixed

#20 Updated by Jim Thompson over 3 years ago

  • Assignee changed from Matthew Smith to Renato Botelho

#21 Updated by Jim Thompson over 3 years ago

  • Priority changed from High to Normal

#22 Updated by Renato Botelho over 3 years ago

  • Status changed from Assigned to Feedback

After spend some time making lots of tests on 2.3 I was not able to reproduce it anymore.

I'll leave this in feedback state for now, waiting for other people tests and reports

#23 Updated by Chris Buechler over 3 years ago

I've never been able to replicate any issues here. The circumstance I believe should be:

  1. create CA testCA
  2. create intermediate CA intermediateCA, signed by testCA
  3. create server cert for OpenVPN signed by testCA
  4. create user cert for OpenVPN signed by intermediateCA

Even going back to 2.2.0-RELEASE, that situation works correctly. If your verify depth is 1, you correctly get a failure with:

Certificate depth 2 exceeded max allowed depth of 1.

Set it to depth 2, and it succeeds. Works on 2.3 as well.

#24 Updated by Chris Buechler over 3 years ago

  • Status changed from Feedback to Not a Bug
  • Target version deleted (2.3)

This has to be a config that in some way was wrong to begin with, but worked out of coincidence until a newer OpenVPN version or some other change. There would be a lot more than 2 reports in a year otherwise, and we'd be able to find some means of replicating.

Armin or Dan, if you can provide a full configuration or access to a system that exhibits the issue, we'll look into it.

#25 Updated by Steve Matos over 3 years ago

I am another pfSense user who has experienced this problem. Here's how I caused it to happen...

1.) Create a root CA using openSSL for my organization.
2.) Create Intermediate CA just for OpenVPN on pfSense (based off of the root CA above) using openSSL.
3.) Add root CA public key to pfSense (Note: Only the public key. pfSense, never get's the private key for the root CA as it shouldn't need it.)
4.) Add both public and private keys for the OpenVPN Intermediate CA to pfSense.
5.) Use the OpenVPN Intermediate CA to make the server key and client keys.

This will fail upon connection because OpenVPN cannot verify the keys.
I may be wrong, but I believe the fix would simply be to add the full chain of public keys to the "ca" file (/var/etc/openvpn/server1.ca). The way it works now, I only get the OpenVPN Intermediate CA public key in there, but there should be the full chain so it also needs the root CA's public key in there too.

I think the problem lies in the fact that the root CA was added to pfSense without a private key and somehow this messes things up. I think it should just fully traverse the chain by looking at the server key that is configured and work it's way back to the root.

Hopefully this is the information that you are looking for. Let me know if you need any more details.

#26 Updated by Chris Buechler over 3 years ago

Steve: did you misstate one of the steps there? In that case, where both the OpenVPN server and client certs are from the intermediate CA, you have no need for the root CA at all and should be specifying the intermediate CA in the OpenVPN config.

#27 Updated by Jim Pingle over 3 years ago

If the CA chain is the problem then this bug isn't quite as described. It should be closed in favor of one that fits better, like #2800, #1801, #4934, etc.

#28 Updated by Steve Matos over 3 years ago

Chris Buechler wrote:

Steve: did you misstate one of the steps there? In that case, where both the OpenVPN server and client certs are from the intermediate CA, you have no need for the root CA at all and should be specifying the intermediate CA in the OpenVPN config.

I think it doesn't work if you use the intermediate CA. I seem to recall something strange with the way the ca is chained. I switched away from this because it wasn't working. I may have to try it again if you guys can't see it in testing.

I believe that I also tried another setup where I made a second intermediate CA that I used just for server certs. In other words, the root CA created two intermediate CAs, the servers CA and the openVPN client CA. I think this one never worked correctly for the same reasons.

In my case, I think it always had to do with the chaining of the intermediate CA and root CA's public keys and the "ca" file not being generated correctly. So, what Jim said above about #2008 may be more correct in my instance.

#29 Updated by Chris Buechler over 3 years ago

It definitely works in that specific circumstance if you pick the intermediate CA in the OpenVPN config, or a chain including the root and intermediate CAs if you want but the root CA is entirely unnecessary in that circumstance where client and server certs are from the intermediate. If you're in a situation where you need a chain, then the CA cert you use needs to contain the entire chain. That's covered in #2800 / #1801.

Also available in: Atom PDF