Restarting OpenVPN from ACME
-
Looking to move to ACME based certificates for the server side of an openvpn deployment (internal CA not an option at this time); as part of that I'd like ACME to restart the OpenVPN instances (one split tunnel, one full tunnel) whenever the certificate is renewed. Unfortunately I can't seem to find good documentation on how best to do that; with the
restart local serviceconfiguration in the ACME package; any pointers would be most appreciated. -
You have to find the OpenVPN instance ID, which is the same as its interface number. For example, if it's using
ovpns2, then the ID is2. Once you know that, the command to enter with the Restart Local Service option would beopenvpn server 2.That said, you probably should not be using ACME with OpenVPN, why are you doing that?
-
Huh, is there even one single advantage of using ACME with OpenVPN?!
-Rico
-
None that I can think of. You want a private CA so that no certs outside of that specific VPN could ever be considered valid.
-
This topic comes up now and then.. User want to use public CA for openvpn.. Never is a good idea, never will be a good idea.
-
Yeah, like storing a copy of my home keys in someone else's house.
-Rico
-
More like storing them at a key copy machine.. Where anyone could get a copy made that wants a copy.. Storing a copy of the keys at someone you trust to not hand out copies isn't all that bad ;)
-
The only VPN usage where it makes a little sense is IPsec remote access IKEv2 without user certs. In that case, such as EAP-MSCHAP or RADIUS, the server cert only serves to identify the server. Though the ACME certs don't contain the IKE intermediate OID that some clients require, so I'm not sure it's worth doing even in that case. Unless clients have backed off that requirement, I haven't tested it in a long time.
-
That's actually not at all the case; ACME is not providing user keys, no user authentication or authorization is done using the server cert. The only the use for the server cert is to allow the client to ensure that you're connecting to the server you think you are (server authentication by the client) much like any other TLS connection. User credentials can be either certificate based (this is where a private CA would be appropriate) or username / password based. Using a public CA (with or without ACME) has no bearing on the CA configured to be trusted for user certificates.
The largest downside to using LetsEncrypt or another ACME based public CA is the short lifespan of the issued certificate however this comes down to automation (the root of my question) and setting proper SLOs. If uptime is an absolute must then running multiple VPN headends would easily cover this; as a headend apprached its maintenance window it could be removed from rotation with sufficient lead time to prevent new sessions establishing and old sessions dying before the cert swap.
The other important note is that while the PFSense ACME package currently has a limited number of CAs available in the drop down ACME is actually an open protocol that internal CAs can also leverage.
-
I would still not consider that ideal for OpenVPN. You have to deliver the config and other settings (TLS key, etc) so using you may as well send along the CA in the bundle to be validated for added security. Sure, you could omit the CA since the OS bundle should consider ACME trusted, but I fail to see any advantage in doing so for OpenVPN. You could also argue it's less secure since any other OpenVPN server using an ACME cert would also appear to be valid to the client, though validating the cert CN and using TLS keys help there, it's still knocking down an extra layer of authentication between the server and client.
Contrast that against the IKEv2 user auth scenerio above, where all you need to do is enter/match settings without delivering anything to the client. It's more convenient in that case, though some of the same security arguments still apply.
