> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Karl Denninger > Sent: Monday, May 13, 2019 16:32
> On 5/13/2019 16:44, Christopher R wrote: > > All I want is whatever remnants of that incorrect certificate removed, > > where ever they are, and a correct certificate created. > Not sure what you have left, but probably in the certs directory. 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. > In the future REVOKE the one with the bad information, and you can then > create a new one under the same common name. Seconded. This is the right way to replace an incorrectly-generated certificate. Even if you're not providing revocation information to your users (not publishing a CRL, not running an OCSP server), use "openssl ca -revoke" to revoke the old certificate. There are any number of tutorials online. > Since the index file is a flat file you can edit it, but you also have > to make sure the other places it references are also updated or the > software can get confused. Editing the CA database is a Bad Idea, in my opinion. If you must, take a backup first. In fact, if you're not prepared to at any moment lose your CA information and have to recreate your CA from scratch, you should have all of those files backed up. I put them in change management, so that I can also diff and revert to an earlier version. (Of course if your CA is used for anything other than local testing you'll want to be careful with your key hygiene; don't let an attacker get the CA private key from a backup. Encrypting the key helps but then you're relying on the entropy in the key passphrase.) -- Michael Wojcik Distinguished Engineer, Micro Focus
