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-us...@dukhovni.org> 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

Reply via email to