trust : crl : implemented fetch and scheduled update from a URL

[zerwes]

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 for crl-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.

[AdSchellevis]

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.

[zerwes]

Hello @AdSchellevis
Yes, you are right, ocsp would be another option.

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.
But freeradius is not capable of this to my knowledge, that is why I have chosen this solution approach, as it offers a build-in solution for both services that use a crl.
And in fact the PR just extends the already existing option to import a existing crl with the extension to update it automated on a scheduled time base (being even less intrusive on updates as the current implementation, as it requires no service reload, just exchanging the files used by the service under the hood)

In case openvpn support ocsp meanwhile directly, this would probably be much easier to implement.
Well, I will have a look at the current ocsp support in openvpn and will be back here soon ...

[fichtner]

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.

[zerwes]

Hello @fichtner and @AdSchellevis
Sorry for the delay, I was kind of stresstracted from this topic.
I will try to keep my answers short:

ocsp

openvpn

Well, openvpn still has no builtin support for ocsp query, a validation script must be used.

freeradius

Has ocsp support, must be implemented in opnsense

crl

Both 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.
But in real life this is not the case... One can be sad about it, but we have to find a way around it ...

Originally the CRL feature was for locally managed CRLs where it works perfectly fine

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.
I am very happy to declare myself willing to invest some time in this ... assuming that is desired.
If this is not the case and you do not wish any changes on this topic, I am fine with it too. It will take me half a working day to implement the features required for our setup. But generally I prefer generic solutions for general benefit much better, even at the cost of a bigger effort.

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

[AdSchellevis]

ocsp would be preferable for OpenVPN, it's likely not super complicated as it can hook into the verify scripts, but needs a solid testbed first. managing CRL's via an api requires quite some rework which is currently not high enough on our list.

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.

[zerwes]

Hello @AdSchellevis and thank you for your prompt reply.
Well, ocsp sounds like a good start and indeed the commands for the hook script should not be to complicated ...
And for the ocsp check the impact on the openvpn config and UI should be quite minimal: a text field for the ocsp URI and maybe a check box in order to confirm the check is desired; in the openvpn cfg this would result in a single config option ...

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.
I am interested in this and happy if I can help here somehow.

[zerwes]

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 ...

[AdSchellevis]

Isn't the ocsp URI included in the CA? I only looked briefly at this, when you have time to work out what it needs, just ping me again. I think it would be good to have ocsp available, with a step by step plan on how to setup and test, the integration challenge on our end shouldn't be too large.

[mimugmail]

Maybe, in addition to OCSP, place every CRL in a fixed path in /etc/ssl/... with <id>.crl so every plugin can automatically link against it due to id field?

[AdSchellevis]

It's not high on my list of priorities, but crl-verify in OpenVPN does seem to support a directory in stead of a single pem file, never tried it to be honest. (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/)

[mimugmail]

Yep, and placing all CRL in one folder would also be a generic approach for all other plugins too.

[AdSchellevis]

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.

[zerwes]

Isn't the ocsp URI included in the CA? I only looked briefly at this, when you have time to work out what it needs, just ping me again. I think it would be good to have ocsp available, with a step by step plan on how to setup and test, the integration challenge on our end shouldn't be too large.

Yes, it should be as noted as X509v3 extension in the CA and the CERT

X509v3 extensions:
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://...
            Authority Information Access: 
                OCSP - URI:...

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 ...

[zerwes]

Yep, and placing all CRL in one folder would also be a generic approach for all other plugins too.

Yes, this was my approach too ... but as @AdSchellevis mentioned, the services are not ready for this ... so my first idea in this PR as a draft was to put the CRLs somewhere where they will survive a upgrade and then use symlinks for each service (this worked for openvpn, but some other services might be picky with symlinks) ... but there might be much better solutions (but these things might require quite big refactoring, so I fully understand the not too enthusiastic about changing things in this area ... maybe we find a viable and not to intrusive solution together.

[fichtner]

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,
Franco