Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: -cacert behaves differently on Windows and Unix. Does this matter?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 9 May 2025 18:15:22 +0200 (CEST)
On Fri, 9 May 2025, Rod Widdowson via curl-library wrote:
> Let me start by stating up front that I do not profess to have any expertise
> in this area. This is just something I noticed while I was spelunking some
> code and understanding the why's would help me a lot. So if what I am
> saying is flawed please point it out.
Before even adressing what you say, let me interrupt you and first say that
your entire premise is wrong:
It is not about Windows and Unix at all. It is about curl behaving slightly
different depending on which TLS backend it is built with and told to use.
Because no matter how much we want to, we can't make them work 100%
identically. In some cases there can of course also be plain bugs causing it.
> in all three cases Curl/OpenSSl checks that the provided cert is in the
> chain somewhere and all is good according the PKIX spec and hey presto the
> web page is printed to stdout.
Some would say that accepting a "leaf" is the incorrect approach and that only
the root of the chain should be accepted. There are different "schools" of
which way is the right one.
> On Windows it is different.
I take it you mean the curl tool that comes bundled with Windows shipped by
Microsoft themselves? That one uses Schannel as a TLS backend. The official
curl for Windows shipped by the curl project (https://curl.se/windows/)
instead uses LibreSSL, making "on Windows" not a specific enough qualifier.
> The last line (where I specify the root cert) works, but the other two fail
Right, because they (Microsoft) think it should do so and we can't change it.
> What I don't understand is why this isn't a bigger deal and how I should go
> about setting things up so that I can restrict my curl connections to a
> specific certificate or only those signed by specific CA, not pretty much
> everyone in the whole world.
Then I believe you need to use pinning because that is typically not what
verifying a server's TLS certificate means. The verification means that it was
signed by a CA you trust.
> Additionally I'll observe that the curl code only ever inspects the first
> cert chain presented. I don't know if this matters, but it would seem to
> argue that cross signing certificates might be problematic.
I don't believe that is generally true. We get countless of questions from
people that get errors from curl when servers don't present their intermediate
certificate - a quite common server setup mistake.
Date: Fri, 9 May 2025 18:15:22 +0200 (CEST)
On Fri, 9 May 2025, Rod Widdowson via curl-library wrote:
> Let me start by stating up front that I do not profess to have any expertise
> in this area. This is just something I noticed while I was spelunking some
> code and understanding the why's would help me a lot. So if what I am
> saying is flawed please point it out.
Before even adressing what you say, let me interrupt you and first say that
your entire premise is wrong:
It is not about Windows and Unix at all. It is about curl behaving slightly
different depending on which TLS backend it is built with and told to use.
Because no matter how much we want to, we can't make them work 100%
identically. In some cases there can of course also be plain bugs causing it.
> in all three cases Curl/OpenSSl checks that the provided cert is in the
> chain somewhere and all is good according the PKIX spec and hey presto the
> web page is printed to stdout.
Some would say that accepting a "leaf" is the incorrect approach and that only
the root of the chain should be accepted. There are different "schools" of
which way is the right one.
> On Windows it is different.
I take it you mean the curl tool that comes bundled with Windows shipped by
Microsoft themselves? That one uses Schannel as a TLS backend. The official
curl for Windows shipped by the curl project (https://curl.se/windows/)
instead uses LibreSSL, making "on Windows" not a specific enough qualifier.
> The last line (where I specify the root cert) works, but the other two fail
Right, because they (Microsoft) think it should do so and we can't change it.
> What I don't understand is why this isn't a bigger deal and how I should go
> about setting things up so that I can restrict my curl connections to a
> specific certificate or only those signed by specific CA, not pretty much
> everyone in the whole world.
Then I believe you need to use pinning because that is typically not what
verifying a server's TLS certificate means. The verification means that it was
signed by a CA you trust.
> Additionally I'll observe that the curl code only ever inspects the first
> cert chain presented. I don't know if this matters, but it would seem to
> argue that cross signing certificates might be problematic.
I don't believe that is generally true. We get countless of questions from
people that get errors from curl when servers don't present their intermediate
certificate - a quite common server setup mistake.
-- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-05-09