Bodo Moeller wrote:
>
>
> 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].
Yes you are correct ca-fix doesn't change the serial number. The serial
conflict can be avoided by either creating a certificate request for CA
#2 or converting its certificate into a request and then have CA #1 sign
it.
> 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?)
>
You can't currently do this but I'm developing some extension handling
code to allow this to be done. You would end up adding a line like this:
basicConstraints=critical, CA:TRUE, pathlen:10
for example.
> 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.
Some software gets round this by not doing chain verification: so that
all subordinate CA's need to be trusted as well.
This is a kludge and the proper thing is to have chain verification in
the verify routines. This is on my list of "things to do".
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
