Validating a new client certificate

erichorne

The time has come to automate the client certificates generation and deployment. A certificate can be generated on the client itself, but it should be verified before it replaces the current certificate. The fear here is that something at the remote site or our own server-side for whatever reason might cause the new client certificate to fail where the current one works (it is absolutely mission critical that the VPN connection not be lost and VPN downtime must be minimized to close to nothing). Think error in the cert generation that leaves off a specific attribute or adds something making it incompatible with our server for some crazy reason.

Once a new certificate is available on the client, what is a good way to validate it will work against our OpenVPN server without replacing the existing certificates and trying it? I'm thinking there is a way that openvpn could connect with the client cert, validate the connection is good and exit without allocating a new IP or establishing a new tunnel.

The --tls-verify argument sounds like it might be a way to do that, where the script could indicate success in some external way (touch a file or whatever), but then return an exit code to cause openvpn to abort. I'm not sure that the tls-verify would happen late enough in the process to validate the client cert, though. Would a script at --ipchange do the job perhaps?

Any thoughts or ideas?

Thanks!

-Eric

TinCanTech

You are way off ..

Use Easy-RSA for your certificates: https://github.com/OpenVPN/easy-rsa

Clients cannot generate their own certificates in your setup.

Use Easy-TLS for enhanced TLS security: https://github.com/TinCanTech/easy-tls

Your ideas regarding TLS Verify are completely wrong.

If you feel brave, which I doubt, you can even try Openvpn in peer-fingerprint mode.
https://github.com/TinCanTech/easy-pfp

But as you don't know what you are doing and this is "mission critical", I suggest
you study the Howto and other Openvpn documentation.

If you need professional help then I am available for hire: tincantech <at> protonmail dot com

erichorne

I appreciate the honesty.

We have a way to deliver a client certificate to the client is what I meant. That works. I've done it. It exists. Not up for debate. What I want to do is try that delivered client cert out on the client itself without just replacing the existing certs to make very sure the certificate do actually work before replacing them on the client.

The idea behind tls-verify or ipchange was that it would allow openvpn to make the connection, thus proving the certs work. When the script executes instead of doing something normal, it kills the openvpn daemon before it starts trying to set up routes and such. If the script doesn't execute, it's a sign it didn't get that far and after x seconds the attempt can be terminated from the shell.

In my experiments so far, ipchange seems to work that way, and I can kill the daemon from that script before and routes are established.. but it does create an interruption in the existing VPN connection (the one that is having it's certificates updated). Soooo I am asking if there are other ideas for verifying that when we replace the old certs with the new ones that it will work without actually replacing the old certs with the new ones and restarting the existing connection. Is there a away to test the water while keeping the existing VPN online/uninterrupted.

TinCanTech

Issue valid certificates .. then you know they work. What do you expect ?

Your test is completely moot.

erichorne

Well, I expect the possibility that something subtle is wrong with the certificate that got delivered through some kind of defect in the certificate delivery code. It's possible, for example, there is a new attribute in the cert that wasn't there before and it's somehow incompatible with openvpn. Or maybe some algo changed somehow someway and now openvpn can't compute something properly. The point is, there is a failure path somewhere that I can't conceive that would be caught by actually using the cert.

So just to be absolutely safe and sure, we'd like to try the certs out in a dry-run kind of way where the certs are exercised as if they were really being used exactly as openvpn would use them, but not actually establish the connection with them. Once it passes that test, that's enough confidence to replace the old existing certs and restart the tunnel with the new certs and absolutely expect the VPN connection will not fail due to a cert issue. And do all that with the least amount of VPN downtime.

Yes, it is an extremely cautious action -- and probably unnecessary in 1 in a million cases. Maybe 1 in a billion. But the business would like to ensure to the highest degree possible that the VPN connection will come back when those new certs replace the old certs and ideally they'd like that to happen without installing a cert that does not work for some crazy remote 1 in a billion reason. Thus, I'm asking for ideas on how to accomplish that level of testing.

So far, I've been successful (I believe) in my testing using a kill script associated through --ipchange. The test ends up dropping 10's of packets on the established VPN, so it's not perfect. And, as I don't know how exactly the openvpn protocol works, I'm not sure if this ipchange is the best place to test and kill the daemon. It seems like it is. I'm making an assumption that the client cert is accepted at this point because the vpn wants to assign an IP, it wouldn't want to do that for an un-auth'd client -- but that's an assumption on my part. I was hoping there might be a kind of openvpn ping that would simply ping openvpn auth'd with the client cert, but that doesn't appear to exist.

So I'm open to ideas or suggestions and would love to draw on your experience for that if we can just get past the "there's no reason to test certs that way" part. Either way, I thank you for your time and the questions.

TinCanTech

@ mod This thread is completely off-topic for "Config Management"

Without going into too much detail these are the only cogent points:

Point 1:

erichorne wrote We have a way to deliver a client certificate to the client is what I meant. That works. I've done it. It exists. Not up for debate.

Then you will deliver perfectly valid certificates. Your test is moot.

Point 2:

erichorne wrote the business would like to ensure to the highest degree possible that the VPN connection will come back when those new certs replace the old certs

And you come here, to a public forum, to ask strangers to give you a free solution to a non-existent problem. See point one above.

Point 3:

erichorne wrote Yes, it is an extremely cautious action -- and probably unnecessary in 1 in a million cases. Maybe 1 in a billion

If it is that important then you would deliver the certificate by hand and install and test it yourself.

Your test is utterly pointless.

If you find a single new certificate that does not work then there are only two possible reasons:

Your delivery system failed -- Nothing to do with OpenVPN
You found a bug in OpenSSL -- Report it to OpenSSL.

The rest is simply waffle ..

If you need professional help then I am available.

To be totally succinct:

If it were that important then you would already have a qualified professional on site

erichorne

Managing certificates is off topic for the Cert/Config Management forum? Weird. Can you suggest a more appropriate topic?

Point 1 is nullified by "you found a bug in OpenSSL", is it not? And that's no dig on openvpn by any means; software fails, ours, theirs.. it fails in ways we don't always expect. So there is a desire to do as complete a validation as possible on the certs. It's really just that simple of a goal.

Point 2 - I understand your point. I'm thankful you chose to engage.

Ah! In point 3.. what's the best way to test it when physically present at the site and the new cert is in possession while avoiding taking down the existing tunnel to perform the test? That's actually the crux of the question.

But fine, I get it. I thought there might be a "oh, no use this feature to try that" kind of answer. It would seem, from your perspective, there is no solution. At least not one you are willing to invest free time into.

Thank you again for trying to help and spending the time to read through the posts. It's helped me at least to clarify some goals and needs.

TinCanTech

If this were that important then you would have what is commonly referred to as a Test environment.

Which you don't .....

And this has nothing todo with managing certificates .. your problem is your lack of confidence in your systems.

TinCanTech

Let me put this another way for you, so that you can see what you are doing wrong:

If this were honestly that important to you then you would not be using Free software to do it.