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
--
> 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
> X509
> 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/
>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 -D
> 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
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
> 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/
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 "untruste
> 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
> 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
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
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
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
> 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 us
> 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,
Pa
> 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
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
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 combi
18 matches
Mail list logo
