[openssl-users] Binding the socket to a source IP address before connect

[Sanjaya Joshi]

Hello,
Is there a BIO family of API that OpenSSL provides to bind to a specific
source IP address before creating a socket connection (using for e.g.
BIO_new_connect()) ?
My application does not need to rely on the kernel-provided source IP
address and hence the need for this.

Regards,
Sanjaya
-- 
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] Failed to access LDAP server when a valid certificate is at .1+

[Misaki Miyashita]

Thank you so much for the review, Viktor.

On 1/8/2018 5:57 PM, Viktor Dukhovni wrote:

On Jan 8, 2018, at 5:46 PM, Misaki Miyashita  
wrote:

I would like to suggest the following fix so that a valid certificate at .x can 
be recognized during the cert validation even when .0 is linking to a 
bad/expired certificate.  This may not be the most elegant solution, but it is a minimal 
change with low impact to the rest of the code.

The patch looks wrong to me.  It seems to have a memory leak.
It is also not clear that with CApath all the certificates will
already be loaded, so the iterator may not find the desired
matching element.


I will look into the code to see if there is a memory leak issue.
However, we have tested internally and all certificates (valid and 
invalid) were loaded, and the suggested fix is able to identify the 
matching valid certificate.





Could I possibly get a review on the change? and possibly be considered to be 
integrated to the upstream?
(This is for the 1.0.1 branch)

The 1.0.1 branch is no longer supported.


Sorry, that was a typo :-(  I meant the 1.0.2 branch.

-- misaki
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL_dane_tlsa_add function signature

[Viktor Dukhovni]

> On Jan 9, 2018, at 1:56 PM, Patrick Schlangen  wrote:
> 
> Thanks a lot for the fast reply. I've submitted a pull request at
> https://github.com/openssl/openssl/pull/5046 and will mail the CLA ASAP.

Great!  Appreciated.  Are you at all at liberty to say how (really to what
end) you plan to use the DANE support in OpenSSL?  Feel free to reply off-list
if that makes a difference.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL_dane_tlsa_add function signature

[Patrick Schlangen]

> On Jan 9, 2018, at 19:25 PM, Viktor Dukhovni wrote:
> If you're enthusiastic to contribute, please feel free to file a githu
pull-request 

Thanks a lot for the fast reply. I've submitted a pull request at
https://github.com/openssl/openssl/pull/5046 and will mail the CLA ASAP.

Best Regards,

Patrick




-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL_dane_tlsa_add function signature

[Viktor Dukhovni]

> On Jan 9, 2018, at 12:56 PM, Patrick Schlangen  wrote:
> 
> Reading the docs, my impression ist hat SSL_dane_tlsa_add adds a TLSA record
> to the SSL object for later use during verification.
> What puzzles me is that the data argument of type unsigned char is not
> const.

It should have been "const".  Sorry about that.  If you're enthusiastic to
contribute, please feel free to file a githu pull-request against
ssl/ssl_lib.c and include/openssl/ssl.h (which for a first pull-request
will also require you to file contributor license agreement).  If that's
all too much work, I can fix the issue on your behalf.

> Will the function modify the data buffer in any way?

No.

> Also, is it safe to free the data after calling SSL_dane_tlsa_add

Yes.

> or phrased differently: Will SSL_dane_tlsa_add create a copy of the data?

Yes.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] SSL_dane_tlsa_add function signature

[Patrick Schlangen]

Hi,

please forgive me if this question has been asked before.

>  int SSL_dane_tlsa_add(SSL *s, uint8_t usage, uint8_t selector,
>   uint8_t mtype, unsigned char *data, size_t dlen);

Reading the docs, my impression ist hat SSL_dane_tlsa_add adds a TLSA record
to the SSL object for later use during verification.
What puzzles me is that the data argument of type unsigned char is not
const. Will the function modify the data buffer in any way?
Also, is it safe to free the data after calling SSL_dane_tlsa_add, or
phrased differently: Will SSL_dane_tlsa_add create a copy of the data?

Thanks a lot in advance,

Patrick



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