Last Friday I started seeing issues (on an environment that has been live for months) this issue on ruby on this docker image:
RestClient::SSLCertificateNotVerified: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
I then proceeded trying adding a custom PEM (wget https://curl.se/ca/cacert.pem) to link in the environment variable SSL_CERT_FILE (as explained in many other stack overflow questions).
but I get:
bash-4.4# wget https://curl.se/ca/cacert.pem
Connecting to curl.se (151.101.2.49:443)
ssl_client: curl.se: certificate verification failed: certificate has expired
wget: error getting response: Connection reset by peer
I tried saving the file on my local machine then docker cp it to the container, but that didn't help either.
I tried running the console with:
bash-4.4# SSL_CERT_FILE=/cacert.pem bundle exec rails c
irb(main):001:0> RestClient.get('https://curl.se/ca/cacert.pem', headers={})
RestClient.get "https://curl.se/ca/cacert.pem", "Accept"=>"*/*", "Accept-Encoding"=>"gzip, deflate", "User-Agent"=>"rest-client/2.0.2 (linux-musl x86_64) ruby/2.3.8p459"
RestClient::SSLCertificateNotVerified: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
I tried running update-ca-certificates both manually in the console, and in the dockerfile, but I get:
bash-4.4# update-ca-certificates
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
When I tried this with the cacert.pem copied to the container as above, update-ca-certificates added a warning to that file too, similar to the ca-certificates.crt one.
the issue doesn't seem to improve with anything.
running
curl -Lks 'https://git.io/rg-ssl' | ruby
say it's all ok, and all (3) green checks
any ideas?
Thanks.
update
I think this issue might be related to lets encrypt expiring their root certificate, I tried the first workaround they recommend, by deleting the file on a container, and also deleting it on the dockerfile, then running update-ca-certificates this didn't help either. I'm not sure how to go about the other two workarounds.
If you are on debian 9, I would recommend you to update it. Otherwise, this is my workaround solution for my image.
# Temporarily fix wrong let's encrypt R3 chain because it's chained to an expired old root CA (DST Root CA X3) on debian 9
RUN sed -i -E 's/(.*DST_Root_CA_X3.*)/!\1/' /etc/ca-certificates.conf
ADD https://letsencrypt.org/certs/isrgrootx1.pem /usr/local/share/ca-certificates/isrgrootx1.pem
RUN update-ca-certificates
FYI: there is a bug on OpenSSL 1.0.2g that causes the issue https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ some platforms have released the workaround fix and you just need to upgrade latest ca-certificates and latest libgnutls30. It would be better if you can upgrade to a more recent OpenSSL.
A way to fix the issue would be to run on the container's console:
apt update && apt install ca-certificates
However, this would be a Docker antipattern, as the changes would be lost when at the container deletion.
The better way would be to rebuild the image from the Dockerfile that you have linked in your question (with docker build), then deleting and recreating the container from the new image.
Related
Hello so I am trying to install a vagrant plugin but I getting the following error in mingW64
$ vagrant plugin install vagrant-winnfsd
Installing the 'vagrant-winnfsd' plugin. This can take a few minutes...
Vagrant failed to load a configured plugin source. This can be caused
by a variety of issues including: transient connectivity issues, proxy
filtering rejecting access to a configured plugin source, or a configured
plugin source not responding correctly. Please review the error message
below to help resolve the issue:
SSL_connect returned=1 errno=0 state=error: certificate verify failed (https://api.rubygems.org/specs.4.8.gz)
Source: https://rubygems.org/
I am behind a firewall and have to pass the company cert manually. I updated my Ruby certs but still no luck. Anyone have any clue why vagrant is not taking my pem/certs?
Well funny thing. Vagrant uses its own certs. Inside of its folder:
the path is: C:\HashiCorp\Vagrant\embedded\cacert.cert on windows.
Add your company cert and you should be good to go.
I solved my own issue. Hopefully this helps someone else.
I'm trying to build a Docker image from a Dockerfile. The image is based on the latest node:alpine image. It installs Ruby and a few gems on top of it. Here is the Dockerfile:
FROM node:alpine
ENV BUNDLE_SILENCE_ROOT_WARNING=1 BUNDLE_APP_CONFIG=/usr/local/bundle \
BUNDLE_BIN=/usr/local/bundle/bin BUNDLE_PATH=/usr/local/bundle
RUN apk add ruby ruby-io-console ruby-bundler ca-certificates \
build-base ruby-dev ruby-json libffi-dev \
python zlib-dev --no-cache && \
update-ca-certificates
WORKDIR /opt/middleman
COPY Gemfile* ./
RUN bundle install --clean
COPY package.json ./
RUN npm install
I can build the image on Linux and MacOS, but on Windows bundler fails randomly, on a different gem every time, with the following message:
Gem::RemoteFetcher::FetchError: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A (https://rubygems.org/gems/rack-2.0.1.gem)
I've googled the SSL error and most solutions suggest installing some SSL certificates. However, in my case the base Docker image is the same. Only the Docker host OS is different. And if the problem were the SSL certs, bundler would always fail on the first gem not a random one each time. So my guess is there's something wrong when Docker runs on Windows, but I have run out of ideas. Any help?
PS: I've made sure that all machines have the same snapshot of node:alpine which happens to be this:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
node alpine 37434f668ea8 30 hours ago 55.3 MB
Update:
I also tried building the quick-start Rails image and it fails.
I tried building the quick-start image with the older Docker Toolbox which uses VirtualBox instead of Hyper-V. It failed again, each time on a different gem, but the error is now different:
Gem::RemoteFetcher::FetchError: Errno::ECONNRESET: Connection reset by peer - SSL_connect (https://rubygems.org/gems/minitest-5.10.1.gem)
Still an SSL error, though.
Thanks for all your comments. I finally found the culprit. It's a "feature" of my Killer Wireless card... For future reference, I had to disable "Advanced Stream Detect" in the "Killer Network Manager" app. Here's a screenshot:
They should probably call it SSL killer.
I am trying to install SonarQube server on Ubuntu14.04 system.
When I do
wget https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-5.3.zip
i am getting certificate error which says
ERROR: cannot verify akamai.bintray.com's certificate, issued by ‘/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2’:
Unable to locally verify the issuer's authority.
I have tried installing the certificate using openssl, still I am unable to get the binaries. I have also updated the ca-certificates using update-ca-certificates, but with no luck.
Can anyone help me on this?
As a workaround:
https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-5.3.zip
redirects to
https://akamai.bintray.com/4e/4e61ee3a01d5e447bcd64357df77e0377325c4a2bb5ceb2cdeb5a5d193443ba5?__gda__=exp=1471600642~hmac=2b041a2929611ac66b6e703c87e0f08a939a5f4cf7a2b9ffa2d7ba3e5a2d7f3e&response-content-disposition=attachment%3Bfilename%3D%22sonarqube-5.3.zip
which seems to be available over HTTP.
So you can try:
wget "http://akamai.bintray.com/4e/4e61ee3a01d5e447bcd64357df77e0377325c4a2bb5ceb2cdeb5a5d193443ba5?__gda__=exp=1471600642~hmac=2b041a2929611ac66b6e703c87e0f08a939a5f4cf7a2b9ffa2d7ba3e5a2d7f3e&response-content-disposition=attachment%3Bfilename%3D%22sonarqube-5.3.zip"
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
For example, running wget https://www.dropbox.com results in the following errors:
ERROR: The certificate of `www.dropbox.com' is not trusted.
ERROR: The certificate of `www.dropbox.com' hasn't got a known issuer.
If you don't care about checking the validity of the certificate just add the --no-check-certificate option on the wget command-line. This worked well for me.
NOTE: This opens you up to man-in-the-middle (MitM) attacks, and is not recommended for anything where you care about security.
Looking at current hacky solutions in here, I feel I have to describe a proper solution after all.
First, you need to install the cygwin package ca-certificates via Cygwin's setup.exe to get the certificates.
Do NOT use curl or similar hacks to download certificates (as a neighboring answer advices) because that's fundamentally insecure and may compromise the system.
Second, you need to tell wget where your certificates are, since it doesn't pick them up by default in Cygwin environment. If you can do that either with the command-line parameter --ca-directory=/usr/ssl/certs (best for shell scripts) or by adding ca_directory = /usr/ssl/certs to ~/.wgetrc file.
You can also fix that by running ln -sT /usr/ssl /etc/ssl as pointed out in another answer, but that will work only if you have administrative access to the system. Other solutions I described do not require that.
If the problem is that a known root CA is missing and when you are using ubuntu or debian, then you can solve the problem with this one line:
sudo apt-get install ca-certificates
May be this will help:
wget --no-check-certificate https://blah-blah.tld/path/filename
First, the SSL certificates need to be installed. Instructions (based on https://stackoverflow.com/a/4454754/278488):
pushd /usr/ssl/certs
curl http://curl.haxx.se/ca/cacert.pem | awk 'split_after==1{n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "cert" n ".pem"}'
c_rehash
The above is enough to fix curl, but wget requires an extra symlink:
ln -sT /usr/ssl /etc/ssl
apt-get install ca-certificates
The s makes the difference ;)
I have the similar problem and fixed it by temporarily disabling my antivirus(Kaspersky Free 18.0.0.405). This AV has HTTPS interception module that automatically self-sign all certificates it finds in HTTPS responses.
Wget from Cygwin does not know anything about AV root certificate, so when it finds that website's certificate was signed with non trust certificate it prints that error.
To fix this permanently without disabling AV you should copy the AV root certificate from Windows certificate store to /etc/pki/ca-trust/source/anchors as .pem file(base64 encoding) and run update-ca-trust
In my case, on raspberry pi 3B the timing was in the future (2025) that I need to update to the current local time using ntpdate by passing the time to the past and it solved the issue.
$ sudo date +%Y%m%d -s "20210101"
$ sudo ntpdate times1.mike.fi
I had a similar problem with wget to my own live web site returning errors after installing a new SSL certificate. I'd already checked several browsers and they didn't report any errors:
wget --no-cache -O - "https://example.com/..." ERROR: The certificate of ‘example.com’ is not trusted. ERROR: The certificate of ‘example.com’ hasn't got a known issuer.
The problem was I had installed the wrong certificate authority .pem/.crt file from the issuer. Usually they bundle the SSL certificate and CA file as a zip file, but DigiCert email you the certificate and you have to figure out the matching CA on your own. https://www.digicert.com/help/ has an SSL certificate checker which lists the SSL authority and the hopefully matching CA with a nice blue link graphic if they agree:
`SSL Cert: Issuer GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1
CA: Subject GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1
Valid from 16/Jul/2020 to 31/May/2023
Issuer DigiCert Global Root CA`
We just had this same issue come up when we installed a newly minted certificate just this last week. I've also seen it two other times...yet I'm slow to learn. In all 3 cases I had to get the "intermediate certificates" and install them. In other words My cert was good but it's signer or it's signer's signer wasn't correctly installed. Make sure you go to your certificate provider's site and get the correct intermediate certificates and install them as well on your server and then this warning will go away.
It might not JUST be the above, it could also be that clients don't have updated lists...but I would make sure it's not just you not fully installing the certificates right FIRST, and then after that going on to the clients and making sure their list is updated.
Not exactly the same issue. On docker, I was mounting my host filesystem to /etc where OpenSSL certs were already installed which gets overwritten.
Changing the mounting to different filesystem fixed it.
Thanks to Denis Bakharev I've solved that case.
If someone has Cygwin wget not working because 'certificate not trusted' and having ca-certificates installed AND having Antivirus that automatically self-sign all certificates it finds in HTTPS responses then you need:
Get root certificate from your AV (I got mine with browser: open any https web-site, check it's certificate, go to Certification Path tab, click on Root certificate. Then click View certificate button, go to Details tab and click Copy to File... button. Default settings are fine for saving certificate in *.cer file).
Convert *.cer to *.crt. You can use Cygwin's OpenSSL with the following command:
openssl x509 -inform DER -in <your *.cer certificate file> -out <new cert>.crt
Move new *.crt file to ca-directory (in my case it was /etc/pki/tls/certs/).
That was enough for me to get wget working.
If you are using windows just go to control panel, click on automatic updates then click on Windows Update Web Site link. Just follow the step. At least this works for me, no more certificates issue i.e whenever I go to https://www.dropbox.com as before.
Just do
apt-get install ca-certificate