New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trust : crl : implemented fetch and scheduled update from a URL #6838
base: master
Are you sure you want to change the base?
Conversation
…CRL Distribution Point) URL
ocsp is probably what you’re looking for, not sure what it needs to support it on OpenVPN, but magic around crl’s is not what we should aim for. |
Hello @AdSchellevis As far as I know, the ocsp check was possible with openvpn using a external check script. But I have to admit this knowledge might not be up to date. In case openvpn support ocsp meanwhile directly, this would probably be much easier to implement. |
The root of the problem is trying to extend the „remote“ CRL feature which basically just an import of externally managed CRL building on top in the wrong direction. Originally the CRL feature was for locally managed CRLs where it works perfectly fine (with the exception of CRL lifetime being super long in order for this to be static enough so nothing else needs to be implemented. Personally rendering the external CRL in the config.xml should be avoided completely. The CRL is steered by the certificate used anyway which the service should support, but most never do. I’ve worked long enough in that field that I can say it’s no fun dealing with that particular part of the trust chain. |
Hello @fichtner and @AdSchellevis ocspopenvpnWell, openvpn still has no builtin support for ocsp query, a validation script must be used. freeradiusHas ocsp support, must be implemented in opnsense crlBoth openvpn and freeradius just support local crl Well, my try summarize this here in a few words: Indeed, it would be great if each service dealing with certificate validation will use the crlDistributionPoints or the OCSP URI provided via authorityInfoAccess provided by the cetrificate/ca in order to validate the certs and by default should even fail if none of both are available.
I am afraid this is the same situation regarding several services, including openvpn and freeradius: they all started with local PKI implementations (even providing some scripts to deal with the setup of these), and thus failed to think outside the box. Well, to keep it short: I consider the implementation of both features as valid options. So please just let me know if there is a general interest in implementing a CRL and OCSP check for the different services, and if yes, I would appreciate some hints where I can contribute. Greetings from Berlin |
So if you're interested in working on ocsp support, my advise would be to start with a document describing the starting position and explain the openssl commands needed to do the actual verification. The development part is likely small if we can work out what is needed first. |
Hello @AdSchellevis and thank you for your prompt reply. Well, I will be on holiday for the next 3-4 weeks and probably have not much time for this, but as soon as I will be back I will have a look at this. |
Just one more thought in favor of supporting for CRL checks too: every PKI has a CRL but not every one has an OCSP server ... |
Isn't the |
Maybe, in addition to OCSP, place every CRL in a fixed path in /etc/ssl/... with |
It's not high on my list of priorities, but |
Yep, and placing all CRL in one folder would also be a generic approach for all other plugins too. |
Unfortunately not, as these CRL's currently are configured per service..... which is highly likely quite stupid, but one change at the point I didn't dare to add as well (thought about it, but managing feedback tends to cost way more than fixing the actual issue).... Also one of the reasons I'm not too enthusiastic about changing things in this area. |
Yes, it should be as noted as
I would try to extract it from the CA at least as default value ... I will try to write a tech draft as soon as I find some time on this and be back here then ... |
Yes, this was my approach too ... but as @AdSchellevis mentioned, the services are not |
I’ve maintained and improved such systems in my past employment and it’s very service centric and not all services implement this, which is why it may be tempting to try to solve this for all. OCSP may invalidate whole CA chains, where CRLs are still not updated or obsoleted. Not reaching a CRL or OCSP responder needs a separate policy (trust or reject), LDAP CRL sources need to be implemented and then you need to micro manage the CA bundles and CRLs dropped into the system. Instead of doing this from the start it would be advisable to check which services consumes which options and if a general rollout of such a system even makes sense if it’s only a handful services supporting this properly. Cheers, |
78845fc
to
8ba454a
Compare
fetch crl on a scheduled time base
We are working towards replacing our cisco branch routes in numerous locations all over the world by opnsense driven devices. One of the last tough nuts to crack is the remote access for the users using certificates and passwords. Not hard to implement, but the fact that opnsense lacks the ability to refresh a crl for a imported ca is a showstopper for as, as we need the option to lock out devices by revoking the certificate they use. Or let's say it the other way round: as openvpn (and freeradius) can just use locally stored CRLs and are not able to fetch the latest from the published crlDistributionPoint of the CA, opnsense must take care to provide a way to update the crl on a scheduled time base.
Well, we are not the first one to stumble over this feature, the feature request in #3335 exists. But this gathered not so much interest (despite the fact that the feature is in my opinion a must have for a enterprise ready product).
As we use ansible in order to manage the opnsense nodes, I could try some voodoo on this way to reach our target. But I think a general solution makes more sense.
tl;dr ... here is my first proposal as a PR in order to implement the feature.
I introduces a 3. option for CRLs that allows you to fetch and update the crl from a X509v3 CRL Distribution Point or any other URL.
I have tested it with openvpn in many combinations and it works as expected.
lint-php
has no complains.It uses a cron job per crl in
/etc/cron.d/
(I did not find another suitable way to register and de-register a cron job, if there is a better solution I am eager to learn about it). And I am not sure if cron jobs in that place will survive a upgrade.Apropos of upgrade: I have chosen to store the crl file in
/var/preserve/
(as the name of that directory suggested it will not be overwritten during a upgrade. If there are better places for such files, please just let me know.Openvpn will then use a symlink to the crl in
/var/preserve
forcrl-verify
(as soon as the PR is merged I will try to provide a update fro the freeradius plugin too).Proposals for improvements and changes are welcome.