> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of Karl Denninger > Sent: Tuesday, May 14, 2019 09:22 > On 5/14/2019 09:48, Michael Wojcik wrote: > > I can't think of what remnant of the old certificate would be there, > > except the certificate itself, in whatever the configuration file > > specifies for the new_certs_dir. And I've never seen that cause this problem. > There's a directory (by default "newcerts" but can be changed in the config > file) that has a copy of the certs that OpenSSL generates. Yeah, that's the new_certs_dir that I referred to. (That's the name of the config file setting.) > If there's a collision in there (which could happen if the serial number is > reused) "bad things" could happen. Right, the filename is taken from the serial number. So if the ca app does something like an open(..., O_CREAT | O_EXCL), and that fails, it might quit. > I've not looked at the code to see if that would cause a bomb-out but the > risk with playing in the database file, although it's just a flat file, > and/or the serial number index is that you can wind up with conflicts. Agreed. Let's see... In 1.1.1b, the ca app does a BIO_new_file for the new certificate file, and if that returns null, it does a perror followed by a goto end. I don't know what version the OP is running, though, and that perror may be missing in older OpenSSL releases. (Why do people post questions without identifying their OpenSSL version, platform, and so on?) Interestingly, right before that the ca app does a bio_open_default on outfile, which is the argument of the -out option (if any) or null for the default (stdout, I think); and if *that* fails it does a goto end without a perror. So if OP's command line has a -out and that file can't be open for output, ca will exit silently. > The "ca" function in openssl lacks the sort of robustness and "don't do that" > sort of protections that one would expect in a "production" setting. That's not > say it can't be used that way but quite a bit of care is required to do so > successfully, and toying around in the database structure by hand is rather > removed from that degree of care. Oh, definitely. I wouldn't recommend using openssl ca for any sort of production use unless you're confident you understand how openssl ca works, how PKIX works, how production CAs are supposed to work, and any details particular to your use, such as CA/BF requirements if you want to generate certificates for HTTPS servers. And then you need a lot of infrastructure around the ca app, including at least partial automation for all the CA operations, a mechanism for key hygiene, backups, auditing, and so on. Unfortunately, the CA function isn't really suitable for a free turnkey implementation (too many variables, too many infrastructure requirements), but customers who don't already have some kind of organizational CA need some way to get started with TLS. For many years we've shipped a demonstration CA based on openssl ca plus some scripts with some of our products, and some customers insist on using it in production, despite our warnings against it. I'm not happy about it, but we haven't found a good alternative. -- Michael Wojcik Distinguished Engineer, Micro Focus
