On 14/05/2019 18:39, Michael Wojcik wrote:
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.
Despite its obvious shortcomings, I have yet to find another ca program
suitable for offline use on a small command-line only machine. Everything
I have found has been bloated GUI stuff with builtin web servers and other
unwanted garbage.
It would be nice if a good command-line offline CA product existed, but
until then, disciplined use of the OpenSSL ca "sample" command seems to be
the best there is.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
