Crashes when generating certificate

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Crashes when generating certificate

Christopher R
So I'm trying to create a certificate for a new user on my domain.
Created the certificate... got everything set up... went to use it and
the email is completely wrong.  Oops.  Missed it when I updated the
configuration file, and,unfortunately, its necessary, because login
depends on the email associated with the certificate.

Ok, take 2.  Delete everything.  Delete the certificates, the request,
all of it for that new user.  Correct the config file and try again.
Gets to the end and throws TXT_DB Error number 2.  Look it up and its
because a certificate with that common name is already in the
database.  Someone recommends editing that certificate out of the
database, so I pull up the index file, find the line for the incorrect
certificate, and delete it.

Cool.  Take 3.  Generates the key and the request.  Try generating the
certificate... it asks for a password and then does... nothing.  Kicks
directly to command prompt.  No error.  No lines of text.  No
questions.  Nothing created.  Password->command prompt.  What is going
on here and how do I fix this?

All I want is whatever remnants of that incorrect certificate removed,
where ever they are, and a correct certificate created.
Reply | Threaded
Open this post in threaded view
|

Re: Crashes when generating certificate

Karl Denninger


On 5/13/2019 16:44, Christopher R wrote:
So I'm trying to create a certificate for a new user on my domain.
Created the certificate... got everything set up... went to use it and
the email is completely wrong.  Oops.  Missed it when I updated the
configuration file, and,unfortunately, its necessary, because login
depends on the email associated with the certificate.

Ok, take 2.  Delete everything.  Delete the certificates, the request,
all of it for that new user.  Correct the config file and try again.
Gets to the end and throws TXT_DB Error number 2.  Look it up and its
because a certificate with that common name is already in the
database.  Someone recommends editing that certificate out of the
database, so I pull up the index file, find the line for the incorrect
certificate, and delete it.

Cool.  Take 3.  Generates the key and the request.  Try generating the
certificate... it asks for a password and then does... nothing.  Kicks
directly to command prompt.  No error.  No lines of text.  No
questions.  Nothing created.  Password->command prompt.  What is going
on here and how do I fix this?

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.

In the future REVOKE the one with the bad information, and you can then create a new one under the same common name.  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.  The better choice when an error is made is to revoke the bad cert, which prevents this from happen.

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Crashes when generating certificate

Skip Carter
In reply to this post by Christopher R
Christopher,

On Mon, 2019-05-13 at 16:44 -0500, Christopher R wrote:

> Cool.  Take 3.  Generates the key and the request.  Try generating
> the
> certificate... it asks for a password and then does...
> nothing.  Kicks
> directly to command prompt.  No error.  No lines of text.  No
> questions.  Nothing created.  Password->command prompt.  What is
> going
> on here and how do I fix this?
>

that sounds like the CA server has a password set and you are not
providing it.
 



--
Dr Everett (Skip) Carter
[hidden email]

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103



signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Crashes when generating certificate

Michael Wojcik
In reply to this post by Karl Denninger
> From: openssl-users [mailto:[hidden email]] 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



Reply | Threaded
Open this post in threaded view
|

Re: Crashes when generating certificate

Karl Denninger
On 5/14/2019 09:48, Michael Wojcik wrote:
From: openssl-users [[hidden email]] 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.

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.  If there's a collision in there (which could happen if the serial number is reused) "bad things" could happen.  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.

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.

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Crashes when generating certificate

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] 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


Reply | Threaded
Open this post in threaded view
|

Re: Crashes when generating certificate

OpenSSL - User mailing list
On 14/05/2019 18:39, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] 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