Client certificate authentication

[Massimo B.]

Hello everybody,

on https://stackoverflow.com/questions/50694429/curl-with-client-certificate-aut
hentication
we already solved why Firefox was able to authenticate to a server while curl
was always failing.

A Wireshark trace revealed that Firefox is sending not only the client
certificate but also one intermediate CA cert that is part of the 4 cert trust
chain up to the highest Root CA Cert.

Using curl I got that done by adding --cacert.
However man curl, --cacert <file> is unclear about that:

"(TLS) Tells curl to use the specified certificate file to verify the
peer." or even wrong, as this cert is added to the client cert at TLS
handshake."

As far as I understand this is only used to validate the server cert on client
site.

In curl I got it also solved without --cacert when merging both certs into one
.pem file and using that as --cert.

I would propose to adapt the handling about --cacert and/or adapt the
documentation about it.

Looking on how Qt for instance is doing this:
https://doc.qt.io/qt-5/qsslconfiguration.html#setLocalCertificate
Can only add one certificate. For the others I guess it is
https://doc.qt.io/qt-5/qsslconfiguration.html#setLocalCertificateChain

The method
https://doc.qt.io/qt-5/qsslconfiguration.html#setLocalCertificate
doesn't change anything about the certificates send from the client but as
described just changes the database for validating the peers certificate.

So I would propose to change --cacert to this behaviour and add some
--certchain to explicitly add more certificates of the trust chain.


Question however is: Is this a common approach to send the CA certificate as
well? Where is this documented as TLS doesn't describe that:
https://tools.ietf.org/html/rfc5246#section-7.4.6

Why behaves Firefox that way and how does it know to only send one intermediate
in a chain of 4 certificates in total up to the root cert? It could have also
sent 2 intermediates or all.

At subscription to the server they provided a list of trusted CAs, Comodo was
there and we purchased a signed cert from them. So actually they should have all
Root CAs and intermediate on the server, just like a Firefox installation also
has.
To me it is non-sense sending the intermediate cert. This sounds like providing
the (potentially corrupted) trust chain to the other peer. Instead I think the
other site should have the freedom to choose which CAs it trusts and fetch the
CA certs itself.
As the server already has our certificate from the subscription process, they
should actually only match this instead of validating with the CA.

As client cert auth is rare, I don't find examples how servers actually do this.

Best regards,
Massimo
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/e

[Daniel Stenberg]

On Fri, 8 Jun 2018, Massimo B. wrote:

Let me preface my response here by saying we're talking about curl built with
the OpenSSL backend here.

Using curl I got that done by adding --cacert. However man curl, --cacert
"(TLS) Tells curl to use the specified certificate file to verify the peer."
or even wrong, as this cert is added to the client cert at TLS handshake."
As far as I understand this is only used to validate the server cert on
client site.

The file name passed in with --cacert is set to the OpenSSL function
SSL_CTX_load_verify_locations, and unfortunately the documentation for this
function is very sparse on details on what it does when a client certificate
is used:
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_load_verify_locations.html

In curl I got it also solved without --cacert when merging both certs into
one .pem file and using that as --cert.

I think that feels like the correct way to do it. I think we should consider
ammending the --cert documentation to mention the case with intermediate
certs.

I would propose to adapt the handling about --cacert and/or adapt the
documentation about it.

Can you please suggest wording for our docs that you think would clarify and
help the next user who falls into the same problem as you did here?

So I would propose to change --cacert to this behaviour and add some
--certchain to explicitly add more certificates of the trust chain.

But why?

[Massimo B.]

Post by Daniel Stenberg
The file name passed in with --cacert is set to the OpenSSL function
SSL_CTX_load_verify_locations, and unfortunately the documentation for this
function is very sparse on details on what it does when a client certificate
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_load_verify_locations.html

I would like to reproduce the issue with openssl s_client and just forward this
whole issue to the openssl group.

Post by Daniel Stenberg
I think that feels like the correct way to do it. I think we should consider
ammending the --cert documentation to mention the case with intermediate
certs.

Yes, or just allow multiple --cert, which doesn't currently work.

Post by Daniel Stenberg
Can you please suggest wording for our docs that you think would clarify and
help the next user who falls into the same problem as you did here?

I can't suggest a working for --cacert as I don't actually now what it does,
regarding that even the openssl documentation is weak about it as you say.

I just know...

Post by Daniel Stenberg

Post by Massimo B.
So I would propose to change --cacert to this behaviour and add some
--certchain to explicitly add more certificates of the trust chain.

But why?

...that --cacert should not change the list of client certs but only the CA db
used for validation.

Having multiple --cert or a merged cert file is also not that correct, as there
is always only one client cert, or maybe multiple client certs if available. The
rest like in my case are CA certs, just used to sign the client cert, required
for validation. Therefore I suggested to add those to something new like
--certchain, similar to the Qt methods. However I'm not completely sure if those
Qt methods do what I expect them to do..

Best regards,
Massimo
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.ht