Rodney Thayer <[EMAIL PROTECTED]>:
> how do I set up a hierarchy of signing certificates? I want to do this:
> root cert (generated with OpenSSL)
> -> signs Signing Certificate Two (generated with OpenSSL)
> -> signs User Certificate
> in other words, I need to generate a cert request for Signing Certificate Two
> and yet make it a valid root certificate. Do I have to do anything special?
Signing certificate two cannot really be a "valid root certificate"
because root certificates are self-signed (otherwise they wouldn't be
a root in the signing tree; however, the software accepting the
certificates may allow you to use non-self signed certs as root,
anyway). Of course, you can create two certificates for the same key
and subject name -- a self-signed one and one signed by your root CA.
To do this, you can first create both CAs as usual (including their
self-signed certs) and then do "openssl ca -ss_cert
cacert_of_2nd_level_ca.pem ..." (using "-ss_cert <filename>" instead
of "-in <filename>" means that the input is a X.509 self-signed
certificate rather than the usual certificate request). In an
additional step, you'd probably have to use Steve Henson's ca-fix
utility in order to make CA #2's certificate issued by CA #1 a valid
X.509v3 CA certificate ("-caset" option). (In this very moment you'll
be violating the X.509 standard because two different certificates
from the same issuer will exist sharing the same serial number [AFAIK
ca-fix does not change the serial number -- correct me if I'm wrong].
Really the "ca" utility ought to have an option allowing the signer to
set basic contraints [i.e. "cA" and "pathLenConstraint"]; maybe you
can already do this somehow by putting appropriate entries in oid.cnf
and ssleay.cnf?)
Note however that, if your certicate accepting software is
SSLeay/OpenSSL based, it usually shouldn't be configured to accept
non-flat hierarchies (i.e. CAs other than root CAs): The libary itself
does, as far as I know, not parse X.509v3 extensions and ignores them
even if they are marked critical. If you allow a depth of more than 1,
then any holder of a ("user") certificate situated at a lower depth
can issue certificates that OpenSSL will accept as valid, even though
that user certificate typically was never intended as a CA certificate.
Bodo M"oller
<[EMAIL PROTECTED]>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
