Cannot import crl certificates

[fgerardi]

The system/trust/revocation section in the webui lacks of the add button...how can I import a new crl certificate?

Any help?

[doktornotor]

Click the pencil for a CA listed there, select "Import existing" from the Method dropdown?

[fgerardi]

Hi, thank for your reply...Unfortunately your suggestion does not solve the issue: first of all, even if it worked, I would rewrite the older crl certificate that, maybe, I still need for different cases...second, I tried to overwrite the crl certificate like you said but when I try to apply the changes I get an error "Certificate does not seem to exist" corresponding to the CA certificate...
Should I delete the referenced CA and then reimport it? But it is referenced sever times in the configuration...

[doktornotor]

even if it worked, I would rewrite the older crl certificate that, maybe

Huh? Yeah, it will rewrite it. There is exactly ONE valid CRL. The latest.

[fgerardi]

The 24.X allowed to import several versions of crl certificates. And this makes perfect sense to me and allows administrator to revert quickly to older (still valid) versions in case of error. Also, allows to update one configuration at a time (for example, starting with a test service). This way I am forced to update all the services depending on that CA at the same time.
That said, it is not working! the new crl is not accepted and raised errors.

[doktornotor]

The 24.X allowed to import several versions of crl certificates. And this makes perfect sense to me

Yes, that was absolute nonsense. Finally it's gone.

the new crl is not accepted and raised errors.

Then perhaps post the errors...

[Patrick M. Hausen]

The 24.X allowed to import several versions of crl certificates.

What's a CRL certificate? There is no such thing. A CRL is a Certificate Revocation List. A list of all serial numbers of all certificates a specific certification authority declares as on hold or revoked. There only ever is one valid such list per certification authority.

The publishing of a new CRL immediately invalidates all previous ones. "On hold" status for specific certificates can be reverted by publishing a new one. Reverting to an older CRL is not part of the protocol.

[franco]

Just as a data point I worked with the big commercial CAs back in the day and nobody had multiple CRLs. There's nothing that says you can't have them, but the CA only ever points to one for good reasons... you cannot micromanage revocation based on application or use cases because in most cases your CRL is public so people need to rely in exactly that one single CRL to tell you as an external entity which certificates from that CA have been revoked. Quite important for S/MIME signatures and stolen certificates and impersonation...


Cheers,
Franco

[fgerardi]

One reply for all your comments...
I know very well what a crl certificate is as I am been working in the security business for decades now.
I also know very well the "good reasons" mentioned by @franco where a CA must publish a single crl as a unique (reliable) source of information.
My point is that in the scenario described the opnsense firewall is NOT the CA that is publishing the crl. It is just one of (possibly) many devices that are using it. The goal of the administrator is to keep the configuration working and being able to quickly switch configuration objects in order to keep it running and secure. That is the exact reason why all major industry security devices are using object oriented configuration strategy.
Whoever says that the current way of managing certificates in opnsense is better then the older way never worked in a complex production environment or just don't care.
The errors in importing the external certificates has been reported in my previous posts and one just need to read them.
I can only add that now opnsense is not even able to recognized that an external certificate has been signed by an external imported CA! And that's exactly why an error is raised whenever I try to update the crl certificate...because the device is not able to link the certificate to the imported CA.

[doktornotor]

Look, you have developed some extremely broken workflow around a misfeature that never should have been there. Need to replace a certificate? Then issue a new certificate, install it, configure it for all places which happen to be using it, and only AFTER that revoke the old certificate. I would hazard to say that's what about 99% of users do. Instead of developing a concept of "per-application" CRL.

The errors in importing the external certificates has been reported in my previous posts and one just need to read them.

Good luck, don't have time for post hunting.

[franco]

I agree, a GitHub ticket for reasonable requests or production bugs is a good start to gain traction.


Cheers,
Franco

[fgerardi]

Look, you have developed some extremely broken workflow around a misfeature that never should have been there. Need to replace a certificate? Then issue a new certificate, install it, configure it for all places which happen to be using it, and only AFTER that revoke the old certificate. I would hazard to say that's what about 99% of users do. Instead of developing a concept of "per-application" CRL.

The errors in importing the external certificates has been reported in my previous posts and one just need to read them.

Good luck, don't have time for post hunting.

If you do not care of reading what other people wrote there is no need to post at all with all your non-sense comments. Goodbye

[doktornotor]

Have a nice day as well.   

[franco]

Let's be nice and conclude that GitHub tickets are the best way forward...

[fgerardi]

I agree, a GitHub ticket for reasonable requests or production bugs is a good start to gain traction.


Cheers,
Franco

My several attemps to update the crl certificate even caused a crash in the system and I correctly uploaded the crash report as suggested.