RE: RE: How to create indirect CRL using openssl ca command
> From: edr > Sent: Friday, 11 March, 2022 03:59 > > On 10.03.2022 20:27, Michael Wojcik wrote: > > Personally, I'd be leery of using openssl ca for anything other than > dev/test purposes, in which case frequent CRL generation seems unlikely to > be a requirement. AIUI, openssl ca isn't really intended for production > use. > > I did see the RESTRICTIONS [1] and WARNINGs [2] sections in the openssl-ca > documentation. I think that I can handle the problems described there but > would still be interested if you have any concerns beyond those warnings > and the functional limitations I am currently running into. My concerns are more general. CAs are tricky. Even dev/test CAs are not trivial to get right, and corporate CAs generally have a lot of requirements. (We recently revamped our internal corporate CA, and even after an extensive requirement-gathering process we're still shaking out issues.) Commercial CAs, of course, are much worse. But even for internal CAs, you'll have to comply with various CA/BF requirements if you want to issue server certificates that current browser releases will accept, for example. So building a CA out of what is essentially a utility for experimentation and testing raises a red flag. Beyond that, "openssl ca" does not by itself do many of the things you'd want even an internal production CA to do. It doesn't provide any change management or backup of the database. It doesn't audit. It doesn't provide access control. Those are all things that need to be added on top of that, and if you're going to do that, it seems like looking for a solution that already addresses at least some of those issues might be a better option. > Also what (open source) ca software do you recommend instead? I've never had to build a production CA, so I don't have any suggestions, I'm afraid. And even if I had, I don't know what your use cases are, so I wouldn't know how well they mapped to my (hypothetical) ones. Different entities will have some difference in requirements. -- Michael Wojcik
Aw: RE: How to create indirect CRL using openssl ca command
On 10.03.2022 20:17, Michael Ströder via openssl-users wrote: > > Are you 100% sure all the software used by your relying participants is > capable of handling the X509v3 extensions involved? > > In practice I saw software miserably fail validating such certs and CRLs. Or > also CAs failed to generate the certs and CRLs correctly. :-/ > That is a very good point you are making - thank you for this input. On 10.03.2022 20:27, Michael Wojcik wrote: > Personally, I'd be leery of using openssl ca for anything other than dev/test > purposes, in which case frequent CRL generation seems unlikely to be a > requirement. AIUI, openssl ca isn't really intended for production use. I did see the RESTRICTIONS [1] and WARNINGs [2] sections in the openssl-ca documentation. I think that I can handle the problems described there but would still be interested if you have any concerns beyond those warnings and the functional limitations I am currently running into. Also what (open source) ca software do you recommend instead? Thanks again [1] https://www.openssl.org/docs/man1.0.2/man1/ca.html#RESTRICTIONS [2] https://www.openssl.org/docs/man1.0.2/man1/ca.html#WARNINGS
RE: How to create indirect CRL using openssl ca command
> From: openssl-users On Behalf Of > Michael Ströder via openssl-users > Sent: Thursday, 10 March, 2022 12:17 > > On 3/10/22 14:06, edr dr wrote: > > At the same time, I do not want to store passwords used for > > certificate creation in cleartext anywhere. Personally, I'd be leery of using openssl ca for anything other than dev/test purposes, in which case frequent CRL generation seems unlikely to be a requirement. AIUI, openssl ca isn't really intended for production use. > It's a pity that there is not something like an OpenSSL key agent > (similar to ssh-agent) for interactively loading the CA's private key > into memory during service start. To be fair, this is not an OpenSSL limitation; it's a limitation of openssl, the utility. Which, again, is not intended to solve all production use cases. openssl ca, like most openssl subcommands, allows the use of an engine (or provider in 3.0), which means in many cases it's possible to use an inexpensive USB-attached HSM (via the pkcs11 engine) rather than having an on-disk key in the first place. I did this some years ago as an experiment using a NitroKey and it worked well. -- Michael Wojcik
Re: How to create indirect CRL using openssl ca command
On 3/10/22 14:06, edr dr wrote: I would like to be able to automate the process of updating CRLs in order to be able to keep the CRL validity time short. Understandable. At the same time, I do not want to store passwords used for certificate creation in cleartext anywhere. It's a pity that there is not something like an OpenSSL key agent (similar to ssh-agent) for interactively loading the CA's private key into memory during service start. My current approach to achieve this is a separate CA only responsible for revocation. My understanding is that such a CA is called an "indirect CRL issuer" Are you 100% sure all the software used by your relying participants is capable of handling the X509v3 extensions involved? In practice I saw software miserably fail validating such certs and CRLs. Or also CAs failed to generate the certs and CRLs correctly. :-/ Ciao, Michael.
How to create indirect CRL using openssl ca command
Dear all, I am building a private PKI using the openssl "ca" functionality. My setup includes a root CA that issues intermediate certificates and intermediate CAs issuing endpoint certificates. I would like to be able to automate the process of updating CRLs in order to be able to keep the CRL validity time short. At the same time, I do not want to store passwords used for certificate creation in cleartext anywhere. My current approach to achieve this is a separate CA only responsible for revocation. My understanding is that such a CA is called an "indirect CRL issuer" so I'll refer to this separate CA in my setup as "indirect-revoker". The indirect-revoker needs to be able to revoke intermediate certificates issued by the root CA as well as endpoint certificates issued by the intermediate CAs. This is what I did configuration-wise: I referred to the indirect-revoker in the crlDistributionPoints setting as follows: crlDistributionPoints = my_cdp ... [ my_cdp ] fullname = URI:file:///home/me/tmp/ca3/intermediate/indirect-revoker/crl/ca.crl.pem CRLissuer = dirName:crl_issuer_section [ crl_issuer_section ] C = DE O = My Organization OU = My organizational unit CN = indirect-revoker The generated certs contain the desired information, so that seems okay: $ openssl x509 -in ~/tmp/ca3/intermediate/revoked/certs/ca.cert.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 4097 (0x1001) Signature Algorithm: sha256WithRSAEncryption Issuer: C = DE, O = My Organization, OU = My organizational unit, CN = rootca Validity Not Before: Mar 10 12:37:52 2022 GMT Not After : Feb 14 12:37:52 2122 GMT Subject: C = DE, O = My Organization, OU = My organizational unit, CN = revoked Subject Public Key Info: ... X509v3 extensions: X509v3 CRL Distribution Points: Full Name: URI:file:///home/me/tmp/ca3/intermediate/indirect-revoker/crl/ca.crl.pem CRL Issuer: DirName:C = DE, O = My Organization, OU = My organizational unit, CN = indirect-revoker Signature Algorithm: sha256WithRSAEncryption To activate the indirect CRL mode I have added the following crl extensions to indirect-revoker's config: crl_extensions= crl_ext [ crl_ext ] authorityKeyIdentifier=keyid:always issuingDistributionPoint = critical, @idp_section [idp_section] indirectCRL = TRUE This seems to work so far, or at least it is included in the text output of crls generated that way: $ openssl crl -in crl/ca.crl.pem -text -noout Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: C = DE, O = My Organization, OU = My organizational unit, CN = indirect-revoker Last Update: Mar 10 10:32:30 2022 GMT Next Update: Apr 9 10:32:30 2022 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:50:54:61:18:41:51:EF:1A:08:CA:D7:CF:B7:4F:C7:05:B8:C3:41:D1 X509v3 Issuing Distribution Point: critical Indirect CRL X509v3 CRL Number: 4096 Revoked Certificates: Serial Number: 1001 Revocation Date: Mar 10 10:32:30 2022 GMT Signature Algorithm: sha256WithRSAEncryption ... Now section 5.3.3 in RFC 5280 [1] states that crl entries in indirect CRLs need to include the information which CA issued the revoked certificate. As can be seen in the text output above the CRL Entry only contains the CRL Number but not the certificate issuer, which I believe is needed to properly match the CRL entry to the revoked certificate. Sure enough the verification still recognizes revoked certs included in the crl as valid: $ openssl verify -CAfile ~/tmp/ca3/rootca/certs/ca.cert.pem -CRLfile ~/tmp/ca3/intermediate/indirect-revoker/crl/ca.crl.pem ~/tmp/ca3/intermediate/revoked/certs/ca.cert.pem /home/me/tmp/ca3/intermediate/revoked/certs/ca.cert.pem: OK So my question is: how do I get this piece of information into the CRL? The openssl documentation [2] explicitly states that the -crlexts option is not meant for this: "The CRL extensions specified are CRL extensions and not CRL entry extensions. " I could not find any other options that looked appropriate. I also inspected the openssl source code [3] and it looks to me as if the filename of the revoked certificate is never written to the "index" file, so I do not think that it can simply be read from the revoked certificate upon CRL generation. What am I missing? Any hints would be greatly appreciated! Kind regards, edr [1] https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.3 [2] https://www.openssl.org/docs/man3.0/man1/openssl-ca.html [3]
