Bug #4329
closed
OpenVPN Server returns an error message while validating selfsigned certificate with a deep of 2
Added by Armin Tueting almost 10 years ago. Updated almost 9 years ago.
100%
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.
Updated by Phillip Davis almost 10 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?
Updated by Armin Tueting almost 10 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?
Updated by Phillip Davis almost 10 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...
Updated by Armin Tueting almost 10 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!
Updated by Ermal Luçi almost 10 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?
Updated by Armin Tueting almost 10 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.
Updated by Ermal Luçi almost 10 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?
Updated by Ermal Luçi almost 10 years ago
- % Done changed from 0 to 100
Applied in changeset ed56ce5a1d12b5a065e2c375a182adc1b2d8f91d.
Updated by Ermal Luçi almost 10 years ago
Applied in changeset 22bca296dc3777bb872c7be460f09c3ff1177994.
Updated by Armin Tueting almost 10 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.
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.1 to 2.2.2
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Armin Tueting over 9 years ago
Any progress so far
Will it go into GA 2.2.3
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.3 to 2.3
Updated by Dan Journo over 9 years ago
Has this one stalled? It is affecting me too.
Is there a safe workaround?
Updated by Armin Tueting over 9 years ago
I've disabled the certificate check and went with the default "Do not check".
Updated by Jim Thompson about 9 years ago
- Assignee changed from Chris Buechler to Matthew Smith
Assigned to Matt, because of the lack of progress here.
Updated by Renato Botelho almost 9 years ago
- Status changed from Feedback to Assigned
Based on user reports, it's not fixed
Updated by Jim Thompson almost 9 years ago
- Assignee changed from Matthew Smith to Renato Botelho
Updated by Jim Thompson almost 9 years ago
- Priority changed from High to Normal
Updated by Renato Botelho almost 9 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
Updated by Chris Buechler almost 9 years ago
I've never been able to replicate any issues here. The circumstance I believe should be:
- create CA testCA
- create intermediate CA intermediateCA, signed by testCA
- create server cert for OpenVPN signed by testCA
- 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.
Updated by Chris Buechler almost 9 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.
Updated by Steve Matos almost 9 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.
Updated by Chris Buechler almost 9 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.
Updated by Jim Pingle almost 9 years ago
Updated by Steve Matos almost 9 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.
Updated by Chris Buechler almost 9 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.