> From: edr <e-d-r@xxxxxx> > 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
