Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support in-memory client / CA certificates #89

Closed
kathampy opened this issue Oct 1, 2019 · 6 comments
Closed

Support in-memory client / CA certificates #89

kathampy opened this issue Oct 1, 2019 · 6 comments
Labels
blocked feature A new feature!

Comments

@kathampy
Copy link

kathampy commented Oct 1, 2019

Probably requires some upstream changes in curl-rust.
https://curl.haxx.se/libcurl/c/usercertinmem.html
https://curl.haxx.se/libcurl/c/cacertinmem.html

@sagebind sagebind added the feature A new feature! label Oct 4, 2019
@kathampy kathampy changed the title Support in-memory client certificates Support in-memory client / CA certificates Oct 4, 2019
@sagebind
Copy link
Owner

sagebind commented Oct 8, 2019

This is pretty tricky to implement correctly. The linked examples are OpenSSL-specific, but libcurl is linked to platform-native TLS implementations on Windows and macOS by default. In fact, CURLOPT_SSL_CTX_FUNCTION does nothing unless OpenSSL, wolfSSL, or mbedTLS are in use. I'm not sure I'm willing to expose this option, especially if #22 goes through and MesaLink is always used on all platforms, which does not support this.

@sagebind
Copy link
Owner

sagebind commented Oct 8, 2019

Looking at the MesaLink APIs, it should be similar enough to OpenSSL to accomplish what those curl examples are doing using MesaLink. I can look into adding support for CURLOPT_SSL_CTX_FUNCTION for MesaLink upstream (as in libcurl itself). If we go down this path, we will want to either

  1. Tie Isahc 100% to bundled libcurl builds and MesaLink for TLS. Extended TLS options can be added to Isahc's API with confidence that it will work. Or,
  2. Detect what libcurl and TLS versions we are linked to at runtime and emit an error when using these configuration options so that the user knows that they will not work and can handle the case appropriately.

@Mythra
Copy link
Contributor

Mythra commented Oct 29, 2020

👋 Hey I just came to this. Looks like the current blocker is on MesaLink? Is #2 still an option in the short term? I'm interacting with services self-signed by a certificate authority i fetch from a trusted endpoint. Having to dump the files to disk is pretty unfortunate 😅 .

@sagebind
Copy link
Owner

No, unfortunately. MesaLink still does not support the necessary features to work with an HTTP/2+ build, and the project has been dead silent for some time, so my hopes are not high at this point. I'm putting much more hope in #199 instead that eventually rustls will be the default and we can control TLS options that way.

sagebind added a commit that referenced this issue Apr 16, 2021
Pull in new bindings for the new blob APIs added to curl in 2020. Bindings were recently added in alexcrichton/curl-rust#384. This of course only works when using a fairly new curl version.

Addresses #89.
@sagebind
Copy link
Owner

At long last, this is finally now possible for us to support since it was finally added to curl itself upstream in 2020 in the form of CURLOPT_SSLCERT_BLOB, CURLOPT_SSLKEY_BLOB, etc. I have a provisional PR implementing this here: #320.

sagebind added a commit that referenced this issue Apr 23, 2021
Pull in new bindings for the new blob APIs added to curl in 2020. Bindings were recently added in alexcrichton/curl-rust#384. This of course only works when using a fairly new curl version.

Addresses #89.
@sagebind
Copy link
Owner

This is now available in the 1.4.0 release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked feature A new feature!
Projects
None yet
Development

No branches or pull requests

3 participants