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.

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