Every now and then I'm encountering problems with scripts hosted on Github which have been linked using https. I've usually managed to get around it one way or the other, but I'm wondering what's the proper way of solving this?
Here's an example: I'd like to make use of this Rails Application template.
Running
rails new APP_NAME -m https://raw.github.com/RailsApps/rails3-application-templates/master/rails3-devise-rspec-cucumber-template.rb -T
will throw:
certificate verify failed (OpenSSL::SSL::SSLError)
What is the proper way of going about this situation without editing the script itself?
UPDATE
I've tried so far as well
export GIT_SSL_NO_VERIFY=true
but I keep on getting the same error.
I also exported the certificate from Firefox as github.com.pem and simply dragged it into my unlocked Keychain Access. The certificate is now listed but the error remains the same.
UPDATE 2
As awful this solution is, this hack works: http://blog.dominicsayers.com/2011/08/16/howto-use-a-rails-template-from-github-on-windows/
It seems that simply "updating" the certificates is the best option:
$ cd /usr/share/curl/
$ sudo wget http://curl.haxx.se/ca/cacert.pem
$ sudo mv curl-ca-bundle.crt old.curl-ca-bundle.crt
$ sudo mv cacert.pem curl-ca-bundle.crt
Related
I haven't been able to find a definition for this error in relation to codesigning. I'm really quite stumped as of what to do.
The error occurs when attempting to execute this command line:
codesign -s "Developer ID Application: Name (ID)" -fv --deep Application.app/
System:
XCode 6.2 on Yosemite 10.10.3
I've reinstalled XCode, still without any luck. This is for a desktop application.
Apologies if this is a silly question!
A solution I found on the Apple forum worked for me: first, run the following command to find your identity's hex ID:
$ security find-identity -v
1) A048017A43F8C9C993128B0101B81CD07049601E "lldb_codesign"
...
Then you can use that hex identifier to sign:
codesign -s A048017A43F8C9C993128B0101B81CD07049601E /usr/local/bin/gdb
Some other tips I came across while debugging this:
You have to give the full path to the binary (/usr/local/bin/gdb, not just gdb). It won't look on the PATH, I assume for security reasons.
You have to run the codesign as root if the directory your binary is in is not user-owned.
passing --timestamp=none seems to make the crash go away. In this case, check the network settings, codesign may be unable to reach e.g. the timeserver.
I've encountered this in Xcode 8.3.2 when I inadvertently wound up with duplicates of my signing certificates. #kristina's answer gave me the clue; $ security find-identity -v showed me two entries with identical hashes. I fixed it by deleting the first certificate in the list with that hash, via:
$ sudo security delete-certificate -Z <SHA hash>
I had the same problem. For me the reason was that I wasn't connected to internet, so probably it was trying to connect a time server because of --timestamp, and it failed.
Restoring an internet connection solved it.
I'm trying to find a way to integrate Kirby CMS with Dropbox running on Openshift using these tutorials:
http://getkirby.com/blog/kirby-meets-dropbox
http://getkirby.com/forum/how-to/topic:561
I already get stuck installing Dropbox, since I assume I don't really have permission while SSHing:
http://www.dropbox.com/install?os=lnx
So my question: Is there even any way of achieving all that greatness? If no, not even if we get reaaaally creative? If NO, why not? If yes, how?
Thanks a bunch!
I have no experience with Kirby, but here's how to get Dropbox working on Openshift.
The following is a combination of doing a Dropbox install on a server and doing it in a non-standard location. Everything gets done in $OPENSHIFT_DATA_DIR because that's where you have write privileges.
First, make sure you're in $OPENSHIFT_DATA_DIR
cd $OPENSHIFT_DATA_DIR
Next, download the appropriate version of Dropbox:
wget -O - "https://www.dropbox.com/download?plat=lnx.x86" | tar xzf -
This should give you the .dropbox-dist folder in $OPENSHIFT_DATA_DIR.
Next, tell Dropbox to start the installation process, but tell it that your home directory is actually the $OPENSHIFT_DATA_DIR:
HOME=$OPENSHIFT_DATA_DIR ./.dropbox-dist/dropboxd start -i
Follow the instructions to link your Dropbox account to the Openshift server. After it's linked, it should start syncing everything in your Dropbox account to $OPENSHIFT_DATA_DIR/Dropbox. This might be a bad thing for you because you have too much data in your Dropbox account. If so, then you should exclude folders.
You can do that with the CLI script that Dropbox provides. Still in $OPENSHIFT_DATA_DIR, download it:
wget -O dropbox.py "https://www.dropbox.com/download?dl=packages/dropbox.py"
Make sure it's executable:
chmod +x dropbox.py
You need to run it the same way you would Dropbox:
HOME=$OPENSHIFT_DATA_DIR $OPENSHIFT_DATA_DIR/dropbox.py -h
Hope that helps.
You should be able to download/compile/install things into your OPENSHIFT_DATA_DIR (app-root/data) on your gear by using something like ./configure --prefix=~/app-root/data/dropbox, i tried that but i ran into missing the nautilus-whatever package, which i assume you could download and install in the same fashion, but i did not try past that point. As long as whatever you are running can be installed into the app-root/data, and does not require root permissions to run, you should be able to do it. If you get it going, you could also create a downloadable cartridge to run install it more easily.
I get the following error running curl https://npmjs.org/install.sh | sh on Mac OSX 10.9 (Mavericks):
install npm#latest
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html
How do I fix this?
First off, you should be wary of urls that throw SSL errors. That being said, you can suppress certificate errors in curl with
curl -k https://insecure.url/content-i-really-really-trust
Using the Safari browser (not Chrome, Firefox or Opera) on Mac OS X 10.9 (Mavericks) visit https://registry.npmjs.org
Click the Show certificate button and then check the checkbox labelled Always trust. Then click Continue and enter your password if required.
Curl should now work with that URL correctly.
NOTE: This answer obviously defeats the purpose of SSL and should be used sparingly as a last resort.
For those having issues with scripts that download scripts that download scripts and want a quick fix, create a file called ~/.curlrc
With the contents
--insecure
This will cause curl to ignore SSL certificate problems by default.
Make sure you delete the file when done.
UPDATE
12 days later I got notified of an upvote on this answer, which made me go "Hmmm, did I follow my own advice remember to delete that .curlrc?", and discovered I hadn't. So that really underscores how easy it is to leave your curl insecure by following this method.
The problem is an expired intermediate certificate that is no longer used and must be deleted. Here is a blog post from Digicert explaining the issue and how to resolve it.
https://blog.digicert.com/expired-intermediate-certificate/
I was seeing the issue with Github not loading via SSL in both Safari and the command line with git pull. Once I deleted the old expired cert everything was fine.
After updating to OS X 10.9.2, I started having invalid SSL certificate issues with Homebrew, Textmate, RVM, and Github.
When I initiate a brew update, I was getting the following error:
fatal: unable to access 'https://github.com/Homebrew/homebrew/': SSL certificate problem: Invalid certificate chain
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master
I was able to alleviate some of the issue by just disabling the SSL verification in Git. From the console (a.k.a. shell or terminal):
git config --global http.sslVerify false
I am leary to recommend this because it defeats the purpose of SSL, but it is the only advice I've found that works in a pinch.
I tried rvm osx-ssl-certs update all which stated Already are up to date.
In Safari, I visited https://github.com and attempted to set the certificate manually, but Safari did not present the options to trust the certificate.
Ultimately, I had to Reset Safari (Safari->Reset Safari... menu). Then afterward visit github.com and select the certificate, and "Always trust" This feels wrong and deletes the history and stored passwords, but it resolved my SSL verification issues. A bittersweet victory.
On MacOS High Sierra/10.13:
~$brew install curl ca-certificates
works like a charm for me.
Another cause of this can be duplicate keys in your KeyChain. I've seen this problem on two macs where there were duplicate "DigiCert High Assurance EV Root CA". One was in the login keychain, the other in the system one. Removing the certificate from the login keychain solved the problem.
This affected Safari browser as well as git on the command line.
Let's say you try to download something using curl or install hub
using brew, then, you get an error like:
==> Downloading https://ghcr.io/v2/linuxbrew/core/ncurses/manifests/6.2
curl: (60) SSL certificate problem: unable to get local issuer certificate
Then, let ghcr.io being the server, execute following commands:
cd ~
# Download the cert:
openssl s_client -showcerts -servername ghcr.io -connect ghcr.io:443 > cacert.pem
# type "quit", followed by the "ENTER" key / or Ctrl+C
# see the data in the certificate:
openssl x509 -inform PEM -in cacert.pem -text -out certdata-ghcr.io.txt
# move the file to certificate store directory:
sudo mv cacert.pem /usr/local/share/ca-certificates/cacert-ghcr.io.crt
# update certificates
sudo update-ca-certificates
# done !
References
SSL Certificate Verification
Snippet
After attempting all of the above solutions to eliminate the "curl: (60) SSL certificate problem: unable to get local issuer certificate" error, the solution that finally worked for me on OSX 10.9 was:
Locate the curl certificate PEM file location
'curl-config --ca' -- > /usr/local/etc/openssl/cert.pem
Use the folder location to identify the PEM file
'cd /usr/local/etc/openssl'
Create a backup of the cert.pem file
'cp cert.pem cert_pem.bkup'
Download the updated Certificate file from the curl website
'sudo wget http://curl.haxx.se/ca/cacert.pem'
Copy the downloaded PEM file to replace the old PEM file
'cp cacert.pem cert.pem'
This is a modified version of a solution posted to correct the same issue in Ubuntu found here:
https://serverfault.com/questions/151157/ubuntu-10-04-curl-how-do-i-fix-update-the-ca-bundle
I started seeing this error after installing the latest command-line tools update (6.1) on Yosemite (10.10.1). In this particular case, a reboot of the system fixed the error (I had not rebooted since the update).
Mentioning this in case anyone with the same problem comes across this page, like I did.
In some systems like your office system, there is sometimes a firewall/security client that is installed for security purpose. Try uninstalling that and then run the command again, it should start the download.
My system had Netskope Client installed and was blocking the ssl communication.
Search in finder -> uninstall netskope, run it, and try installing homebrew:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
PS: consider installing the security client.
If you are behind a corporate firewall like Palo Alto it will intercept all TLS/SSL traffic, inspect it and re-encrypt it using its own using self-signed certificates. Although these certificates will typically be available on your workstation, the various programs like npm, Git, curl, etc. will not inherit them from the workstation.
If you are working in an enterprise do not use the -k or --insecure option because this turns of the TLS/SSL encryption completely and opens up you and your organization to compromise
The solution is to add this self signed certificate to the specific certificate chain that is used by the program you are trying to use. I have included a link to Adrian Escutia Soto's answer which is the best way of addressing this. Unfortunately, I cannot comment or upvote on it because I don't have enough reputation points
Sorry for the dumb question, but I've been getting this on Xcode. I'm not sure if it's because I updated to Mountain Lion or not. Every time I click continue, I just get the same message and it never proceeds. I am able to pull or push from the command line however. Does anyone know how to solve this? Thanks!
Just click "Show Certificate", unfold the disclosure arrow and set the "Trust" dropdown option menu to "Always Trust". Accept and re-enter your password if asked. It should be fine now. (Sorry for not being more precise, but I don't have the Certificate window under my eyes right now.)
None of the certificates in the CA chain for GitHub appears to have just expired or be closed to expire.
This article (on rail app, but also relevant here) suggests:
install MacPorts
use OpenSsl
if have a directory /opt/local/etc/openssl:
$ cd /opt/local/etc/openssl
$ sudo curl -O http://curl.haxx.se/ca/cacert.pem
$ sudo mv cacert.pem cert.pem
$ setenv SSL_CERT_FILE /opt/local/etc/openssl/cacert.pem
Anyone facing this issue, quit your proxy and try again.
Background:
I've just replaced my hard drive, and done a fresh install of Lion. I installed git from source and make test seemed fine. SSH keys are loaded and I can ssh into the remote box without problem.
Problem:
I get the following error when trying to pull over ssh when using scp style syntax:
$ git pull origin master
git-upload-pack: error while loading shared libraries: libcrypto.so.0.9.7: cannot open shared object file: No such file or directory
My .git/config for origin looks like this:
[remote "origin"]
url = me#example.com:some_repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
If I change the url to ssh://me#example.com/path/to/some/repo.git it works fine.
I recognize that I could just change all my urls to that format, but I'd rather have a system that works correctly without having to work around setup issues every time.
I was able to push and pull to this repo just fine before reinstalling lion, and I still can with the different syntax. I suspect I symlinked something to work around this on the old hard drive way back in the snow-leopard days, but I'm having a hell of a time googling what it was. I found one post that suggested the problem was a missing library server-side and the error message was misleading, but this can't be the case because it worked just fine on the old hard-drive, and it works just fine with the ssh:// syntax
Anyone know how to address this?
Try to use dtrace to figure out what git it up to. Run this in another terminal and then run git pull as usual.
$ sudo dtrace -qn 'syscall::execve:entry { printf("%s\n", copyinstr(arg0)); }'
/usr/bin/uname
/usr/libexec/git-core/git
... Cut ...
/usr/libexec/git-core/git-pull
/usr/libexec/git-core/ssh
/usr/bin/ssh
Use otool -L /usr/bin/ssh to see if some library is missing.
But while writing this it think your problem might be on the server side. If you instead of my dtrace one-liner run sudo newproc.d while running git pull you will see something like this:
58694 64b ssh me#example.com git-upload-pack 'some_repo.git'
Which indicates that the error might be from git-upload-pack when it is executed on the server side. So take a look at the dynamic libraries used by git-upload-pack on the server.
Try to run ssh me#example.com 'ldd $(which git-upload-pack)' and look for something fishy. Does git-upload-pack work from the shell?