Re: [openssl-users] 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

Re: [openssl-users] cert chain file ordering question

[Viktor Dukhovni]

> On Jan 9, 2018, at 8:29 PM, Norm Green  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

Re: [openssl-users] cert chain file ordering question

[Viktor Dukhovni]

> On Jan 9, 2018, at 8:29 PM, Norm Green  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

Re: [openssl-users] 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:
  

Re: [openssl-users] cert chain file ordering question

[Viktor Dukhovni]

> On Jan 9, 2018, at 7:28 PM, Norm Green  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

Re: [openssl-users] 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  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

Re: [openssl-users] cert chain file ordering question

[Viktor Dukhovni]

> On Jan 9, 2018, at 6:43 PM, Norm Green  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

Re: [openssl-users] cert chain file ordering question

[Norm Green]

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

Re: [openssl-users] cert chain file ordering question

[Viktor Dukhovni]

> On Jan 9, 2018, at 6:04 PM, J Decker  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

Re: [openssl-users] cert chain file ordering question

[Viktor Dukhovni]

> On Jan 9, 2018, at 5:55 PM, Norm Green  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

Re: [openssl-users] cert chain file ordering question

[J Decker]

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 
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

Re: [openssl-users] 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

Re: [openssl-users] cert chain file ordering question

[Benjamin Kaduk via openssl-users]

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

[openssl-users] 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