Enabling CRL breaks Dot1x authentication when cert chain does not specify CRL

I have discovered an interesting wrinkle with how RouterOS handles CRL that I wanted to share in case someone else is dealing with a similar issue.

For a long time, I have noticed that I get errors in the log if I enable CRL relating to my DoH configuration:

DoH server connection error: SSL: ssl: crl not found for: "C=AT, O=ZeroSSL, CN=ZeroSSL ECC Domain Secure Site CA" (6)

I thought this was a bug for a long time, but Mikrotik support informed me it’s because the intermediate certificate for my DoH provider (NextDNS) is not installed in the router. Installing the intermediate certificate (the one referenced in the error above) fixed this particular issue.

But then I discovered that, after rebooting, my router would not do the 802.1x authentication to my ISP’s OLT (AT&T fiber). It got stuck on “connecting…”, usually. Sometimes it would get stuck on “authenticating…” or just say “rejected”. I finally figured out that it was because I had “use crl” turned on for certificates.

I don’t understand why it should matter. I have the full chain installed on the router (4 certs). None of them has a CRL specified. I don’t know why it would prevent the 802.1x auth from working to use CRLs. I would think it would just ignore the installed certificate chain(s) that don’t specify CRLs, but apparently it breaks things.

In any case, this is a quirk of RouterOS (maybe a bug?) that I wanted to get Google to index in case someone else runs into it.

If the router is instructed to use the CRL, but there is no CRL...
The router does its job by not considering certificates that do not have a CRL as valid... You told it...

But that doesn’t make sense to me. If the certificate issuer says there’s no CRL, then there’s no CRL and the router should just ignore that cert.

I suppose MikroTIk’s implementation is erring on the side of caution/least trust, but it just seems like it’s being intentionally difficult in this case.

If you were a security guard posted at the entrance to a venue
and were told not to let anyone in with an expired or revoked pass,
would you still let in those who didn't have a pass at all?

Regardless, the overall decision to not use CRLs and instead switch to a short certificate validity period is more logical.

How many times will you ever encounter a revoked certificate?

Thanks for the analogy, it was actually pretty helpful. Yeah, I’ve never dealt with revoked certificates. It just seemed like a good thing to enable, just in case.

What would be ideal is to include a flag on whether to allow certs without a CRL, when CRL verification is on. But that probably introduced vulnerabilities.