Again thanks Dave. I figured out my last question about the Signature algorithm. Signed cert is working perfectly on my device.
On Fri, May 17, 2013 at 7:59 PM, Stan Joyner <swj2...@gmail.com> wrote: > Thanks Dave for the quick response. It helped a lot. > > One last question and I think I'll have what I need. (And yes I am very > new to openssl.) > > I was able to produce the self signed Root CA, the intermediate CA, and > then sign my server device CA with the intermediate CA. I was able to use > openssl verify to make sure my server certificate was OK. > > I used "openssl x509 -in cert-name.pem -text -noout" to inspect all three > pem files. I see that I ended up a signature algorithm of edcsa-with-SHA1 > when I wanted ecdsa-with-SHA384 in each of them. > > Here are the commands I used. Trying to figure out how to change them to > make the ROOT CA. Intermediate CA and Device Certificate have SHA384 as > the signature algorithm instead of SHA1. After I get that; I think I am set. > > Generate Key and Self Signed Root CA > ============================= > a) openssl ecparam -out ca.key -name secp384r1 -genkey > > b) openssl req -new -x509 -days 3650 -key ca.key -out ca.crt > > c) openssl x509 -in ca.crt -out ca.pem > > d) openssl x509 -in ca.pem -text -noout > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > e6:8e:45:5f:bf:55:4a:10 > Signature Algorithm: ecdsa-with-SHA1 <<<<< Want ecdsa-with-SHA384 > > > Generate Key and Intermediate Cert > ========================== > a) openssl ecparam -out ca-int.key -name secp384r1 -genkey > > b) openssl req -new -key ca-int.key -out ca-int.csr -subj "/CN= > ca-...@acme.com" > > c) openssl x509 -req -days 3650 -in ca-int.csr -CA ca.crt -CAkey ca.key > -set_serial 01 -out ca-int.crt > > d) openssl x509 -in ca-int.crt -text -noout > > Certificate: > Data: > Version: 1 (0x0) > Serial Number: 1 (0x1) > Signature Algorithm: ecdsa-with-SHA1 <<<< Want ecdsa-with-SHA384 > > > > Sign Server CSR from device > ===================== > a) openssl x509 -req -days 3650 -in server.csr -CA ca-int.crt -CAkey > ca-int.key -set_serial 01 -out server.pem > > b) openssl x509 -in server.pem -text -noout > Certificate: > Data: > Version: 1 (0x0) > Serial Number: 1 (0x1) > Signature Algorithm: ecdsa-with-SHA1 <<<< Want ecdsa-with-SHA384 > > > > > Thanks, > > Stan > > > > > > On Fri, May 17, 2013 at 6:20 PM, Dave Thompson <dthomp...@prinpay.com>wrote: > >> >From: owner-openssl-us...@openssl.org On Behalf Of Stan Joyner >> >Sent: Friday, 17 May, 2013 16:14 >> >> >I have the following in place: >> >1. Certificate Signing Request from a device. >> >2. Root CA I generated via these openssl commands: >> >openssl ecparam -out ec_param.pem -name secp384r1 >> >openssl req -new -x509 -days 3650 -extensions v3_ca -keyout >> private/ec_cakey.pem >> >-out ec_cacert.pem -newkey ec:ec_param.pem -config openssl.cnf >> >> >I am able to sign my CSR with this Root CA and everything works fine. >> >The device can install the certificate and a peer device using the >> >root CA can verify it as part of a TLS exchange. So the CSR is good >> >and the root CA is good. >> >> Nit: a CA, such as your root CA, does NOT sign a CSR. It signs a cert >> which is based on the CSR but not the same. Many people get this wrong. >> >> >What I would like to be able to do is the following: >> >1. Sign Root CA with intermediate CA; again with secp384r1 >> >> That makes no sense. The root is selfsigned and must remain so >> or it isn't a root. An intermediateCA cert can be signed (issued) >> with/by the root. (Or by a higher-level intermediate, but you >> don't have that yet; see below.) >> >> >2. Sign my device Certificate with that Intermediate CA. >> >Every attempt I have made has ended when I tried to sign >> >my device CSR with the intermediate CA. >> >Always get errors about not being able to load private keys at that >> point. >> >> Then you did something wrong. You'll have to be much more specific. >> >> As an outline, what you should do (in total) is: >> 1 create root key and cert (as you did above is okay) >> (to be pedantic what you create is a keypair -- private plus public. >> but openssl keeps both 'halves' in one data structure in one file.) >> 2 create level1 *CSR* and preferably key, and use root to issue level1 >> cert >> - technically you could use the same key(pair) for root and level1, >> but it's better to generate a new key. This can be done separately >> but combining it with req -newkey as you did for root is fine. >> - level1 CSR must have a different DN than root (and resulting cert >> will); >> with the standard openssl.cnf you are prompted for the DN fields and >> must type different data; if you modified conf to "hardcode" the DN >> you need to hardcode a different value for level1 than for root >> - there are two ways to issue a child cert: x509 -req -CA* and ca, which >> are similar but not identical. Which did you use or do you want? >> Depending on the endpoints that will use these certs you may need to >> specify CA-suitable extensions (such as standard v3_ca) and not >> the EE-extensions provided by ca's standard default usr_cert. >> (x509 -req -CA* has no extensions by default, not even copy.) >> 3 use level1 key and cert with device CSR to issue device cert. Same >> two ways, except you (probably) do want extensions like usr_cert. >> >> >I also need to be able to do this with a depth of 3; (RootCA + CA1 + >> CA2). >> >> Repeat 2 as needed: do level1 under root, then level2 under level1, >> then device(s) under level2 if that's what you want. You must give >> them distinct DNs, and I recommend using meaningful ones. >> >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> > >
