On Fri, Nov 21, 2003, Dave Roberts wrote: > On Thu, 20 Nov 2003, Dr. Stephen Henson wrote: > > > Cert1 has keyUsage keyCertSign set. Its issuer and subject names are > > identical. > > > > Cert2 includes keyUsage and does *not* have keyCertSign set. Its issuer and > > subject names are identical *and* identical to Cert1. > > > > The two certificates have different keys. > > > > That test is needed to correctly verify the chain as Cert1->Cert2. > > Fair enough. > > What about checking the basicConstraints? All CAs must have this > extension according to RFC2459, and by inference cA must be set to true. >
Well yes except there's a broken certificate workaround in there... One rather important CA excludes basicConstraints in its "CA" certificate but includes keyUsage+keyCertSign so it will tolerate this case. > Therefore if the issuer is the same as the subject, then the > basicContraints may be missing or cA set to false, and the keyUsage > keyCertSign can be missing. > > If the issuer != subject, then basicContraints must be present and cA set > to true. > If you just want a specific application to verify these certificates (and not OpenSSL in general) then you could always override that error in the verify callback or supply your own check_issuer routine (it is replacable). Do these certificates include SKID/AKID if so then relaxing the keyUsage check if SKID==AKID would be a possibility. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
