cert chain file ordering question

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

cert chain file ordering question

Norm Green
This question is regarding OpenSSL 1.1.

Let's say I have this trust hierarchy:

RootCA
CA1
CA2
CA3
userCert


So userCert is signed by CA3, CA3 is signed by CA2, and so on up to
RootCA, which is a self-signed root cert.

If I combine CA1,CA2,CA3 and userCert into single PEM file, chain.pem,
the openssl verify command only verifies the chain is correct if the
order of the file is such that the user cert occurs *last* in the chain
as follows:

CA1
CA2
CA3
userCert

openssl verify -CAfile RootCA.pem chain.pem


What strikes me as odd is the order shown above is the *opposite* of
what is needed for the SSL_CTX_user_certificate_chain_file() function,
which requires the highest level CA to appear at the end of the file.
 From the man page:

SSL_CTX_use_certificate_chain_file() loads a certificate chain from file
into ctx. The certificates must be in PEM format and must be sorted
starting with the subject's certificate (actual client or server
certificate), followed by intermediate CA certificates if applicable,
and ending at the highest level (root) CA.
SSL_use_certificate_chain_file() is similar except it loads the
certificate chain into ssl.

Is my understanding of things correct?  Seems like there should be a way
for the openssl command to verify a chain file which will be used with the
SSL_CTX_use_certificate_chain_file() function.

Norm Green

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

Re: cert chain file ordering question

OpenSSL - User mailing list
On 01/08/2018 06:33 PM, Norm Green wrote:

> This question is regarding OpenSSL 1.1.
>
> Let's say I have this trust hierarchy:
>
> RootCA
> CA1
> CA2
> CA3
> userCert
>
>
> So userCert is signed by CA3, CA3 is signed by CA2, and so on up to
> RootCA, which is a self-signed root cert.
>
> If I combine CA1,CA2,CA3 and userCert into single PEM file, chain.pem,
> the openssl verify command only verifies the chain is correct if the
> order of the file is such that the user cert occurs *last* in the
> chain as follows:
>
> CA1
> CA2
> CA3
> userCert
>
> openssl verify -CAfile RootCA.pem chain.pem
>
>
> What strikes me as odd is the order shown above is the *opposite* of
> what is needed for the SSL_CTX_user_certificate_chain_file() function,
> which requires the highest level CA to appear at the end of the file.
> From the man page:
>
> SSL_CTX_use_certificate_chain_file() loads a certificate chain from
> file into ctx. The certificates must be in PEM format and must be
> sorted starting with the subject's certificate (actual client or
> server certificate), followed by intermediate CA certificates if
> applicable, and ending at the highest level (root) CA.
> SSL_use_certificate_chain_file() is similar except it loads the
> certificate chain into ssl.
>
> Is my understanding of things correct?  Seems like there should be a
> way for the openssl command to verify a chain file which will be used
> with the
> SSL_CTX_use_certificate_chain_file() function.

But the verify command is intended to verify an *individual*
certificate, not a file containing an entire chain -- the specific chain
used is somewhat incidental.

Did you try something like (with a 1.1.0 installation):

openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem

with the leaf certificate as the first one in chain.pem?

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

Re: cert chain file ordering question

Norm Green
On 1/9/2018 6:03 AM, Benjamin Kaduk wrote:
> Did you try something like (with a 1.1.0 installation):
>
> openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem
>
> with the leaf certificate as the first one in chain.pem?

Same result. The only way it seems to work is if the leaf cert appears
at the end of the file.

Norm

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

Re: cert chain file ordering question

d3x0r
The certs are built into a stack... they are pushed... so element 0 is the last thing in the list.
The chain starts with 0, and then can search the rest.


On Tue, Jan 9, 2018 at 2:55 PM, Norm Green <[hidden email]> wrote:
On 1/9/2018 6:03 AM, Benjamin Kaduk wrote:
Did you try something like (with a 1.1.0 installation):

openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem

with the leaf certificate as the first one in chain.pem?

Same result. The only way it seems to work is if the leaf cert appears at the end of the file.

Norm


--
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: cert chain file ordering question

Viktor Dukhovni
In reply to this post by Norm Green


> On Jan 9, 2018, at 5:55 PM, Norm Green <[hidden email]> wrote:
>
> Same result. The only way it seems to work is if the leaf cert appears at the end of the file.

You're badly mistaken.  *ONLY* the first certificate in the file is verified.
When you put the leaf cert at the end, you're *ONLY* verifying the top-most
issuer CA certificate.

The correct way to verify a chain is to put the root CA in a CAfile,
intermediate CAs in an "untrusted" chain file, and the leaf cert all
by itself in a separate file.  As explained upstream.  If that's not
working, then perhaps your chain is actually incomplete or otherwise
does not satisfy all the requirements.

--
        Viktor.

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

Re: cert chain file ordering question

Viktor Dukhovni
In reply to this post by d3x0r


> On Jan 9, 2018, at 6:04 PM, J Decker <[hidden email]> wrote:
>
> The certs are built into a stack... they are pushed... so element 0 is the last thing in the list.
> The chain starts with 0, and then can search the rest.

This is either false or irrelevant depending on what you intended
(too terse to know which).

--
        Viktor.

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

Re: cert chain file ordering question

Norm Green
In reply to this post by Viktor Dukhovni
Well that is not *at all* obvious from the documentation, but ok.

What is the correct order of intermediate CA certs in the untrusted
chain file?



On 1/9/2018 3:36 PM, Viktor Dukhovni wrote:
> The correct way to verify a chain is to put the root CA in a CAfile,
> intermediate CAs in an "untrusted" chain file, and the leaf cert all
> by itself in a separate file.

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

Re: cert chain file ordering question

Viktor Dukhovni


> On Jan 9, 2018, at 6:43 PM, Norm Green <[hidden email]> wrote:
>
> What is the correct order of intermediate CA certs in the untrusted chain file?

The untrusted CA list is a heap, the order is irrelevant.

--
        Viktor.

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

Re: cert chain file ordering question

Norm Green
It still doesn't verify correctly.

To simplify, I tried it with 1 intermediate CA. Here's the chain:

rootCa.pem - self-signed root cert. CN = rootCA
firstIntermedCa.pem - intermediate CA cert signed by rootCa.pem. CN = EmeaCA
secondIntermedCa.pem - intermediate CA cert signed by
firstIntermedCa.pem.  CN = KapitalCA


openssl verify -verbose -show_chain -CAfile rootCa.pem -untrusted
firstIntermedCa.pem secondIntermedCa.pem
1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA
error 20 at 0 depth lookup: unable to get local issuer certificate
error secondIntermedCa.pem: verification failed







On 1/9/2018 3:57 PM, Viktor Dukhovni wrote:
>
>> On Jan 9, 2018, at 6:43 PM, Norm Green <[hidden email]> wrote:
>>
>> What is the correct order of intermediate CA certs in the untrusted chain file?
> The untrusted CA list is a heap, the order is irrelevant.
>

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

Re: cert chain file ordering question

Viktor Dukhovni


> On Jan 9, 2018, at 7:28 PM, Norm Green <[hidden email]> wrote:
>
> It still doesn't verify correctly.

Or correctly fails to verify?

> To simplify, I tried it with 1 intermediate CA. Here's the chain:
>
> rootCa.pem - self-signed root cert. CN = rootCA
> firstIntermedCa.pem - intermediate CA cert signed by rootCa.pem. CN = EmeaCA
> secondIntermedCa.pem - intermediate CA cert signed by firstIntermedCa.pem.  CN = KapitalCA

Without the certificates (no private keys, just the certs) in question it quite
difficult to offer much help.

> openssl verify -verbose -show_chain -CAfile rootCa.pem -untrusted firstIntermedCa.pem secondIntermedCa.pem
> 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA
> error 20 at 0 depth lookup: unable to get local issuer certificate
> error secondIntermedCa.pem: verification failed

In addition to posting the certificates in question, please post (again even if
posted previously) what version of OpenSSL you're using, the output of:

        $ openssl version -a

will suffice.

--
        Viktor.

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

Re: cert chain file ordering question

Norm Green
 >Or correctly fails to verify?
Perhaps.  Hopefully you'll be able to tellme.

Here's the version info and a dump of the certs.
Thanks for your help.

Norm


openssl version -a
OpenSSL 1.1.0g  2 Nov 2017
built on: reproducible build, date unspecified
platform: linux-x86_64
compiler: /usr/bin/gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
-DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
-DPOLY1305_ASM
-DOPENSSLDIR="\"/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/ssl\""
-DENGINESDIR="\"/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/lib/engines-1.1\""
OPENSSLDIR:
"/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/ssl"
ENGINESDIR:
"/export/moop3/users/normg/gs64-3xm3/slow50/openssl_1.1/install50/lib/engines-1.1"



opensslx509 -in secondIntermedCa.pem -noout -text
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 4097 (0x1001)
     Signature Algorithm: sha256WithRSAEncryption
         Issuer: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA
         Validity
             Not Before: Jan  8 23:23:59 2018 GMT
             Not After : Jan  8 23:23:59 2019 GMT
         Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
                 Public-Key: (2048 bit)
                 Modulus:
00:d1:26:00:3b:36:08:50:1b:30:96:c4:d9:c9:48:
1d:26:e4:f7:5a:ea:27:7a:ce:e6:3f:83:c6:e8:3e:
f9:88:e0:e9:e3:a5:81:05:ff:e5:3f:63:d9:db:5e:
da:33:62:aa:a6:26:a3:b0:d5:f9:5e:1a:24:af:1e:
a8:e9:bb:58:25:84:bb:90:86:4a:58:aa:a8:95:87:
e5:b1:f3:0f:9a:e4:24:a4:60:2b:bb:02:f5:38:34:
6b:75:58:e6:a1:d4:04:3e:1c:cb:70:14:61:cf:6a:
09:52:a9:d0:e3:90:63:f5:77:3c:d0:6a:04:13:56:
f1:79:fe:49:05:de:ff:19:cb:1a:61:77:b5:34:0b:
7e:b7:e9:35:b0:bd:b1:57:20:50:9a:b5:2f:ac:35:
e5:c4:81:ac:61:4d:81:e3:05:1c:a4:04:f9:80:c0:
44:e6:01:76:9d:8e:7d:a5:0a:ff:92:5f:44:06:52:
be:49:b5:44:c4:6a:43:91:d3:d3:f9:14:ad:f5:78:
62:fa:3b:53:e2:84:0c:cc:7d:6e:46:46:f1:7b:b5:
bb:df:12:7d:0d:23:0c:8d:a8:33:8a:c5:b6:b0:e5:
bc:fd:38:b4:e1:96:ca:96:ce:bb:99:c2:d0:6b:35:
e3:17:7c:5f:20:2c:52:51:4d:61:9f:63:e3:fc:f9:
                     c8:ab
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Subject Key Identifier:
C7:26:0D:BB:DF:7E:90:CA:7F:A0:C8:B7:CC:09:44:27:C0:53:A7:97
             X509v3 Authority Key Identifier:
keyid:0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34

             X509v3 Basic Constraints: critical
                 CA:TRUE
             X509v3 Key Usage:
                 Digital Signature, Key Encipherment
     Signature Algorithm: sha256WithRSAEncryption
84:5d:c1:1d:f1:b0:03:f1:b2:32:17:0e:be:45:6b:41:f8:97:
17:6a:d0:3e:37:5b:c6:d7:a7:23:83:37:d0:e6:6c:f0:9e:63:
ca:8a:89:c4:96:ee:c9:58:d8:97:f6:35:71:57:f9:fc:a5:d2:
98:ba:f4:77:5c:83:62:7a:2a:06:73:13:25:5d:ae:c7:05:0d:
67:51:b3:4d:06:cb:41:3a:26:ac:59:34:6c:e8:9f:f2:f8:a9:
55:b0:b6:c4:5e:1c:f7:5c:25:16:89:c4:2a:e0:7d:9d:6f:db:
47:20:48:3c:42:4b:f0:cd:a6:b1:fc:98:b2:b0:83:8a:4d:47:
01:33:b2:67:5f:90:94:50:39:31:ef:16:22:52:5d:fe:c1:13:
c8:67:43:70:ff:3f:8c:d5:ef:5f:a7:eb:3a:f7:8e:b3:f2:28:
37:41:3b:aa:c7:af:e7:7b:96:17:6c:5e:47:ff:2c:2d:b5:63:
55:12:77:ce:61:83:52:a9:5a:83:3b:d8:e9:0a:e6:6a:4d:eb:
79:2c:54:33:36:2e:f6:67:4b:a2:1b:86:71:f5:56:50:d7:34:
85:45:6c:4d:11:0a:2e:b9:98:e9:3a:07:d6:ea:7b:89:d3:ae:
d0:71:5b:b1:5b:fa:e9:f8:e5:18:f3:1e:3e:05:d6:27:9a:bf:
          89:7c:ac:b4



opensslx509 -in firstIntermedCa.pem -noout -text
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 4096 (0x1000)
     Signature Algorithm: sha256WithRSAEncryption
         Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA
         Validity
             Not Before: Jan  8 23:23:08 2018 GMT
             Not After : Jan  8 23:23:08 2019 GMT
         Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
                 Public-Key: (2048 bit)
                 Modulus:
00:cd:46:bf:77:3c:b5:89:fc:58:96:b3:6c:df:93:
30:28:79:e7:d2:61:ca:37:78:e3:eb:3b:da:13:d7:
a3:b7:dd:89:1c:35:b2:5e:77:eb:df:4b:c5:c3:fe:
38:23:8b:bc:ff:f2:1a:f4:b3:0a:92:ee:2a:27:0e:
c0:a9:bc:3f:05:dd:88:b7:ca:c8:b6:6a:fe:b0:b3:
6f:da:fa:ef:aa:61:f3:31:d3:55:70:ca:3f:aa:d0:
1f:7a:3d:57:04:a9:e1:16:a8:79:04:4a:3e:6e:1a:
e5:0f:7a:a9:3e:02:d5:44:a1:18:74:1d:96:ba:98:
5f:fc:97:1d:62:36:3a:4b:3b:64:85:1a:8d:10:80:
3f:15:00:9b:18:ed:a6:0f:f1:a9:6e:f9:ab:42:bd:
72:75:13:bb:48:56:80:d3:5d:06:f6:32:59:9f:b4:
62:32:4d:fb:7e:12:6a:3f:a5:0d:05:74:a9:3e:11:
6f:9b:a3:61:7f:8b:ac:7d:52:1c:99:f5:be:bd:48:
6e:6c:ae:70:b5:44:27:1f:40:4a:b3:9c:e5:78:02:
c7:b0:a3:c6:18:86:51:a8:8a:1a:86:fc:73:6c:7f:
d9:a7:95:55:ed:b3:6c:65:d0:0a:b6:15:69:e3:24:
ea:b9:c9:33:f1:48:46:6c:5a:10:d0:37:41:53:bd:
                     00:f9
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Subject Key Identifier:
0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34
             X509v3 Authority Key Identifier:
keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2

             X509v3 Basic Constraints: critical
                 CA:TRUE
             X509v3 Key Usage:
                 Digital Signature, Key Encipherment
     Signature Algorithm: sha256WithRSAEncryption
1c:31:e5:b4:9a:de:81:5f:0d:6d:70:50:4d:cc:09:db:07:e0:
7e:fa:ca:65:a8:5e:32:6f:90:28:c1:34:1b:e1:89:8f:0d:ed:
c5:80:d6:12:20:c7:7f:dc:ec:87:51:5a:95:cd:16:d1:06:bc:
b5:6c:da:18:a8:88:1a:27:6f:91:8d:c4:0f:7a:a9:39:a1:68:
15:09:16:b3:09:ba:e3:b4:d2:48:32:b8:b9:6f:43:01:d2:d7:
a2:63:ae:3f:21:90:15:e6:7e:b0:e4:c9:69:7a:aa:6a:93:72:
ec:22:b8:e6:ce:a0:f2:93:4b:f4:e1:5d:2f:ce:01:78:c1:8f:
43:87:fb:99:37:60:b3:6f:75:0d:10:99:5c:44:90:7d:28:22:
f6:e5:df:c2:d6:44:7a:8d:7d:6f:74:a2:55:0c:5a:97:8f:97:
dc:c4:e5:aa:e5:08:f5:74:ea:6c:7c:43:ba:b7:91:e4:e6:bb:
ef:82:53:25:13:4d:7d:dc:1b:f0:b2:05:c2:a3:46:b5:ff:b9:
e7:83:64:83:67:75:f9:c4:32:66:a2:a6:bb:f2:01:b5:c2:71:
10:b1:f9:9b:c6:20:c1:de:00:b8:80:a4:9d:97:91:d2:ac:ec:
80:4d:b2:11:f9:b5:25:7b:03:3c:e5:37:c9:50:6f:d6:29:12:
          f7:27:46:5d




opensslx509 -in rootCa.pem -noout -text
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             90:ef:af:e5:b9:0d:0c:a7
     Signature Algorithm: sha256WithRSAEncryption
         Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA
         Validity
             Not Before: Jan  8 23:21:46 2018 GMT
             Not After : Jan  8 23:21:46 2019 GMT
         Subject: 1.3.6.1.4.1.47749.1.1 = rootCA
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
                 Public-Key: (2048 bit)
                 Modulus:
00:c0:34:94:b1:a0:d7:e1:04:a0:2f:bf:0c:43:b4:
26:3a:98:aa:29:37:56:09:d0:1a:e1:b0:51:c9:47:
33:d9:1d:3e:62:f9:53:0e:85:17:27:33:bb:5c:f3:
8d:24:29:9f:e4:df:fd:93:bb:e1:2d:d0:6c:23:4e:
60:72:d1:cb:3d:32:64:4d:09:4b:cc:fb:57:6b:74:
1a:19:80:44:af:a3:35:93:c3:ea:f9:fc:66:5a:21:
ea:18:c0:75:82:87:51:36:47:b5:69:73:34:01:49:
f9:b2:f4:ad:3f:ee:eb:25:50:0d:b4:43:57:18:95:
75:5b:09:8c:95:4d:60:28:12:af:4f:56:bc:bb:11:
7b:cf:82:6b:16:ca:95:8f:25:34:10:3c:e1:4b:92:
07:83:da:3f:d4:e4:21:8e:dc:86:1d:ae:1e:4c:6b:
88:bd:7e:7f:eb:57:49:17:0c:f6:70:1a:78:48:4a:
15:0a:6b:a6:df:20:d3:35:ac:6a:20:23:9f:3c:d6:
88:22:7a:a0:a4:d7:e5:25:f0:f8:60:54:6e:d3:3f:
9c:47:d4:3b:f7:21:25:c3:4b:bd:7b:9c:76:58:ea:
73:be:5e:48:ca:fb:e1:02:82:98:ce:15:a0:3d:87:
54:df:2b:f7:6c:41:ce:fc:4e:fc:b2:49:14:65:e7:
                     e8:d3
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Subject Key Identifier:
5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2
             X509v3 Authority Key Identifier:
keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2

             X509v3 Basic Constraints: critical
                 CA:TRUE
             X509v3 Key Usage:
                 Certificate Sign, CRL Sign
     Signature Algorithm: sha256WithRSAEncryption
20:52:6d:e7:01:cc:17:5d:10:7e:c0:48:ca:60:78:a5:c7:80:
d9:ee:6f:90:41:b6:12:dc:2f:37:14:be:0d:97:5b:e6:4a:86:
f9:e8:4d:89:15:de:93:c2:b5:ab:30:c8:9d:1d:93:86:8a:b4:
3a:bf:e3:75:53:42:b9:fb:77:21:2f:05:38:ed:9f:12:3e:b7:
32:02:ae:cb:18:78:e8:df:c3:cb:78:6c:21:f1:f0:ab:99:4f:
b4:02:d2:9d:e4:1d:31:05:1d:b6:37:5f:99:ba:59:87:da:78:
55:7d:fb:06:c2:f8:a1:d6:59:dc:54:3f:63:ee:8b:43:c3:c5:
f8:36:dc:c0:ab:78:20:cc:ba:8f:06:cb:0b:e0:3d:15:d5:1c:
a9:90:1f:d6:57:6c:ab:4e:b6:52:ce:61:d9:6f:32:56:ba:a5:
e8:4b:49:c8:85:2d:ae:f1:cd:ee:7b:9d:39:df:25:2d:ac:64:
04:36:11:99:f3:29:26:a1:f8:ba:e2:02:c0:41:79:38:09:1d:
c2:e7:41:ec:d2:73:5c:a3:53:28:f5:b5:af:fe:66:84:54:58:
43:b5:21:de:42:ba:9f:67:0a:cd:14:d9:ad:02:b3:35:b0:dd:
73:70:24:ca:bc:34:93:e7:c1:20:ee:da:11:6b:a0:95:55:2a:
          61:33:da:55




On 1/9/2018 4:55 PM, Viktor Dukhovni wrote:

>
>> On Jan 9, 2018, at 7:28 PM, Norm Green <[hidden email]> wrote:
>>
>> It still doesn't verify correctly.
> Or correctly fails to verify?
>
>> To simplify, I tried it with 1 intermediate CA. Here's the chain:
>>
>> rootCa.pem - self-signed root cert. CN = rootCA
>> firstIntermedCa.pem - intermediate CA cert signed by rootCa.pem. CN = EmeaCA
>> secondIntermedCa.pem - intermediate CA cert signed by firstIntermedCa.pem.  CN = KapitalCA
> Without the certificates (no private keys, just the certs) in question it quite
> difficult to offer much help.
>
>> openssl verify -verbose -show_chain -CAfile rootCa.pem -untrusted firstIntermedCa.pem secondIntermedCa.pem
>> 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA
>> error 20 at 0 depth lookup: unable to get local issuer certificate
>> error secondIntermedCa.pem: verification failed
> In addition to posting the certificates in question, please post (again even if
> posted previously) what version of OpenSSL you're using, the output of:
>
> $ openssl version -a
>
> will suffice.
>

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

Re: cert chain file ordering question

Viktor Dukhovni


> On Jan 9, 2018, at 8:29 PM, Norm Green <[hidden email]> wrote:
>
> >Or correctly fails to verify?
> Perhaps.  Hopefully you'll be able to tellme.

When you post machine-readable certificates, not just "-text" output.

--
        Viktor.

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

Re: cert chain file ordering question

Viktor Dukhovni
In reply to this post by Norm Green


> On Jan 9, 2018, at 8:29 PM, Norm Green <[hidden email]> wrote:
>
> opensslx509 -in secondIntermedCa.pem -noout -text
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA
>         Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = KapitalCA
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
> C7:26:0D:BB:DF:7E:90:CA:7F:A0:C8:B7:CC:09:44:27:C0:53:A7:97
>             X509v3 Authority Key Identifier:
> keyid:0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34
>             X509v3 Basic Constraints: critical
>                 CA:TRUE
>             X509v3 Key Usage:
>                 Digital Signature, Key Encipherment

The Key Usage is not what'd I'd expect for a CA.

> opensslx509 -in firstIntermedCa.pem -noout -text
>         Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA
>         Subject: 1.3.6.1.4.1.47749.1.1 = userCA, CN = EmeaCA
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
> 0F:D8:48:FB:6C:8D:C3:1A:E1:5C:94:32:45:E8:EA:DE:5B:C5:E5:34
>             X509v3 Authority Key Identifier:
> keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2
>             X509v3 Basic Constraints: critical
>                 CA:TRUE
>             X509v3 Key Usage:
>                 Digital Signature, Key Encipherment

Same here.

> opensslx509 -in rootCa.pem -noout -text
>         Issuer: 1.3.6.1.4.1.47749.1.1 = rootCA
>         Subject: 1.3.6.1.4.1.47749.1.1 = rootCA
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
> 5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2
>             X509v3 Authority Key Identifier:
> keyid:5D:A3:87:58:67:E9:3D:B2:4F:8A:87:DA:CA:26:39:FF:FE:70:D5:F2
>
>             X509v3 Basic Constraints: critical
>                 CA:TRUE
>             X509v3 Key Usage:
>                 Certificate Sign, CRL Sign

This Key Usage is more appropriate.  When the "Key Usage" is present in
a CA certificate, it *MUST* include "Certificate Sign".

--
        Viktor.

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

Re: cert chain file ordering question

Norm Green

On 1/9/18 19:32, Viktor Dukhovni wrote:
This Key Usage is more appropriate.  When the "Key Usage" is present in
a CA certificate, it *MUST* include "Certificate Sign".
That was indeed the problem.  Thank you!! It seems strange to me that OpenSSL will allow creation of a CA cert (CA:TRUE) that may not be used to sign other certs.

I appreciate your help Viktor.

Norm

P.S. Seems you didn't need machine-readable certificates to help me after all ;-)
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users