The following test case attempts to validates evilserver.pem, issued by evilca.pem. evil*.pem is violating: 1/ pathlen=0 constraint of the compromised intermediate.pem (issuer of evilserver.pem) 2/ pathlen=1 constraint of the non-compromised root-ca.pem (issuer of intermediate.pem) The particular example execution is from Mac (LibreSSL) but same behaviour observed with e.g. homebrew as well. https://github.com/blaufish/openssl-pathlen openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic" Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:1 openssl x509 -text -in intermediate.pem | grep -a1 "X509v3 Basic" Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic" X509v3 Basic Constraints: critical CA:TRUE openssl verify -verbose -CAfile root.pem -untrusted untrusted.pem evilserver.pem evilserver.pem: OK On Wed, Oct 3, 2018 at 4:51 PM Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: > > On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Magnusson wrote: > > > $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem evil.pem > > evil.pem: OK > > This is expected to work when intermediate.pem has pathlen 0, because > you're verifying "evil.pem" as a *leaf* certificate, its CA:true > is irrelevant when it is the last (leaf) certificate in the chain. > > An actually unexpected result would be: > > $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem -untrusted evil.pem badee.pem > badee.pem: OK > > where badee.pem is signed by evil.pem. The path length constraint > is not a constraint against issuing EE certs with CA:true, it only > constraints the number additional intermediate (non-self-issued) > CAs in a valid path. In your example that number is zero. > > https://tools.ietf.org/html/rfc5280#section-4.2.1.9 > > The pathLenConstraint field is meaningful only if the cA boolean is > asserted and the key usage extension, if present, asserts the > keyCertSign bit (Section 4.2.1.3). In this case, it gives the > maximum number of non-self-issued intermediate certificates that may > follow this certificate in a valid certification path. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users