> You don't have to explain the code to me. :-)
^^. Ok. I was also trying to explain what I understood so you can correct
me if I'm wrong.
Everything is Cristal clear now.
Thanks a million.
On Sun, 3 Oct 2021, 22:25 Viktor Dukhovni,
wrote:
> On Sun, Oct 03, 2021 at 09:33:29PM +0200, Alex
On Sun, Oct 03, 2021 at 09:33:29PM +0200, Alex Robuchon wrote:
> > Not quite, a candidate chain is constructed from whatever certificates the
> > peer (server in your case) provided, and then passed to the callback with
> > "preverify_ok" set to false (for the top certificate), because the chain
>
> Not quite, a candidate chain is constructed from whatever certificates the
> peer (server in your case) provided, and then passed to the callback with
> "preverify_ok" set to false (for the top certificate), because the chain is
> not trusted.
>
This confuses me a little bit because I thought
> On 3 Oct 2021, at 12:33 pm, Alex Robuchon
> wrote:
>
> So I suppose openssl skip the part that is supposed to build the chain when
> no store is configured.
Not quite, a candidate chain is constructed from whatever certificates
the peer (server in your case) provided, and then passed to the
I just had a big laugh Reading this. I never had to dig into openssl before
so I unfortunately had to try to understand your API with eventmachine as
an example. Silly me.
> On the other hand I suppose if we do not call this it would pick the
> "default" trust store from the system which seems
On Sun, Oct 03, 2021 at 01:54:44PM +0200, Alex Robuchon wrote:
> Thanks for the detailed answer.
>
> From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1
>
> When I use the eventmachine lib that uses the wrong cert chain I can see
> with strace :
Run as far away from
Thanks for the detailed answer.
>From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1
When I use the eventmachine lib that uses the wrong cert chain I can see
with strace :
openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such
file or directory)
On Sat, Oct 02, 2021 at 06:21:00PM +0100, Angus Robertson - Magenta Systems Ltd
wrote:
> > Yes. To make things even more complex, a few sites also have an
> > older version of R3 that is directly signed by the DST root:
> >
> > - leaf <- R3 <- DST Root CA X3 (self-signed)
> >
> > but
> Yes. To make things even more complex, a few sites also have an
> older version of R3 that is directly signed by the DST root:
>
> - leaf <- R3 <- DST Root CA X3 (self-signed)
>
> but that's far from common at this point.
That old R3 root was issued last winter and got installed in
On Sat, Oct 02, 2021 at 05:24:26PM +0200, Alex Robuchon wrote:
> The project has a callback function registered with SSL_CTX_set_verify
> and failed to verify DST Root CA X3 since it expired.
That happens when either:
* The configured trust store (perhaps not the default system
trust
10 matches
Mail list logo
