How to validate the certificate chain in a JWT, including checking against provided CRLs?

Hi, I need to validate the certificate chain in a JWT. This includes checking against provided CRLs.

I’ve tried at first using public_key:pkix_crls_validate, using as reference the test suite for public_key. But I’ve ended with a more simplistic approach, because I’m a little bit lost.

Here’s my code to CRL checking right now:

And here is my attempt to do it right (I think) following the documentation:

I have serious doubts, probably I’m overthinking the issue or doing something very wrong, but I don’t find any resources outside the test suite.

Thanks!

Sorry for bothering, but reviewing the tests I used as reference and other posts in this forum related with public-key, I’ve found that @ingela could help with this. Thanks!

I probably can help you when I am back from vacation. Sometime after 5 of August.

2 Likes

So first of all I would like to know a little more about the context of your verification. It seem you are trying to perform certificate path validation outside of the context of using out ssl application that implements the TLS protocol (which can be a valid use case but then you do not need to start the ssl application as you are not using it, you are only using the public_key application. I just today merged a correction to the public_key application in that area to maint and master, that might help clarify things for you. Fix: ‘issuer_fun’ takes {Fun, Term} tuple by rlipscombe · Pull Request #8566 · erlang/otp (github.com)

Hi, in order to pass the FIDO alliance certification process, they make us to pass this test:

They bring us 5 JWTs, but only 1 is valid, and that one should be the one to use as metadata for the FIDO2 server. Two of them have revoked certificates in its certificate chain. One have the leaf certificate revoked, and other an intermediate. So the point of the test is discard the invalid ones.

Point 4.3 here: FIDO Metadata Service

I manage to pass the tests using my first solution to identify revoked certs in the chain:

Is really simple and probably enough, but when I started the issue, the first thing I did was to check the right way to do it following the erlang docs. I’ve tried probably without fully understand the API, following the unit tests present in the OTP code.

Ok so as I understand it you are doing this outside of TLS connection environment. I think that
you should look at the ssl applications code for doing this for guidance.
See module ssl_handshake:maybe_check_crl/5 and module ssl_crl_cache.erl should be good places to find help. I think a that it also would be good if you can avoid calling none API functions of public_key (for your own sake, as we may rename them or whatever without any concerns for backwards compatibility).