Re: Openssl req command

[Jamrock]

"Dave Thompson"  wrote in
message news:ee558ada74ef4896a656a182b39d9...@prinpay.com...
> > From: owner-openssl-us...@openssl.org On
Behalf Of Jamrock
> > Sent: Sunday, 30 May, 2010 06:35
>
> >  In the past I have created my certificates as follows:
> > /etc/pki/tls/misc/CA -newca
> >
> > openssl req -newkey rsa:2048 -nodes -keyout newreq.pem -out newreq.pem
> >
> > /etc/pki/tls/misc/CA -sign
> >
> > The /etc/pki/tls/misc/CA script has a -newreq option. $REQ
> > -new -keyout
> > newkey.pem -out newreq.pem $DAYS.
> >
> > This appears to put the key and the certificate in different
> > files. The
> > command I use appears to put the key and the certificate in a
> > single file.
> > What are the advantages and disadvantages of each approach?
> >
> I guess/hope /etc/pki/tls/misc/CA is a copy (possibly modified) of
> or link to openssl's apps/CA.sh; assuming so:
>
> Your method puts the Certificate Signing *Request* aka CSR
> and (unencrypted!) privatekey in one file. CA.sh -sign does
>   openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem
> so the *certificate* is in newcert.pem, and that's the (other) file
> you must give your application to use for this identity.
>
> In a real CA situation, where you send the CSR off somewhere
> to get a cert, you absolutely must not send your unencrypted
> private key, and having it in the same file risks that mistake.
> Even post-editing might not work; while no CA I've heard of
> uses MSWord files or PDF, if for example you paste your key+req
> into a vanilla HTML  and delete the key and then POST
> you're okay, but if that HTML used some 'helpful, convenient'
> scripting to 'make things better for the customer', or just to
> 'keep advertising annoyingly at every opportunity', it could
> easily have stored your key somewhere that later gets exposed.
> If you're careful pasting and your finger doesn't slip you can
> avoid this, but with separate files you don't have to worry.
>
> If you encrypted your privatekey, as is better practice, then
> there would be somewhat less security risk in sending it out,
> but still some since it's only protected by a human-memorable
> passphrase which almost never contains the 80ish bits of
> entropy needed nowadays (and likely more in the future).
> Plus it could confuse the CA, depending on the CA.
>
> But for your own CA like this there's no security issue,
> and 'openssl ca' in particular isn't confused by this format.
>
> Also, it is technically possible to create multiple CSRs
> and thus obtain multiple certs for the same key(pair),
> although I have never seen a desirable use-case. If you did
> do this, putting the CSRs in separate files would allow you
> to give them descriptive, necessarily different, filenames,
> which be a good idea in dealing with a situation that could
> easily be(come) confusing. (And the same for the certs.)
>

Thanks for the explanation.  I will test using 2 separate files.

The CA script is CentOS's version of the CA.sh script.  The name was changed
a version or so ago.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Openssl req command

[Jamrock]

 In the past I have created my certificates as follows:
/etc/pki/tls/misc/CA -newca

openssl req -newkey rsa:2048 -nodes -keyout newreq.pem -out newreq.pem

/etc/pki/tls/misc/CA -sign

The /etc/pki/tls/misc/CA script has a -newreq option. $REQ -new -keyout
newkey.pem -out newreq.pem $DAYS.

This appears to put the key and the certificate in different files. The
command I use appears to put the key and the certificate in a single file.
What are the advantages and disadvantages of each approach?



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL and Windows

[Jamrock]

 I have been using OpenSSL for a few years. I have mostly used it to encrypt
OpenLDAP data. Recently I started using it to encrypt Postfix queries from a
Linux box to Active Directory on a Windows box.
I used Microsoft's article 321051 "How to enable ldap over ssl with a
third-party certification authority". Basically the article states how to
create a certification request on the Windows box, have it signed by the CA
and import it into Windows.

Here are a few observations. I hope the openssl gurus can comment on the
accuracy of my findings.  I am trying to get a better understanding of
OpenSSL.

When I used the default settings of the /etc/pki/tls/openssl.cnf file,
Windows rejected the signed certificate because it said the CA was not
configured to sign certificates.

I had read of success stories using Tiny CA to create certificates for
Windows servers.  I tried it on a test machine. I realized that Tiny CA's
default settings were different from the default settings in openssl.cnf. I
then changed the settings in openssl.cnf to match those of Tiny CA and
Windows accepted the CA and the signed certificate.

For example I uncommented the following values on the v3_ca section:

keyUsage

nsCertType

subjectAltName

issuerAltName

Do people on the list normally edit the v3_ca and usr_cert settings in
openssl.cnf before using them?

I changed the x509_extensions value in the CA_default section depending on
the type of certificate I was going to create. I set it to v3_ca when
creating a CA and back to usr_cert when creating a certificate for the
Windows machine.

Is this the correct approach?



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org