nextclade: Error using `nextclade dataset get` behind proxy: CURLE_PEER_FAILED_VERIFICATION: SSL peer certificate or SSH remote key was not OK

Hi Eric @EricFournier3,

Sorry, Nextclade does not have the proxy networking functionality and it seems to be out of scope of the project.

You should bring that up with your IT team and tell them that their technical implementation prevents you from doing your job. It’s their responsibility to ensure you can do your work effectively. Otherwise why they exist?

Also note that these restrictions might be done on purpose. I.e. they don’t want you to download any files from the internet. In that case, you are about to violate some rules, and it’s no longer a technical problem - you should seek support of your superiors instead.

If that does not work, you have a few options (from simple and sane to complicated and ridiculous, depending on how bad your situation is):

• use Nextclade Web
• use a proxifier - put a special piece of software in between the proxy and nextclade, which will translate whatever is needed to make https requests to the outside world work
• download the dataset as usual on another machine and carry it over to your worker machine
• download the dataset from GitHub
• implement a dataset download script using the tools that work (and are allowed). Start with the index.json file, pick one of the dataset versions and look at the ‘files’ array. That’s what Nextclade does.
• use a VPN, WireGuard or Tor to bypass the restrictions - this is technically very involved, and is likely to get you into troubles if you are caught. But this is what unreasonably brave people might use in countries with state-sanctioned firewalls.
• use a bastion host - if you can get access to another machine on the same network as your worker machine, but also has access to the internet, you might be able pipe your traffic through that machine, i.e. using an SSH tunnel, bypassing the proxy

Unfortunately, we don’t have bandwidth to support any of these use-cases officially, but feel free to reach out with questions.

If you ever find a solution or a workaround, please post here so that other users could also benefit.

If you or your colleagues have some time, you could also take a look at how proxy support might be implemented in nextclade. Nextclade is currently using libcurl for networking, and I know that curl has a --proxy flag, so pushing through HTTP proxies might be doable. I don’t have enough knowledge in this area, and neither I have information on what kind of different proxy configurations you or other users might have. As I don’t have any of these proxies handy, I also will not be able to test if it works even if I implement it. Contributions in this area are welcome.

We are planning some mid-term changes in Nextclade which may or may not help to resolve this - the network implementation will be different and it might have a better support for proxies (or not).

Hi, It looks like this problem is coming from the openssl crate: https://docs.rs/openssl/latest/openssl/

The vendored copy will not be configured to automatically find the system’s root certificates, but the openssl-probe crate can be used to do that instead.

This could explain why nextclade dataset fails on a properly configured system, where curl and wget work flawlessly in a shell, with https requests going through a transparent proxy (for web filtering). i.e. With the proxy’s cert’s CA in the system CA store or with environment variables and a CA bundle file.

I’ll let you do your excellent development work from here, I’m back to my questionable existence as a sysadmin in an IT team. 😉

I don’t think the issue here is lack of proxy support. My understanding is that libcurl respects standard proxy environment variables unless they’ve been explicitly disabled/overridden by libcurl init options (which I assume Nextclade wouldn’t be doing).

Instead, I think nextclade’s libcurl either…

1. …isn’t using the system CA store (because libcurl is statically compiled into nextclade?), or…
2. …@EricFournier3’s proxy’s cert’s CA isn’t in their system CA store (in which case it’s likely only in their browsers’ local CA stores).

Situation 1 seems most likely to me given the info so far. To fix this and retain the use of the proxy, @EricFournier3 should be able to set the CURL_CA_BUNDLE environment variable to a CA bundle file that includes the proxy’s cert’s CA. Curl’s CA store handling is described a bit more on these two pages:

• https://everything.curl.dev/usingcurl/tls/verify
• https://curl.se/docs/sslcerts.html

This situation is fairly common. As an example of this happening elsewhere, @jacaravas ran into a similar issue in nextstrain/ncov with the Python requests library and was able to resolve it by setting request’s corresponding env var (REQUESTS_CA_BUNDLE).