On Thu, 27 Sep 2012, Jim Pingle wrote:
My experience so far is that I have two bad choices:
1. Use the web GUI to paste the CRL into cert manager and
assign that CRL to each OpenVPN instance. This is bad because
I can't seem to update the CRL without OpenVPN restarting
and dropping connections.
2. scp the CRL to each /var/etc/openvpn/serverX.crl-verify (where
X is 1, 2, 3, etc.). This is bad because the web GUI is now
out of sync with the underlying filesystem.
Am I missing a cleaner solution, one that allows a CRL update without
restarting the openvpn binary?
Why the reluctance to restart OpenVPN? Seems to me you'd want to
kill all active connections to ensure that the newly revoked
certificate is not in use.
At most the remote sites would have ~60 seconds of downtime after
the server is restarted.
I'm a bit reluctant to discuss our VPN setup in a public forum, so I
suffice it to say that we have three or four dozen VPN connections
running at any given time. Disrupting them all -- possibly in the
midst of some fairly significant work -- is not my preference.
I suppose it's possible at some point that I'd want to revoke a
certificate that's currently connected, but that's not as big a deal
to me as preventing future connections. (If I were worried about
current sessions, the GUI-driven restart wouldn't bother me as much
because I'd be able to justify to all concerned the severity of the
situation.)
There really wouldn't be a good way to manage that from the GUI,
write it out to the FS, and not restart OpenVPN. At least not the
way the GUI for that is currently coded.
I guess what I was hoping to hear is that there's a way to tell the
GUI to replace the CRL without rewriting every single
/var/etc/openvpn/serverN.* file and completely restarting OpenVPN. In
our configuration, each server eight runtime files:
* server1.ca
* server1.cert
* server1.conf
* server1.crl-verify
* server1.key
* server1.sock
* server1.tls-auth
* server1.tls-verify.php
My guess is that, in most deployments, only the *.crl-verify file will
need to change during day-to-day operations. Any other change
(certificate, basic configuration, etc.) would necessitate a restart.
Again, if I'm missing something, I'd be more than happy to be set
straight!
--
Paul Heinlein Galois, Inc.
Systems Administrator 421 SW Sixth Avenue, Suite 300
[email protected] Portland, Oregon 97204
+1 503 626-6616 x140 http://corp.galois.com/
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
