Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
I'm not really sure what you mean by 'dump a certificate back to PEM format'. AFAIK .pem is just a base 64 encoded certificate wrapped in '---- BEGIN-CERTIFICATE-----' tags. This should be simple to do. I probably don't understand what you mean.
As for OCSP, it looks like openvpn doesn't support it natively, although I'd have thought it would be a useful patch. Maybe talk to the developers (or make your own patch).
Alternatively (and this is me thinking out loud, i.e. untested), perhaps you could implement a simple FUSE filesystem that does the lookup and exposes the results as a file to be passed to OpenVPN. As you've previously mentioned Perl, have a look at Fuse::Simple on CPAN. You could write a script that first queries your OCSP provider and grabs the current CRL(s) (using openssl for example, I couldn't see a pre-built CPAN module for OCSP). Then make that data available in a 'file' mounted somewhere. Just point 'crl-verify' in OpenVPN at that file. I've not done it with CRLs before, but I have used Fuse::Simple for 'dynamic' readonly config files with data from LDAP and MySQL databases. I find it simpler than a full blown database filesystem like LDAPfs or MySQLfs.
Also, it would probably be useful to know a little more about your setup. How many clients and servers? Hub or mesh based etc. etc. There are probably subtleties that make a simple transfer of a standard CRL file unsuitable, but I would have thought the VPN would have to get pretty big before you'd need to worry about using something dynamic as described above. Afterall, usually only the server(s) need access to the CRL as clients shouldn't be connecting to each other.
At one point according to google at least, there was an ocsp patch floating around for OpenVPN. As clients connect to the OpenVPN server, I can check their certificate DN as that is exposed. I'm currently using the client certificate DN to match against a group in ldap. Since any user in this infrastructure can request a certificate from the CA based on their user DN, but not every user with a valid certificate should get to the private VPN than is setup with OpenVPN.
To do an OCSP lookup, I need more than just the cert DN though, I need the actual certificate exposed.
My issue with dumping the CRL and then using crl-verify in open vpn is purely because that would be a slice in time of the CRL, and over time I suspect the CRL is going to grow very large. Depending on what other labs start noticing this little project in my corporation, there could potentially be several users with several OpenVPNs all trying to dump out the CRL to validate the status of client certificates.
What I'm looking for is how to get ahold of the client certificate as its passed to the OpenVPN server, not just the DN.
I don't know how to answer the rest of your questions. I did not setup the OpenVPN server, I was just enabling it work with a new internal CA. I don't see how the architecture of the OpenVPN networking matters however. One thing to note, is that the number of certificates being signed by the CA in this infrastructure is at least 100-1000x the size of the number of openvpn clients, hence my concerns with screwing around with moving a crl
Okay, I get what you want now. The patch here works fine against openvpn-2.1_rc21 on my gentoo box, and it looks simple enough to work against others. It should do what you want.
I would say though that (IMHO) you might want to re-think things. As I understand it, you're having to revoke almost all the certificates generated by your CA. This seems very inefficient and will, as you point out, generate a very big CRL quickly. Would it not be possible to have a separate CA for the VPN? When a certificate is issued that needs VPN, have the CSR signed by the VPN's CA. The patch should work though if you want to stick with your setup.