Referring to CRL Distribution Point as quick hack?

[BGP4]

Hi,

referring to my Feature Request, is it possible to get a CRL Attribute quickly into a new Server Certificate?
MS Exchange Server, MS Remotedesktop, ... all need an valid CRL URL.
Its just a simple string...
Maybe there is a way to edit a template or pass sth?

[franco]

Hi,

> is it possible to get a CRL Attribute quickly into a new Server Certificate?

Well, as quick as you can reissue a certificate. But usually even then CRL DPs are relatively fringe in leaf certificates and lead to larger issues.

CRL validation is somewhat broken by design the imposed OpenSSL default behaviour of really not offering any mechanisms to fetch and update CRLs and many services therefore don't bother supporting it.

Turning it on can be fatal, especially for non-targeted applications that talk to more than one server you have control over to change and adapt the TLS certificate at your will.

I'm saying this not because it doesn't work. We've had to ensure CRL checking for our update servers but we've had to modify libfetch and curl and add more core fetch and management glue in order for it to work reliably (and it sometimes still fails for individual users, mostly because the CRL fetch is prohibited by another firewall in their network).


Cheers,
Franco

[Patrick M. Hausen]

> is it possible to get a CRL Attribute quickly into a new Server Certificate?

Well, as quick as you can reissue a certificate. But usually even then CRL DPs are relatively fringe in leaf certificates and lead to larger issues.

I guess they were referring to the fact that there is no field for the CRL distribution point in the OPNsense internal CA generation form, only OCSP URI, which is a different beast, altogether (although equally obsolete).

[franco]

That's because the distribution point needs to be managed and either externally or internally visible. OpenSSL also specifies "invisible" CRL DPs which it expects to be fetched by a client trying to verify a CRL on a certificate that doesn't offer CRL DP for "security" or "privacy" reasons.

The whole design is pretty broken by default so even if we added an input for an URL it would not help anyone. You still need the valid CRL (which expires and needs to be regenerated) from wherever you expect it at some point in time you try to verify at.

To be more precise: you do not need a CRL DP in the certificate in order for OpenSSL to verify a CRL. You simply have to provide a valid CRL at the time of verification with the correct switch to tell OpenSSL it should verify a CRL.


Cheers,
Franco

[Patrick M. Hausen]

According to the OP some version of MS Windows will not accept a private CA without a CRL DP - be it reachable or not. If I understood correctly they just want the option to follow the stupid book, not a functional implementation of an actual DP.

[franco]

A random string for security requirement reasons? Maybe I'm in the wrong field. ;)

[Patrick M. Hausen]

Security theatre [tm]

[franco]

I see the benefit of having it in this instance, but I think it causes more requirements and complaints in the future.

If you need a CRL DP for your own CA it's better to generate it elsewhere entirely or try signing an appropriate CSR.


Cheers,
Franco