Re: Crashes when generating certificate

[Jakob Bohm via openssl-users]

On 14/05/2019 18:39, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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

RE: Crashes when generating certificate

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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

Re: Crashes when generating certificate

[Karl Denninger]

On 5/14/2019 09:48, Michael Wojcik wrote:
>> 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.

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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Crashes when generating certificate

[Michael Wojcik]

> 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

Re: Crashes when generating certificate

[Skip Carter]

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
s...@taygeta.com

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




signature.asc
Description: This is a digitally signed message part

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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

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.