"Dave Thompson" <dthomp...@prinpay.com> 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 <form> 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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
