> -----Original Message----- > From: Erwann Abalea > > Le 22/05/2012 10:57, Eisenacher, Patrick a écrit : > >> -----Original Message----- > >> From: Erwann Abalea > >> > >> Bonjour, > >> > >> Le 21/05/2012 14:10, Serge Emantayev a écrit : > >>> Hello openSSL gurus, > >>> > >>> I faced an issue of pathlen constraint checking by openSSL > >> when verifying the client certificate. I did few studies for > >> how openSSL does that and I appreciate your assistance on > >> clarifying the issue. > >>> 1. The certificate chain with a pathlen constraint defined > >> in a root CA: > >>> Root CA, pathlen:1 > >>> \ policy CA, pathlen:none > >>> \ issuer CA, pathlen:none > >>> \ client certificate > >>> > >>> In the first case openSSL does not verify the certificate > >> correctly (i.e. the verification succeeds). It ignores the > >> pathlen constraint defined in the root CA. > >> > >> This is conformant with X.509. The basicConstraints > extension is not > >> taken in consideration if present in a trust anchor (a root > >> certificate > >> is a trust anchor). > >> Download X.509 recommendation, see chapter 10 (from memory), the > >> validation algorithm is described. > > Actually, I find this hard to believe. The verifying party > can deem any certificate as trusted and thereby making it its > trust anchor. Nevertheless the verification process needs to > take into account the extensions of the trust anchor and I > don't see any reason to exclude basicConstraints. Can you > please cite the relevant part of the validation algorithm > that you reference? > > Taken from X.509, 2008/11 edition. But IIRC, the algorithm is > the same > since the 2000 edition, at least. > > ----- > 10.5 Certificate processing > > Each certificate is then processed in turn, starting with the > certificate signed using the input trusted public key. The last > certificate is considered to be the end certificate; any other > certificates are considered to be intermediate certificates. > ----- > > Note that the first certificate taken into consideration is signed by > the trust anchor, and not the trust anchor itself. > > ----- > 10.5.1 Basic certificate checks > > The following checks are applied to a certificate. Self-signed > certificates, if encountered in the path, are ignored. > > a) Check that the signature verifies, that dates are valid, that the > certificate subject and certificate issuer > names chain correctly, and that the certificate has not been revoked. > > b) For an intermediate version 3 certificate, check that > basicConstraints is present and that the cA > component in the basicConstraints extension is TRUE. If the > pathLenConstraint component is present, > check that the current certification path does not violate that > constraint (ignoring intermediate self-issued > certificates) > > [...other basic steps...] > ----- > > The same logic applies for other constraints extensions. > Basically, from > the trust anchor, you only take the public key, name, and validity > dates. No extension at all. That's because a trust anchor > doesn't need > to be a certificate at all.
Hi Erwann, I guess it's time to re-read in-depth the lengthy chapter on certification path validation of RFC 5280 and pay special attention to trust anchors in form of self signed and non-self signed certificates :o) Thanks for clarification, Patrick Eisenacher ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
