Replies: 7 comments 10 replies
-
I would be open to supporting this in |
Beta Was this translation helpful? Give feedback.
-
|
I really would like to rely on the default truststore of my TLS impl instead of pointing to it explicitly. |
Beta Was this translation helpful? Give feedback.
-
OpenSSL, GnuTLS and wolfSSL do have. You just need to invoke the functions and rely on them. |
Beta Was this translation helpful? Give feedback.
-
|
none of them have their own trust stores |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand what you're asking for. |
Beta Was this translation helpful? Give feedback.
-
I never said that. Default does not mean own. Admin needs to populate, but the client does not have to take care of or where it resides. Do you know where Windows actually stores the CAs, or Keychain? No, and you don't care. You just use the API for that. Just make use of |
Beta Was this translation helpful? Give feedback.
-
I think the correct way is using |
Beta Was this translation helpful? Give feedback.
-
|
For me, the ideal situation would be that curl would work like this, independent of which TLS library it is built to use:
if asked to use a specific CA cert file/dir, that set is then used instead of the default. I believe this matches what @icing says above. |
Beta Was this translation helpful? Give feedback.
-
|
This implies that every store can read a common format which is not achievable. But the idea sounds reasonable, at the end you confirm what I would like to see. |
Beta Was this translation helpful? Give feedback.
-
|
To add even more "color" to this, there are also Windows-specific build flags to control
IMO option 3 is the desirable default option, or possible the only option, once we This also looks like an opportunity to discuss how libcurl should behave by default I think it'd be useful if libcurl would also default to the native CA. It would allow using |
Beta Was this translation helpful? Give feedback.
-
|
Now we have #18703 with support for the native trust service in Apple operating systems. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to add how useful this work would be. We have recently converted the HTTP client component of our cross platform (win, Linux, macos, ios, android) application from using Qt to use libcurl. The single biggest complication we faced was around the issue of access to the native CA stores, so having this work "out of the box" across as many platforms as possible would be great. In particular, given the removal of SecureTransport, it would be great if these was a straightforward way of doing HTTPS on iOS. |
Beta Was this translation helpful? Give feedback.
-
|
iOS and its friends is the major motivation for doings this, yes. Nice to hear that libcurl improved your feature set and performance as well.❤️ |
Beta Was this translation helpful? Give feedback.
-
|
With the merge of #18703 and release in the upcoming 8.17.0, I close this discussion. Thank to everyone participating. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
There are lengthy discussion in #18279 and #16181 and how curl should use/integrate "CA"s (meaning, to be precise a "set of trust anchors") from the platform it is on (commonly referred to as the "Native CA") and files/folders/blobs.
The CA Mess We're In
There are several concepts in
curl/libcurlthat influence the set of trust anchors. It is quite convoluted across platforms and TLS backends on how they are used and interact with each other.Native CA
All modern OS maintain their own list of trust anchors for certificate verification. This store we refer to as the "Native CA" of the host. There are three way that
libcurlcan use it:Embedded CA
A set of trust anchors, configured in the build that becomes part of the
curlexecutable.CURL_CA_BUNDLE / CURL_CA_PATH
A file/path on the host system that is configured by default in
libcurlto be used in TLS backends. Can also be overridden via environment variables.Fallback CA
The issue has become more muddled over the years by introducing a feature called a "Fallback CA". This is configured at build time, only has an effect on Windows, only affects OpenSSL builds and has weird interactions with all other options at runtime, even if the "Native CA" did not have any readable trust anchors when interrogated.
Usability
We want the following for
curl/libcurlusers:https:transfer to public server should work without having to twiddle the CA options.These has been a lot of focus on (1) in the discussions. But (2) is equally important in times where more governments/agencies manage to force their trust anchors into systems.
in
curlFor the command line (1) means that when no CA option is given,
curlshould use the best defaults it knows/is configured with on the platform. And if a CA option is specified (like--cacert),curlneeds to use only those and not any other defaults it has. (@jay, I believe this is the main point you were trying to make. Please correct me if I got that wrong.)in
libcurlIn the library, the different CA options need to be additive, not exclusive. This is needed to transform a
curlcommand line like--ca-native --cacert certs.peminto the correct transfer settings. (open for discussion: I think the command line should work this way.)Imperfections
It will be impossible to make all platforms and TLS backends to behave exactly the same.
rustlsfor example supports native and file based verifiers but no a mix of them. OpenSSL can, but ignores "Native CAs" on anything but Windows. GnuTLS imports system certificates on many platforms and can mix them. Schannel...does Schannel things.Discussion Points
We should come to an agreement on how the CA use is supposed to work, to guide the implementation for build system, curl tool and library TLS implementations:
Beta Was this translation helpful? Give feedback.
All reactions