On Thursday, November 1, 2018 10:15:51 PM CET James Short wrote:
> Thanks for your response!
>
> I got the 7.29.0 source and compiled with openssl instead and I just can
> include the cert/inter chain in --cert and it works fine.
>
> I guess NSS does things in contention with the curl documentation :(. I'm
> limited to this curl as it is in our yum repos. I might add a new one with
> updated curl and have it compiled with OpenSSL instead.

The downside of this solution is that you will need to handle security updates
of (lib)curl yourself from now on.

Kamil

> On Thu, Nov 1, 2018 at 9:45 AM Kamil Dudka <kdudka_at_redhat.com> wrote:
> > On Thursday, November 1, 2018 4:53:26 PM CET Daniel Stenberg wrote:
> > > On Wed, 31 Oct 2018, James Short wrote:
> > > > I'm trying to test mTLS with curl/nginx. The server side client
> > > > verification is going fine as my system ca-certs has the relevant root
> >
> > for
> >
> > > > the server cert/inter chain nginx is sending to curl. However, I have
> >
> > a
> >
> > > > client cert/inter chain that I'm passing via --cert and only the
> > > > client
> > > > cert (first pem entry) is sent to the server.
> > >
> > > (Let me first preface this reply by saying that I'm far from an expert
> > > in
> > > TLS and client certs.)
> > >
> > > This is probably curl functionality that is TLS backend dependent.
> > > You're
> > > using a curl built to use NSS, so maybe there's a bug there.
> > >
> > > But also: your curl version (7.29.0) is over five years old. We have
> >
> > quite
> >
> > > literaly fixed thousands of bugs since that was released, and maybe we
> > > improved in this area as well.
> > >
> > > > With openssl s_client, I can use -CAfile to include the intermediate
> >
> > as it
> >
> > > > is only used for client cert verification. With curl, if I put the
> > > > intermediate for the client cert in a file and point to it with
> >
> > --cacert,
> >
> > > > then *server* certificate validation fails because the root for the
> >
> > server
> >
> > > > cert validation is no longer there.
> > >
> > > Right, because curl's --cacert option is the CA bundle used for
> > > verifying
> > > the server.
> > >
> > > > The workaround is to concatenate my system root and my client cert
> > > > intermediate into a new file and point to it with --cacert. This
> >
> > tells me
> >
> > > > that --cacert is used for building/verifying both server and client
> > > > certificate chains.
> > >
> > > That surprises me, and might also be a TLS backend specific thing. I
> > > would've expected a work-around to concatenate them for the --cert
> >
> > option.
> >
> > This use-case was discussed at the following upstream issue:
> >
> > https://github.com/curl/curl/issues/851
> >
> > The ability of libcurl to load certificates from files is limited when it
> > uses
> > NSS for TLS. Not that I tried it myself but you should be able to import
> > the
> > certificates to the native NSS database and control the trust more
> > precisely.
> >
> > Kamil

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-11-02