pfSense

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?

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?

"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...

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!

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?

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.

Applied in changeset 22bca296dc3777bb872c7be460f09c3ff1177994.

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.

Any progress so far
Will it go into GA 2.2.3

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

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

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.

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.

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.

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.

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.

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.