Closed rslabbert closed 9 years ago
Can you gist a full log of the build as well?
This is a log of three successive runs. This repeats, looping around to the first package again.
Closing this because it seems to be related to the openssl installation on my machine.
I have the same problem on Mac Os X.
A few things you can try:
/etc/ssl/certs/ca-certificates.crt
file for some reason, and that was causing many ssl applications to not have any cerificates.pip search whatever
and see if it gives you an ssl error, if it does then it might be global, otherwise it's a cargo thing.I have no problem visiting the https://crates.io with safari, the lock appears and everything is correct.
pip search returns a warning :
A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
/etc/ssl/certs/ca-certificates.crt
is empty, I installed openssl homebrew and it talks about the directory : /usr/local/etc/openssl/certs
Try renaming /etc/ssl/certs/ca-certificates.crt
and adding a .bak
to the end. If that file doesn't exist the SSL library will use it's own defaults.
Sorry I mean /etc/ssl/ doesn't even exist.
Firstly, the pip error might mean your python is out of date but it could also be related to a general SSL error. After you installed openssl did you do brew link --force openssl
?
Even after brew link --force openssl it shows the same error.
I'm having the same issue on OSX Yosemite 10.10.3. Doing a brew link --force openssl
does not fix the issue for me. It appears that cargo (version cargo 0.2.0-nightly (83a6d0e 2015-04-16) (built 2015-04-16)
) is linked against Apple's OpenSSL 0.9.8 dylibs in /usr/lib, while brew's dylibs are 1.0.0 (specifically, 1.0.2a).
pip search
works fine for me, so I don't think it's a global issue. Curl downloads it if I tell it to follow redirects.Wget also downloads it successfully.
So that some future person (maybe me?) Googling this issue knows how I fixed it, I had a rogue certificate bundle in /etc/openssl/cert.pem
which cargo was reading that mustn't have had the right cert in it. Moving it out of the way got things working again.
It seems I've got a certificate problem :
openssl verify /etc/openssl/cert.pem
/etc/openssl/cert.pem: CN = com.apple.systemdefault, O = System Identity
error 18 at 0 depth lookup:self signed certificate
CN = com.apple.systemdefault, O = System Identity
error 21 at 0 depth lookup:unable to verify the first certificate
But I have no idea how to resolve it.
I discovered that an RVM upgrade put that cert.pem
there during a recent upgrade. Other people have had issues with it: https://github.com/rvm/rvm/issues/3330 . Renaming that directory to e.g. /etc/openssl-bak
made cargo not find the cert and work correctly. Ultimately, I deleted the /etc/openssl
directory, but you might not be as cavalier about sudo as I was.
Thanks it was that, I renamed cert.pem.
I'm still having this issue.
This fixed the error and am now able to cargo build
sudo mv /etc/openssl /etc/openssl-bak
When I ran openssl verify /etc/openssl/cert.pem
the output was:
/etc/openssl/cert.pem: /CN=com.apple.systemdefault/O=System Identity
error 20 at 0 depth lookup:unable to get local issuer certificate
I seem to be having this issue on OSX 10.10.4 with openssl installed via brew and without an /etc/openssl/cert.pem certificate.
@djpalmer88 I have /etc/openssl/cert.pem and even /etc/openssl/certs/cert.pem
curl/git is working, cargo doesn't.
I'm actually seeing this on 10.10.4 (14E36b). curl/git and such all working fine. cargo (1.0 and nightly) refuse to download anything with the above mentioned error. This is regardless of removing /etc/openssl, updating certs there... etc. Turned out (thanks to dtruss ;) that in my case the following locations had a certs.pem with invalid certs:
/etc/openssl/certs.pem /usr/lib/ssl/certs.pem
Removing all of them did the trick.
@andoriyu try that location. If it still does not work, run cargo like this:
sudo dtruss cargo fetch
And look where it reads the certs.pem from.
Thanks, it worked.
Have this issue too, still have no clue how to solve it.
I have the same problem on mac os10.10.5 (14F27)
➜ racer git:(master) cargo build --release --verbose
Downloading syntex_syntax v0.13.0
Unable to get packages from source
Caused by:
Failed to download package `syntex_syntax v0.13.0` from https://crates.io/api/v1/crates/syntex_syntax/0.13.0/download
Caused by:
SSL peer certificate or SSH remote key was not OK
I can't get any crate on cargo.
@paomian what version of Cargo are you running? You may want to try using the latest Cargo builds as well and see if the problem is fixed.
@alexcrichton I tried the latest version of Cargo, the issue still exist. The only solution is rename /etc/opensll/cert.pem
I was having this issue again on OSX 10.11 Beta (15A279b)
Example output after cloning https://github.com/hyperium/hyper :
~/github/RUST/hyper master
❯ cargo fetch --verbose
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading gcc v0.3.16
unable to get packages from source
Caused by:
Failed to download package `gcc v0.3.16` from https://crates.io/api/v1/crates/gcc/0.3.16/download
Caused by:
Peer certificate cannot be authenticated with given CA certificates
[1] 23354 exit 101 cargo fetch --verbose
Since SSL certificate errors were being thrown from the https://crates.io domain, I tried importing the crates.io X.509 Certificate (PEM) with /Applications/Utilities/Keychain\ Access.app
mkdir -p ~/tmp && cd ~/tmp && openssl s_client -showcerts -connect crates.io:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >crates.io.pem
File -> Import Items...
or use the keybind Cmd+Shift+I ~/tmp
then Enter or click Go
crates.io.pem
then click Open
Category
click Certificates
Right click -> Get Info
, or double click the imported crates.io Certificate and click the Trust
dropdown. Secure Sockets Layer (SSL)
and select Always Trust
After doing the above, I haven't had a single error reported with cargo
e.g. The initial command repeated after importing crates.io.pem and trusting for SSL :
~/github/RUST/hyper master*
❯ cargo fetch --verbose
Updating registry `https://github.com/rust-lang/crates.io-index`
Downloading openssl-sys v0.6.5
Downloading traitobject v0.0.1
Downloading gcc v0.3.16
Downloading language-tags v0.0.7
Downloading regex v0.1.41
Downloading num v0.1.27
Downloading typeable v0.1.2
Downloading openssl v0.6.5
Downloading rand v0.3.11
Downloading advapi32-sys v0.1.2
Downloading libc v0.1.10
Downloading time v0.1.32
Downloading env_logger v0.3.1
Downloading winapi-build v0.1.1
Downloading aho-corasick v0.3.2
Downloading regex-syntax v0.2.2
Downloading pnacl-build-helper v1.4.10
Downloading pkg-config v0.3.5
Downloading libressl-pnacl-sys v2.1.6
Downloading log v0.3.2
Downloading solicit v0.4.4
Downloading cookie v0.1.21
Downloading httparse v0.1.6
Downloading lazy_static v0.1.14
Downloading winapi v0.2.4
Downloading tempdir v0.3.4
Downloading hpack v0.2.0
Downloading unicase v1.0.0
Downloading bitflags v0.3.2
Downloading num_cpus v0.2.6
Downloading kernel32-sys v0.1.4
Downloading rustc-serialize v0.3.16
Downloading mime v0.1.0
Downloading url v0.2.37
Downloading serde v0.6.0
Downloading matches v0.1.2
Downloading memchr v0.1.6
~/github/RUST/hyper master* 13s
❯
@alexcrichton I fix it when i mv /etc/openssl/cert.pem
to /etc/openssl/cert.pem.bak
, i use the last version of cargo. cargo 0.4.0-nightly (553b363 2015-08-03) (built 2015-08-02)
@paomian you may want to try a newer Cargo, there's a bugfix which may apply to you (66eed58784c0312b5ef027a8ac6dce2cea4eb548)
I also faced same problem while installing hyper.
cargo --version cargo 0.6.0-nightly (68e6799 2015-10-06) rustc --version rustc 1.4.0-dev (fd302a95e 2015-08-27)
Is there some problem on it?
I use cargo 0.6.0-nightly (ec85eef 2015-10-10), still have this issue.
Error info:
Downloading winapi v0.2.4
Unable to get packages from source
Caused by:
Failed to download package `winapi v0.2.4` from https://crates.io/api/v1/crates/winapi/0.2.4/download
Caused by:
SSL peer certificate or SSH remote key was not OK
Test with curl: curl https://crates.io/api/v1/crates/winapi/0.2.4/download -v
:
* Trying 54.243.67.21...
* Connected to crates.io (54.243.67.21) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: crates.io
* Server certificate: RapidSSL SHA256 CA - G3
* Server certificate: GeoTrust Global CA
> GET /api/v1/crates/winapi/0.2.4/download HTTP/1.1
> Host: crates.io
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: keep-alive
< Server: nginx
< Date: Sun, 11 Oct 2015 12:50:29 GMT
< Transfer-Encoding: chunked
< Location: https://crates-io.s3-us-west-1.amazonaws.com/crates/winapi/winapi-0.2.4.crate
< Set-Cookie: cargo_session=--3c156d7a3629aa08a1a0d538832f99ea30835cc8; HttpOnly; Secure; Path=/
< Strict-Transport-Security: max-age=31536000
< Via: 1.1 vegur
<
* Connection #0 to host crates.io left intact
Also using cargo 0.6.0-nightly (ec85eef 2015-10-10), I faced the same issue on all the crates I tried to install. Can confirm that mv /etc/openssl/cert.pem to /etc/openssl/cert.pem.bak
fixes it. Mac OS X 10.10.5
@djKooks, @towry, @rgardner these sorts of errors are typically related to a nonstandard local OpenSSL installation, do you know of any oddities with how openssl was installed locally for you?
I have openssl installed through homebrew, but even after uninstalling it (and unlinking it) and having the /etc/openssl/cert.pem
file present, I still get the SSL peer certificate or SSH remote key was not OK
message. I'm can't think of any other oddities around openssl on my system (that I know of).
@rgardner hm I'm curious, but do you know how /etc/openssl
was created? I'm on 10.10.5 as well and I don't seem to have that directory existing at all. I also tried installing openssl via homebrew and linking via brew link --force openssl
and everything worked out locally for me.
@rgardner @alexcrichton /etc/openssl
may be created by rvm
, it seems that rvm
also created /usr/local/etc/openssl
.
Hm how'd you install rvm? I just installed it and /etc/openssl
wasn't created or touched
Hmm, Finder tells me that my /etc/openssl/cert.pem
was created March 2014. I do have rvm installed, maybe it was an older version that created a cert.pem
that conflicts with cargo. I successfully used Cargo in rust beta without modifying /etc/openssl/
though, so could have been a change in Cargo or in my cert.pem
file after an rvm update.
It seems is this case: https://github.com/rvm/rvm/issues/2875#issuecomment-44142789, probably also this: https://github.com/rvm/rvm/issues/3330
I deleted /etc/openssl
folder, everything works fine.
@towry is it okay after deleting it? Is it okay using rvm?
I'm on OSX El Capitan, removing /etc/openssl/cert.pem
did the trick.
@rodrei do you know what introduced that file in the first place?
@alexcrichton Sorry, I don't. It was the first time I was attempting to use Cargo to install dependencies.
@alexcrichton Some more info: I was trying to install some gems using the gem
command and it failed with a cert related error. I then added back the file /etc/openssl/cert.pem
and it started working again. I'm using RVM.
Ran into this same issue today. Removing the cert.pem worked for me, too.
Same thing happened to me on Arch Linux. The directory /etc/openssl does not exist. Renaming /etc/ssl/cert.pem does not help.
ERROR:conduit_log_requests: 127.0.0.1:34588 [2016-01-30T03:16:34+01:00] Put /api/v1/crates/new - 384ms 500: failed to upload to S3:
/crates/testtt/testtt-0.1.0.crate
failed to upload to S3:/crates/testtt/testtt-0.1.0.crate
caused by SSL peer certificate or SSH remote key was not OK Caused by: SSL peer certificate or SSH remote key was not OK
@alexcrichton Is this issue resolved? I am getting this error with the latest stable release. I am running this on Ubuntu docker image.
openssl verify -verbose /etc/ssl/certs/ca-certificates.crt
/etc/ssl/certs/ca-certificates.crt: OK
git config --global http.sslverify false
http://docker.for.mac.host.internal:8098 git clone https://github.com/rohitjoshi/turing-db
Cloning into 'turing-db'...
remote: Enumerating objects: 107, done.
remote: Counting objects: 100% (107/107), done.
remote: Compressing objects: 100% (56/56), done.
remote: Total 107 (delta 54), reused 91 (delta 47), pack-reused 0
Receiving objects: 100% (107/107), 65.41 KiB | 2.62 MiB/s, done.
Resolving deltas: 100% (54/54), done.
cargo --version
cargo 1.30.0 (a1a4ad372 2018-11-02)
https_proxy=http://docker.for.mac.host.internal:8098 cargo build --release
Updating crates.io index
warning: spurious network error (2 tries remaining): [60] SSL peer certificate or SSH remote key was not OK (SSL certificate problem: self signed certificate in certificate chain); class=Net (12)
warning: spurious network error (1 tries remaining): [60] SSL peer certificate or SSH remote key was not OK (SSL certificate problem: self signed certificate in certificate chain); class=Net (12)
error: failed to fetch `https://github.com/rust-lang/crates.io-index`
Caused by:
[60] SSL peer certificate or SSH remote key was not OK (SSL certificate problem: self signed certificate in certificate chain); class=Net (12)
@rohitjoshi sounds like https://github.com/rust-lang/cargo/issues/1180
Yes, it is duplicate.thanks.
Hmm, now I'm getting this out of nowhere
error: failed to download from `https://crates.io/api/v1/crates/time-macros/0.2.8/download`
Caused by:
[60] SSL peer certificate or SSH remote key was not OK (SSL certificate problem: unable to get local issuer certificate)
I ran
$ openssl verify -verbose /etc/ssl/certs/ca-certificates.crt
/etc/ssl/certs/ca-certificates.crt: OK
I ran the following without it helping
$ sudo mv /etc/ssl/certs /etc/ssl/certs.bak
I'm running WSL. For me, the problem was that Windows correctly updated for daylight saving time but not the WSL instance I was running in. Restarting WSL got it working,
Running
cargo build --verbose
produces an "SSL peer certificate or SSH remote key was not OK" when attempting to download a package from crates.io. Packages from github are pulled without any problems. My system is OSX Yosemite 10.10.2.Interestingly, when attempting to download the package manually from https://crates.io/api/v1/crates/package/x.x.x/download with curl, nothing is downloaded, but with wget the download succeeds.
I can also confirm that it's not a network issue as another computer on my network(running windows) can download the packages without any issues.