Our production (Heroku) and development (local) instances have been working when accessing a https endpoint. However, within the past 2 days, we started getting the dreaded OpenSSL error:
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
I've read through a lot of OpenSSL failed posts on StackOverflow and http://railsapps.github.io/openssl-certificate-verify-failed.html.
I have updated to the latest OpenSSL and confirmed it by running the following:
ruby -ropenssl -e 'p OpenSSL::OPENSSL_VERSION'
"OpenSSL 1.0.1e 11 Feb 2013"
However, I'm still getting this error:
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
when I call hash = JSON.parse(open(_url).read) where the _url points to a https endpoint.
I don't seem to have problems accessing some providers. For example, when I issue: curl -I https://d2chzxaqi4y7f8.cloudfront.net/gems/rake-0.9.2.2.gem, it seems to work.
I also tried this in irb and it seems to work:
require 'open-uri'
open 'https://google.com'
=> #<File:/var/folders/dv/s_2dq32n0ggcn65kn61jtmc80000gn/T/open-uri20130630-887-y2cg2q>
Is this something the endpoint provider needs to fix or something with my local and production implementation of OpenSSL?
A certificate verification failure indicates that your Ruby instance was unable to find a way to chain the endpoint's certificate up to a trusted root that it is aware of. This can be a few different things:
The endpoint may have changed certificate providers and their new source is not in the default trust tore.
The endpoint may not have the proper intermediates installed.
The endpoint may have an untrusted certificate on it.
To narrow it down you can try loading the endpoint via a web browser. Do you get an untrusted error then? If so, time to contact your provider. If not, you'll need to look at the certificate and see what root it's using. Then you'll want to add that to the Ruby list of trusted certs (which is sourced differently depending on how you compiled it and on what platform).
Related
Having problems installing PayPalCommerce in OpenCart,
After installing and trying to connect to PayPal I get this error!
"(60) SSL peer certificate or SSH remote key was not OK"
As anybody else come across problem as the server certs are just fine?
As Stated Server Certificats are fine, was thinking of changing the Curl SSL Veerify to False but that would defeat the whole purpose. And as the latest Security 1.2 (whatever abrevation).
Update your certificate authority bundle so that your HTTPS connection to the PayPal API endpoint can verify the connection is trusted.
One can be downloaded here, among other places.
If your attempted connection is using a specific certificate file rather than a CA bundle, delete the old certificate and either obtain the endpoint's current one to use instead or use CA verification of it
I am installing Chef Server version 12.8.0-1 on Debian 8.5.
By downloading the .deb package files direct from the chef.io website I have successfully got the chef-server and chef-manage modules installed, configured and running.
I have got stuck trying to install the push jobs server. I used the command below...
chef-server-ctl install opscode-push-jobs-server
when the command runs I get the following errors...
Chef Client failed. 0 resources updated in 06 seconds
[2016-07-12T12:02:23+01:00] FATAL: Stacktrace dumped to /var/opt/opscode/local-mode-cache/chef-stacktrace.out
[2016-07-12T12:02:23+01:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2016-07-12T12:02:24+01:00] FATAL: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed
I believe the cause of the problem is a self signed certificate used on our corporate firewall to allow the security team to decode SSL traffic.
What I need to know is how to either get Chef to accept this certificate or get it to ignore self signed certs.
I know I could manually download and install the module but this issue will affect other things like installing cookbooks from the Chef supermarket so I'd rather find a solution that lets me use the Chef tools as intended.
Can anyone advise please?
Tensibai gave you the path for fixing Chef Server, you'll probably need to do it for the client too which is fortunately easier. Just drop the extra root cert in /etc/chef/trusted_certs.
I am setting up Chef workstation by configuring knife.rb using "knife configure -i" configure command. After PROPERLY answering all question, I get the following error :
ERROR: SSL Validation failure connecting to host: 172.xx.x.xx - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
ERROR: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
My goal is to disable this SSL certificate verification forever and use knife utility to bootstrap my all nodes.
I had the same issue running chef-client after upgrading to the version 12.xx. Steps to solve:
Pull crt from server. Run on node:
knife ssl fetch -s https://yourchefserver01.com:443
Note: If fetch doesnt work copy from yourchefserver01.com:/var/opt/chef-server/nginx/ca/yourchefserver01.com.crt to client:/root/.chef/trusted_certs/yourchefserver01.com.crt
Verify it pulled:
knife ssl check -s https://yourchefserver01.com:443
export SSL_CERT_FILE="/root/.chef/trusted_certs/yourchefserver01.com.crt"
Run chef-client
Your problem is the validation of the chef server certificate.
Install a proper certificate on the chef server
or add your chef server certificate (located in /etc/chef-server/hostname.crt) to your workstation cacert.pem (located by default in <install path>/opscode/chef/embedded/ssl/certs).
With chef 12 you'll have to ditribute it too on your nodes to validate the chef API server or you'll have a warning at the start of each chef-client run about it.
Issue seems to be concerned with the .pem validator. your validation are misconfigured. Try create new validation key from chef server and place it under the node.
If you are running Chef Server on-premise, it will easier in the long run to install a third-party SSL cert, e.g. Verisign, on the Chef Server (or load balancer). chef-client and knife come with OpenSSL which will trust a valid third-party cert automatically with no configuation required on each node.
Please don't turn off SSL cert validation. SSL validation is additional protection that the server you are trusting with root access to your Chef nodes is the real Chef server, not a man-in-the-middle attack.
I've tried to build a master/agent system with puppet.
My master host name is snspay.cn, I followed the document, and everything was right until I tried to get the catalog from the master. My command is
puppet agent --server snspay.cn --no-daemonize --test onetime --verbose
and the output from the agent
Error: Could not request certificate: SSL_connect returned=1
errno=0 state=SSLv3 read server certificate B: certificate verify
failed: [self signed certificate in certificate chain for /CN=Puppet
CA: snspay.cn]
and the master's log is like
[2014-08-11 14:39:14] ERROR OpenSSL::SSL::SSLError: SSL_accept
returned=1 errno=0 state=SSLv3 read client certificate A: tlsv1
alert unknown ca
I think it is wrong with the ssl instead of puppet it self, but I'm not very familiar with ssl, any ideas?
well I have added another agent node(ubuntu) with a total different environment and everything is so well, so the problems is with the original agent node, I am now running yum update in that node and try later
Your agent has not established trust with the master.
What basically needs to happen is for the agent to import the master's CA certificate to the agent. However, since the agent's cert is obviously signed by an obsolete CA, you will have to replace all SSL data.
On the agent, find the $ssldir (usually /var/lib/puppet/ssl) using
puppet agent --configprint ssldir
and rename or remove it.
Upon the next puppet agent --test run, the agent should request a new certificate, and cache th correct CA.
Ruby 2.0, Rails 4.0.2
I have read a number of SO posts about the error I'm getting, and I'm still confused. Here's what I'm trying to do.
I'm running a Rails app on an Ubuntu server: https://rails.example.com. It has a PositiveSSL certificate for the domain from Comodo.
From within that Rails app, I'm trying to post data to a form on another one of my servers: https://api.example.com. It also has a PositiveSSL certificate.
Here's my code:
require 'net/http'
require 'uri'
uri = URI('https://app.pilotpro.com/scripts/migrate.php')
Net::HTTP.start(uri.host, uri.port,
:use_ssl => uri.scheme == 'https') do |http|
request = Net::HTTP::Get.new uri
response = http.request request
logger.info "::: #{response}"
end
This results in this error:
OpenSSL::SSL::SSLError at /test
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed
I don't get any SSL errors when I view these sites in my web browser, but I think I'm supposed to do something to tell my request about the certificate on the API server, but I am unsure.
Can someone give me some direction on what steps I need to take to make this request not fail?
openssl s_client -connect app.pilotpro.com:443 -CApath /etc/ssl/certs/ gives:
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=app.pilotpro.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
That is the complete chain, which means, that your client expects to have PositiveSSL CA 2 as a trusted Root-CA in the CA store. But, this is not the case because this CA is just an intermediate CA so your HTTPS server should send all the intermediate CAs on the path to the trusted Root-CA.
So this is not a client-side, but a server-side problem. See also http://www.positivessl.com/ssl-certificate-support/cert_installation/apache-ssl.php
The reason you get no errors if you access it from browsers might be, that browsers cache intermediate CAs. So if the browser once connected to a host which provided the correct certificate chain it can from now on deal with hosts which omit the needed chain. With firefox you might try access with a fresh browser profile, which does not have any certificates cached.