I'm currently working in a dev environment trying to configure haproxy with crl validation in front of a server that uses staging certificates.
Haproxy requires crl's from the entire chain to be valid.
My backend server has a certificate signed by (STAGING) Puzzling Parsnip E7 which has a crl distribution endpoint http://stg-x1.c.lencr.org/
The crl downloaded from this url is outdated and can't be used for validation
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
Last Update: Sep 4 00:00:00 2020 GMT
Next Update: Aug 4 00:00:00 2021 GMT
The same is the case for http://stg-x2.c.lencr.org/
Version 2 (0x1)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Bogus Broccoli X2
Last Update: Sep 4 00:00:00 2020 GMT
Next Update: Aug 4 00:00:00 2021 GMT
Thanks for bringing this to my attention. I've confirmed that Staging is serving (very!) outdated root CRLs. I've escalated internally and will report back when I know what went wrong and when we have an ETA for a fix.
Alright, we've got this on our docket to fix. We've been planning to change how these static files are served, so it might take up to a week if we decide to use this opportunity to make that change as well, but you should see updated CRLs soon.
I mean, they must have a ton of alerting around CRL generation in their production environment. And given they had an incident earlier this year where one contributing factor was that they weren't paying enough attention to their CRL alerting in staging, I'm kind of surprised this got past them.
Though then again, it sounds like it was broken for several years and this is the first time someone noticed, which says, uh, something about how broken revocation usually is in practice.