Le 25/08/2009 20:09, Patrick Patterson a écrit :
The only way to add this extension to your
root cert is to re-issue your Root CA certificate (you can use the same
private keys, so you wouldn't have to change or re-do any of the other
certificates in your trust chain, as long as your Certificate Policy allows
this).
OK, then how do I re-issue my root CA certificate with my already
existing ca.key ?
I only see example to create a CA self signed from scratch (both key and
certs), but not from an already existing key :
openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout
private/myca.key -out certs/myca.crt -days 1825
openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem \
-out cacert.pem -days 3650 -config ./openssl.cnf
where should I introduce my ca.key ?
If I could have a sample commande line for openssl it would help me .
Now, while you are at it, you may want to fix up a couple of things: First of
all, it is generally considered to be ill advised to create a
certificatePolicy section in a Root CA. This is in case you ever change the
assurance levels / certificate Policy OID that your PKI issues (among other
reasons - see RFC3280 and RFC5280). Second, I doubt your organisation is
authoritative for the OID arc 1.1.1.1.1 - from what documentation I can find,
the 1.1 arc is used for examples, and shouldn't be used in production. You
should have your organisation register with IANA to be issued its own correct
OID arc (or, I think the French Government maintains an arc under their
country arc for organisations and companies in that country). Also, since Root
CA Certificates are not revoked by CRL (Please see RFC3280/RFC5280 for trust
anchor verification), it is not considered good practice to have CRL DP in the
root cert. And, having an AIA that points to itself is simply not that great
an idea :)
OK, I will coorect these extensions with an appropiate openssl.cnf ,
but I don't understand why there shouldn't be a certificatePolicy
section in my master root_CA !?
I though that it was "mandatory", meaning that it points to the place
where our PKI policy is defined .
For oid 1.1.1.1.1, years ago we did reserved a IANA oid number
(1.3.6.1.4.1.7391 )
we used 7391.2 for ldap, 7391.1 for snmp, is there a recommandation for
certificates or 7391.3 would be fine ?
My "Master" root CA (IT_ROOT_CA) signed a intermediate (sub IT_CA) CA,
that finally signed 3rd level local schools CA (Paris_CA etc .. those
finally signed servers ...), then that "Master" root CA should (?)
maintained a CRL for the Sub CA (2nd level) certificate, no ?
IT_ROOT_CA
|
-------------IT_CA--------------
| | |
Evry_CA Paris_CA Brest_CA
|
|------------|
www imap ....
Regards .
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
