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?
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
Quote from: franco on October 06, 2025, 11:47:48 AM> 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).
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
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.
A random string for security requirement reasons? Maybe I'm in the wrong field. ;)
Security theatre [tm]
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
The Problem is, for internal RDP Access or internal Exchange CA, we need a CRL Url, as MS forces it to be present.
It is not about OCSP/CRT which one is better or if it is useful. It is just about what MS dictates. Thats the law.
Currently we can make CRL files, but the URL is not included in the Certificate.
We just would need a simple Attribute for the CRL, which could be manually entered (or defaulted).
This would be no security risk. it does not need to be managed.
Also it would be good practice and a useful optional feature to just set the url.
It would be very easy to implement (i guess 10 minutes ;-), it has not disadvantage and is logical, as it adds a connection to the already offered crl.
Currently it is strange, that we can make CRL but not add them to certs anyway.
Nevertheless if opnSense would upload and maintain the CRL list using sftp on a webserver it would be perfect.
But this would be much work todo, so i did not suggest the full feature.
It is good practice, to use your own CA for management devices etc.
The own CA is better than any third-party one imho.
Also for internal IPs it is not possible to gain Certs from big CAs.
If a CRL is not set, we are forced to use the self-signed snail certs from MS or have to deploy AD Certs...