-
Notifications
You must be signed in to change notification settings - Fork 952
rustup refuses server certificate on openSUSE Tumbleweed #2878
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
Comments
Is that local time accurate in the I'm curious if there's something in the reqwest invocation or whichever TLS backend being used that's not utilizing the local issuer certificates. What happens if you repeat this process with the environment variable |
I was able to install Rust on openSUSE running under WSL. But the problem persists on my regular openSUSE box. I've compared installed system packages between this openSUSE instance running under WSL2 with my regular openSUSE box.
I've then uninstalled several packages which accumulated along the years from my regular openSUSE box, making sure that I try to install Rust once again for every batch of packages which are uninstalled. Even after cleaning packages to the point that both machines look similar... even after that... I'm still not able to run This approach was insufficient for mitigating the issue. |
I've discovered that my system had accumulated a relative large number of package repositories and it has a lot of stuff which probably is colliding to each other in multiple ways. I've decided for reinstalling openSUSE. Hours later... After reinstalling openSUSE from scratch I was able to install Rust as usual. I'll leave this issue open so that you guys decide whether Note: I've observed that, in Debian 11, looking for packages containing $ apt search openssl | fgrep dev | fgrep openssl | fgrep rust
librust-cargo+openssl-dev/stable 0.43.1-4 amd64
librust-curl+openssl-probe-dev/stable 0.4.33-1 amd64
librust-curl+openssl-sys-dev/stable 0.4.33-1 amd64
librust-curl-sys+openssl-sys-dev/stable 0.4.36-1 amd64
librust-git2+openssl-probe-dev/stable 0.13.11-2 amd64
librust-git2+openssl-sys-dev/stable 0.13.11-2 amd64
librust-openssl-dev/stable 0.10.29-1 amd64
librust-openssl-probe-dev/stable,now 0.1.2-1+b1 amd64 [installed]
librust-openssl-sys-dev/stable 0.9.55-2 amd64 I don't see similar packages on openSUSE, though... at least not after reinstalling the system, which resets the repositories to default settings. |
@facklambda :: I've seen other issues mentioning that date/time must be accurate, NDP client must be active, etc. I can guarantee that my computers are all configured to obtain date/time from NDP servers. I believe that the problem was related to certificates being obtained from wrong locations. Unfortunately, I could not wait for this issue to be solved, I mean: I had to reinstall openSUSE from scratch and move on, which means that we don't have a computer anymore for exploring whatever went wrong. For your information, in my brand new openSUSE installation, the command |
@frgomes interesting, I wonder if the freshly installed rustup is still using the reqwest backend. |
@facklambda : It is, apparently. $ rustup -v check
verbose: read metadata version: '12'
verbose: creating temp file: /home/rgomes/.rustup/tmp/c5pvsrolbn7q91pz_file
verbose: downloading file from: 'https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256'
verbose: downloading with reqwest
verbose: deleted temp file: /home/rgomes/.rustup/tmp/c5pvsrolbn7q91pz_file
stable-x86_64-unknown-linux-gnu - Up to date : 1.56.0 (09c42c458 2021-10-18)
rustup - Up to date : 1.24.3 |
With no ability to investigate (due to perfectly reasonable reinstallation by OP) and no ability to reproduce when I tried, I'm going to have to close this. If someone else has this problem in the future, we should open a fresh issue and work through as much careful detail as possible. |
Problem
rustup refuses the server certificate on openSUSE Tumbleweed.
curl
andopenssl
accept the server certificate as it should be.Steps
curl
andopenssl
accept the server certifcate on this very same machine and terminal session:I would expect a successful output, like it happens on my Debian 11 box:
Possible Solution(s)
Nothing listed below produced any benefit:
i've found this
///var/lib/ca-certificates
above suspicious.Notes
Output of
rustup --version
:Output of
rustup show
:The text was updated successfully, but these errors were encountered: