Path Length Constraint ignored for Root and any self-issued certificate

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Path Length Constraint ignored for Root and any self-issued certificate

Peter Magnusson
One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have been mixed up).

https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2

openssl x509 -text -in root.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"
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
----
openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
--
--
                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
            X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
--
--
                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
            X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
--
--
                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
            X509v3 Authority Key Identifier:

keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
----
../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
root.pem -untrusted evilca.pem evilserver.pem
******* important variables *******
*** check_chain_extensions:524 i=0
*** check_chain_extensions:525 plen=0
*** check_chain_extensions:526 x->ex_pathlen=-1
******* if statement components *******
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=0
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:524 i=1
*** check_chain_extensions:525 plen=1
*** check_chain_extensions:526 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:524 i=2
*** check_chain_extensions:525 plen=2
*** check_chain_extensions:526 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:528 i > 1=1
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=1
evilserver.pem: OK
Chain:
depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
EvilServer, CN = EvilServer (untrusted)
depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
= EvilCA (untrusted)
depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

d3x0r
It was my interpretation that 0 pathlen on the root self signed meant infinite.
The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)

On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <[hidden email]> wrote:
One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have been mixed up).

https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2

openssl x509 -text -in root.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"
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
----
openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
--
--
                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
            X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
--
--
                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
            X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
--
--
                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
            X509v3 Authority Key Identifier:

keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
----
../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
root.pem -untrusted evilca.pem evilserver.pem
******* important variables *******
*** check_chain_extensions:524 i=0
*** check_chain_extensions:525 plen=0
*** check_chain_extensions:526 x->ex_pathlen=-1
******* if statement components *******
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=0
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:524 i=1
*** check_chain_extensions:525 plen=1
*** check_chain_extensions:526 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:524 i=2
*** check_chain_extensions:525 plen=2
*** check_chain_extensions:526 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:528 i > 1=1
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=1
evilserver.pem: OK
Chain:
depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
EvilServer, CN = EvilServer (untrusted)
depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
= EvilCA (untrusted)
depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
--
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 | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

Peter Magnusson
That is not correct behaviour as far as I can understand.

RFC5280 Certification Path Validation algorithm process from root to
leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
Preparation for Certificate i+1 is expected to occur upon Root
certificate, i.e. the following should be expected behaviour:
* max_path_length=n (initialisation)
* max_path_length=n-1 (first decrement)
* max_path_length=0 (copied from root certificate constraint)
* VERIFY(max_path_length>0) error upon preparing transition from i=1
(Root) to i=2 (EvilCA).

OpenSSL does everything in a slightly different reverse algorithm, but
should perform the same controls and behaivor as the RFC imho.

And aside from the RFC algorithm checking for this condition, it is
also analog with the description of the expected behaviour:

   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.  (Note: The
   last certificate in the certification path is not an intermediate
   certificate, and is not included in this limit.  Usually, the last
   certificate is an end entity certificate, but it can be a CA
   certificate.)  A pathLenConstraint of zero indicates that no non-
   self-issued intermediate CA certificates may follow in a valid
   certification path.  Where it appears, the pathLenConstraint field
   MUST be greater than or equal to zero.  Where pathLenConstraint does
   not appear, no limit is imposed.

So my understanding is that the OpenSSL algorithm is confused and
fails to perform a check that is applicable to self-issued
certificates. The decrement of max_path_length (aka plen++ in OpenSSL
implementation) should not occur for self issued certificates, but the
validation of max_path_length>0 (aka plen>(constraint+1)) should
occur.
On Mon, Oct 8, 2018 at 1:27 PM J Decker <[hidden email]> wrote:

>
> It was my interpretation that 0 pathlen on the root self signed meant infinite.
> The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>
> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <[hidden email]> wrote:
>>
>> One more logic confusion in the OpenSSL Path Length Constraint check.
>> Any Path Length Constraint set by Root (or any other Self-Issued
>> Certificate) is ignored.
>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>> applied to the checker (i.e. the checker and the calculation logic
>> have been mixed up).
>>
>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>
>> openssl x509 -text -in root.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"
>>                 Certificate Sign, CRL Sign
>>             X509v3 Basic Constraints: critical
>>                 CA:TRUE, pathlen:0
>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>>         X509v3 extensions:
>>             X509v3 Basic Constraints: critical
>>                 CA:FALSE
>> ----
>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>>         X509v3 extensions:
>>             X509v3 Subject Key Identifier:
>>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> --
>> --
>>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>             X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>>         X509v3 extensions:
>>             X509v3 Subject Key Identifier:
>>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> --
>> --
>>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>             X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>>                 TLS Web Server Authentication
>>             X509v3 Subject Key Identifier:
>>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>> --
>> --
>>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>             X509v3 Authority Key Identifier:
>>
>> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> ----
>> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
>> root.pem -untrusted evilca.pem evilserver.pem
>> ******* important variables *******
>> *** check_chain_extensions:524 i=0
>> *** check_chain_extensions:525 plen=0
>> *** check_chain_extensions:526 x->ex_pathlen=-1
>> ******* if statement components *******
>> *** check_chain_extensions:528 i > 1=0
>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>> proxy_path_length + 1))=0
>> ******* important variables *******
>> *** check_chain_extensions:524 i=1
>> *** check_chain_extensions:525 plen=1
>> *** check_chain_extensions:526 x->ex_pathlen=0
>> ******* if statement components *******
>> *** check_chain_extensions:528 i > 1=0
>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>> proxy_path_length + 1))=0
>> ******* important variables *******
>> *** check_chain_extensions:524 i=2
>> *** check_chain_extensions:525 plen=2
>> *** check_chain_extensions:526 x->ex_pathlen=0
>> ******* if statement components *******
>> *** check_chain_extensions:528 i > 1=1
>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>> proxy_path_length + 1))=1
>> evilserver.pem: OK
>> Chain:
>> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
>> EvilServer, CN = EvilServer (untrusted)
>> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
>> = EvilCA (untrusted)
>> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
>> --
>> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

Peter Magnusson
sorry, typo on the verify line, this was what I should have written:
VERIFY(max_path_length>0) error upon preparing transition from i=2
(EvilCA) to i=2 (EvilServer).
On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
<[hidden email]> wrote:

>
> That is not correct behaviour as far as I can understand.
>
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
>
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
>
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
>
>    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.  (Note: The
>    last certificate in the certification path is not an intermediate
>    certificate, and is not included in this limit.  Usually, the last
>    certificate is an end entity certificate, but it can be a CA
>    certificate.)  A pathLenConstraint of zero indicates that no non-
>    self-issued intermediate CA certificates may follow in a valid
>    certification path.  Where it appears, the pathLenConstraint field
>    MUST be greater than or equal to zero.  Where pathLenConstraint does
>    not appear, no limit is imposed.
>
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker <[hidden email]> wrote:
> >
> > It was my interpretation that 0 pathlen on the root self signed meant infinite.
> > The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
> >
> > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <[hidden email]> wrote:
> >>
> >> One more logic confusion in the OpenSSL Path Length Constraint check.
> >> Any Path Length Constraint set by Root (or any other Self-Issued
> >> Certificate) is ignored.
> >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> >> applied to the checker (i.e. the checker and the calculation logic
> >> have been mixed up).
> >>
> >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> >>
> >> openssl x509 -text -in root.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"
> >>                 Certificate Sign, CRL Sign
> >>             X509v3 Basic Constraints: critical
> >>                 CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> >>         X509v3 extensions:
> >>             X509v3 Basic Constraints: critical
> >>                 CA:FALSE
> >> ----
> >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> >>         X509v3 extensions:
> >>             X509v3 Subject Key Identifier:
> >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> --
> >> --
> >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >>             X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> >>         X509v3 extensions:
> >>             X509v3 Subject Key Identifier:
> >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >> --
> >> --
> >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >>             X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
> >>                 TLS Web Server Authentication
> >>             X509v3 Subject Key Identifier:
> >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> >> --
> >> --
> >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> >>             X509v3 Authority Key Identifier:
> >>
> >> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >> ----
> >> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> >> root.pem -untrusted evilca.pem evilserver.pem
> >> ******* important variables *******
> >> *** check_chain_extensions:524 i=0
> >> *** check_chain_extensions:525 plen=0
> >> *** check_chain_extensions:526 x->ex_pathlen=-1
> >> ******* if statement components *******
> >> *** check_chain_extensions:528 i > 1=0
> >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> >> proxy_path_length + 1))=0
> >> ******* important variables *******
> >> *** check_chain_extensions:524 i=1
> >> *** check_chain_extensions:525 plen=1
> >> *** check_chain_extensions:526 x->ex_pathlen=0
> >> ******* if statement components *******
> >> *** check_chain_extensions:528 i > 1=0
> >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> >> proxy_path_length + 1))=0
> >> ******* important variables *******
> >> *** check_chain_extensions:524 i=2
> >> *** check_chain_extensions:525 plen=2
> >> *** check_chain_extensions:526 x->ex_pathlen=0
> >> ******* if statement components *******
> >> *** check_chain_extensions:528 i > 1=1
> >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> >> proxy_path_length + 1))=1
> >> evilserver.pem: OK
> >> Chain:
> >> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> >> EvilServer, CN = EvilServer (untrusted)
> >> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> >> = EvilCA (untrusted)
> >> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> >> --
> >> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

Peter Magnusson
Tested mbedtls to see how other code bases handle thus.

mbedtls rejects the EvilCA certificate when connecting to openssl
s_server (as opposed to openssl c_client -verify that accepts the
connection).

Verify requested for (Depth 1):
cert. version     : 3
serial number     : 10:00
issuer name       : C=SE, ST=Root, L=Root, O=Root, OU=Root, CN=Root
subject name      : C=SE, ST=EvilCA, L=EvilCA, O=EvilCA, OU=EvilCA, CN=EvilCA
issued  on        : 2018-10-08 08:20:21
expires on        : 2028-10-05 08:20:21
signed using      : RSA with SHA-256
RSA key size      : 4096 bits
basic constraints : CA=true, max_pathlen=0
key usage         : Key Cert Sign, CRL Sign
  ! The certificate is not correctly signed by the trusted CA

The handshake fails after this error, mbedtls_ssl_handshake returned -9984.
On Mon, Oct 8, 2018 at 2:51 PM Peter Magnusson
<[hidden email]> wrote:

>
> sorry, typo on the verify line, this was what I should have written:
> VERIFY(max_path_length>0) error upon preparing transition from i=2
> (EvilCA) to i=2 (EvilServer).
> On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
> <[hidden email]> wrote:
> >
> > That is not correct behaviour as far as I can understand.
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
> >
> > OpenSSL does everything in a slightly different reverse algorithm, but
> > should perform the same controls and behaivor as the RFC imho.
> >
> > And aside from the RFC algorithm checking for this condition, it is
> > also analog with the description of the expected behaviour:
> >
> >    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.  (Note: The
> >    last certificate in the certification path is not an intermediate
> >    certificate, and is not included in this limit.  Usually, the last
> >    certificate is an end entity certificate, but it can be a CA
> >    certificate.)  A pathLenConstraint of zero indicates that no non-
> >    self-issued intermediate CA certificates may follow in a valid
> >    certification path.  Where it appears, the pathLenConstraint field
> >    MUST be greater than or equal to zero.  Where pathLenConstraint does
> >    not appear, no limit is imposed.
> >
> > So my understanding is that the OpenSSL algorithm is confused and
> > fails to perform a check that is applicable to self-issued
> > certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> > implementation) should not occur for self issued certificates, but the
> > validation of max_path_length>0 (aka plen>(constraint+1)) should
> > occur.
> > On Mon, Oct 8, 2018 at 1:27 PM J Decker <[hidden email]> wrote:
> > >
> > > It was my interpretation that 0 pathlen on the root self signed meant infinite.
> > > The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
> > >
> > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <[hidden email]> wrote:
> > >>
> > >> One more logic confusion in the OpenSSL Path Length Constraint check.
> > >> Any Path Length Constraint set by Root (or any other Self-Issued
> > >> Certificate) is ignored.
> > >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> > >> applied to the checker (i.e. the checker and the calculation logic
> > >> have been mixed up).
> > >>
> > >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> > >>
> > >> openssl x509 -text -in root.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"
> > >>                 Certificate Sign, CRL Sign
> > >>             X509v3 Basic Constraints: critical
> > >>                 CA:TRUE, pathlen:0
> > >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> > >>         X509v3 extensions:
> > >>             X509v3 Basic Constraints: critical
> > >>                 CA:FALSE
> > >> ----
> > >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> > >>         X509v3 extensions:
> > >>             X509v3 Subject Key Identifier:
> > >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> --
> > >> --
> > >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >>             X509v3 Authority Key Identifier:
> > >>
> > >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> > >>         X509v3 extensions:
> > >>             X509v3 Subject Key Identifier:
> > >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> > >> --
> > >> --
> > >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> > >>             X509v3 Authority Key Identifier:
> > >>
> > >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
> > >>                 TLS Web Server Authentication
> > >>             X509v3 Subject Key Identifier:
> > >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> > >> --
> > >> --
> > >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> > >>             X509v3 Authority Key Identifier:
> > >>
> > >> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> > >> ----
> > >> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> > >> root.pem -untrusted evilca.pem evilserver.pem
> > >> ******* important variables *******
> > >> *** check_chain_extensions:524 i=0
> > >> *** check_chain_extensions:525 plen=0
> > >> *** check_chain_extensions:526 x->ex_pathlen=-1
> > >> ******* if statement components *******
> > >> *** check_chain_extensions:528 i > 1=0
> > >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> > >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> > >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> > >> proxy_path_length + 1))=0
> > >> ******* important variables *******
> > >> *** check_chain_extensions:524 i=1
> > >> *** check_chain_extensions:525 plen=1
> > >> *** check_chain_extensions:526 x->ex_pathlen=0
> > >> ******* if statement components *******
> > >> *** check_chain_extensions:528 i > 1=0
> > >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> > >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> > >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> > >> proxy_path_length + 1))=0
> > >> ******* important variables *******
> > >> *** check_chain_extensions:524 i=2
> > >> *** check_chain_extensions:525 plen=2
> > >> *** check_chain_extensions:526 x->ex_pathlen=0
> > >> ******* if statement components *******
> > >> *** check_chain_extensions:528 i > 1=1
> > >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> > >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> > >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> > >> proxy_path_length + 1))=1
> > >> evilserver.pem: OK
> > >> Chain:
> > >> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> > >> EvilServer, CN = EvilServer (untrusted)
> > >> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> > >> = EvilCA (untrusted)
> > >> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> > >> --
> > >> 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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

Viktor Dukhovni
In reply to this post by Peter Magnusson
> On Oct 8, 2018, at 8:47 AM, Peter Magnusson <[hidden email]> wrote:
>
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).

Well, strictly speaking, the trust-anchor is not part of the certificate
chain in RFC5280, it is a public key and an issuer name, not a certificate
in the chain.  However, when the trust-anchor is in the form of a self-signed
CA certificate, one might take the view that this is a self-issued certificate
to be included in the chain:

 trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

in which case the "path lenth: 0" in the self-issed root CA cert precludes
the root from issuing any subsidiary CAs that can in turn issue further
EE certs.  That is perhaps reasonable, so I updated PR #7353 with
a further commit:

  https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3

Does that address your concerns?

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

OpenSSL - User mailing list
In reply to this post by Peter Magnusson
Bonjour,

The prospective certification path excludes the Trust Anchor.
Therefore, the « max_path_length=0 » step is attained only when dealing with your EvilCA cert.

Cordialement,
Erwann Abalea

> Le 8 oct. 2018 à 14:47, Peter Magnusson <[hidden email]> a écrit :
>
> That is not correct behaviour as far as I can understand.
>
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
>
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
>
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
>
>   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.  (Note: The
>   last certificate in the certification path is not an intermediate
>   certificate, and is not included in this limit.  Usually, the last
>   certificate is an end entity certificate, but it can be a CA
>   certificate.)  A pathLenConstraint of zero indicates that no non-
>   self-issued intermediate CA certificates may follow in a valid
>   certification path.  Where it appears, the pathLenConstraint field
>   MUST be greater than or equal to zero.  Where pathLenConstraint does
>   not appear, no limit is imposed.
>
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker <[hidden email]> wrote:
>>
>> It was my interpretation that 0 pathlen on the root self signed meant infinite.
>> The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>>
>> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <[hidden email]> wrote:
>>>
>>> One more logic confusion in the OpenSSL Path Length Constraint check.
>>> Any Path Length Constraint set by Root (or any other Self-Issued
>>> Certificate) is ignored.
>>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>>> applied to the checker (i.e. the checker and the calculation logic
>>> have been mixed up).
>>>
>>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>>
>>> openssl x509 -text -in root.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"
>>>                Certificate Sign, CRL Sign
>>>            X509v3 Basic Constraints: critical
>>>                CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>>>        X509v3 extensions:
>>>            X509v3 Basic Constraints: critical
>>>                CA:FALSE
>>> ----
>>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>        X509v3 extensions:
>>>            X509v3 Subject Key Identifier:
>>>                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> --
>>> --
>>>                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>>            X509v3 Authority Key Identifier:
>>>
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>>>        X509v3 extensions:
>>>            X509v3 Subject Key Identifier:
>>>                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>> --
>>> --
>>>                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>>            X509v3 Authority Key Identifier:
>>>
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>                TLS Web Server Authentication
>>>            X509v3 Subject Key Identifier:
>>>                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>> --
>>> --
>>>                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>>            X509v3 Authority Key Identifier:
>>>
>>> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>> ----
>>> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
>>> root.pem -untrusted evilca.pem evilserver.pem
>>> ******* important variables *******
>>> *** check_chain_extensions:524 i=0
>>> *** check_chain_extensions:525 plen=0
>>> *** check_chain_extensions:526 x->ex_pathlen=-1
>>> ******* if statement components *******
>>> *** check_chain_extensions:528 i > 1=0
>>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
>>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>>> proxy_path_length + 1))=0
>>> ******* important variables *******
>>> *** check_chain_extensions:524 i=1
>>> *** check_chain_extensions:525 plen=1
>>> *** check_chain_extensions:526 x->ex_pathlen=0
>>> ******* if statement components *******
>>> *** check_chain_extensions:528 i > 1=0
>>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>>> proxy_path_length + 1))=0
>>> ******* important variables *******
>>> *** check_chain_extensions:524 i=2
>>> *** check_chain_extensions:525 plen=2
>>> *** check_chain_extensions:526 x->ex_pathlen=0
>>> ******* if statement components *******
>>> *** check_chain_extensions:528 i > 1=1
>>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
>>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>>> proxy_path_length + 1))=1
>>> evilserver.pem: OK
>>> Chain:
>>> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
>>> EvilServer, CN = EvilServer (untrusted)
>>> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
>>> = EvilCA (untrusted)
>>> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
>>> --
>>> 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
> --
> 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 | Threaded
Open this post in threaded view
|

Re: Path Length Constraint ignored for Root and any self-issued certificate

Peter Magnusson
In reply to this post by Viktor Dukhovni
> trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

Yes that seems to be aligned with how the intended the path validation
algorithm should be applied, i.e. first certificate processed is the
cert of the trust anchor.  But it could be clearer, and wording
"recommended" (lowercase) does seem to imply implementers SHOULD
process trust anchor cert rather than MUST process it.

"  In Section 6.1, the text describes basic path validation.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA's name, and any
   constraints upon the set of paths that may be validated using this
   key."

...

" Where a CA distributes self-signed certificates to specify trust
   anchor information, certificate extensions can be used to specify
   recommended inputs to path validation.  For example, a policy
   constraints extension could be included in the self-signed
   certificate to indicate that paths beginning with this trust anchor
   should be trusted only for the specified policies."


> https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
> Does that address your concerns?

I think so! I'll integrate it into my tests and try to do Q/A on the
change, see if I can figure out any other edge case.

Best Regards
//P
On Mon, Oct 8, 2018 at 6:15 PM Viktor Dukhovni
<[hidden email]> wrote:

>
> > On Oct 8, 2018, at 8:47 AM, Peter Magnusson <[hidden email]> wrote:
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
>
> Well, strictly speaking, the trust-anchor is not part of the certificate
> chain in RFC5280, it is a public key and an issuer name, not a certificate
> in the chain.  However, when the trust-anchor is in the form of a self-signed
> CA certificate, one might take the view that this is a self-issued certificate
> to be included in the chain:
>
>  trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)
>
> in which case the "path lenth: 0" in the self-issed root CA cert precludes
> the root from issuing any subsidiary CAs that can in turn issue further
> EE certs.  That is perhaps reasonable, so I updated PR #7353 with
> a further commit:
>
>   https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
>
> Does that address your concerns?
>
> --
>         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