OK, then how do I re-issue my root CA certificate with my already
existing ca.key ?
If I could have a sample commande line for openssl it would help me .
something like
OPENSSL x509 -set_serial $SERIAL -clrext -extfile CA-EXTENSION.prm -days
$DURATION -CA $CAPREFIX-ca.cacert -CAkey $CAPREFIX-ca.key -in
$PREFIX-ca.crt -out $PREFIX-ca.der -outform der -sha256
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 !?
because it is ignored anyway in a trust anchor. A policy document specifies
mainly what you may put into end entity certificates that are created
under a PC
(and maybe what a certifying CA for your CA may put into a CA cert)
If you put it into intermediate CAs, they are filters indicating what that
CA can create, whether this is actually tested is still another story.
I though that it was "mandatory", meaning that it points to the place
where our PKI policy is defined .
Depending on what specification? You probably may want to put it into
end entities.
It does not hurt (much). Whether you want to put filters into CA
certificates, is another
story.
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 ?
As long as "you" own 7391, you organise the name space as you like and
there is no
(technical) semantics related to such a hierarchie.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
