[openssl-users] Binding the socket to a source IP address before connect
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
> 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
> 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
>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
> 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
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
> 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
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
> 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
> 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
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
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+
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
> 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
> 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
> 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
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
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