tag:help.rubygems.org,2010-01-19:/discussions/problems/21968-ssl_verify-has-to-be-set-to-false-due-to-updated-certRubyGems.org: Discussion 2018-12-13T15:12:53Ztag:help.rubygems.org,2010-01-19:Comment/400129372016-06-01T13:17:30Z2016-06-01T13:17:30Zssl_verify has to be set to false due to updated cert?<div><p>Can you provide:<br>
- what platform you are on - what version of Ruby - what version of
RubyGems Also can you try without the proxy? We have often seen
issues where proxies mess with https sites.</p></div>David Radcliffetag:help.rubygems.org,2010-01-19:Comment/400129372016-06-01T13:42:21Z2016-06-01T13:42:23Zssl_verify has to be set to false due to updated cert?<div><p>Hi - here is my gem env output. I cannot try w/o the proxy,
because that is how I get to ruby gems. I don't think this is due
to our proxy however as we have installed a cert for that
particular issue we were hitting, now we are point to point with
our issue(i.e. server to ruby gems)</p>
<p>gem env<br>
RubyGems Environment:<br>
- RUBYGEMS VERSION: 2.6.4 - RUBY VERSION: 2.1.0 (2013-12-25
patchlevel 0) [x86_64-linux] - INSTALLATION DIRECTORY:
/redacted/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0 - USER
INSTALLATION DIRECTORY: /redacted/.gem/ruby/2.1.0 - RUBY
EXECUTABLE: /redacted/.rbenv/versions/2.1.0/bin/ruby - EXECUTABLE
DIRECTORY: /redacted/.rbenv/versions/2.1.0/bin - SPEC CACHE
DIRECTORY: /redacted/.gem/specs - SYSTEM CONFIGURATION DIRECTORY:
/redacted/rbenv/versions/2.1.0/etc - RUBYGEMS PLATFORMS: - ruby -
x86_64-linux - GEM PATHS: -
/redacted/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0 -
/redacted/.gem/ruby/2.1.0 - GEM CONFIGURATION: - :update_sources
=> true - :verbose => true - :backtrace => false -
:bulk_threshold => 1000 - :sources => ["<a href="https://rubygems.org/&quot">https://rubygems.org/&quot</a>;]
- "benchmark" => false - REMOTE SOURCES: - <a href="https://rubygems.org/">https://rubygems.org/</a> - SHELL PATH:
redacted - not necessary</p></div>Dougtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-02T21:02:29Z2016-06-02T21:02:30Zssl_verify has to be set to false due to updated cert?<div><p>I hit the same issue today around 2:10 CST via a Windows EC2
instance in AWS OpsWorks, one of their cookbooks was attempting to
resolve a dependency.<br></p>
<pre>
<code>C:\opscode\chef\embedded\bin>gem env
RubyGems Environment:
- RUBYGEMS VERSION: 2.4.4
- RUBY VERSION: 2.0.0 (2014-02-24 patchlevel 451) [i386-mingw32]
- INSTALLATION DIRECTORY: C:/opscode/chef/embedded/lib/ruby/gems/2.0.0
- RUBY EXECUTABLE: C:/opscode/chef/embedded/bin/ruby.exe
- EXECUTABLE DIRECTORY: C:/opscode/chef/embedded/bin
- SPEC CACHE DIRECTORY: H:/.gem/specs
- SYSTEM CONFIGURATION DIRECTORY: C:/ProgramData
- RUBYGEMS PLATFORMS:
- ruby
- x86-mingw32
- GEM PATHS:
- C:/opscode/chef/embedded/lib/ruby/gems/2.0.0
- H:/.gem/ruby/2.0.0
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- https://rubygems.org/
- SHELL PATH:
- C:\Windows\system32
- C:\Windows
- C:\Windows\System32\Wbem
- C:\Windows\System32\WindowsPowerShell\v1.0\
- C:\Program Files\Amazon\cfn-bootstrap\
- C:\opscode\chef\bin</code>
</pre>
<pre>
<code>[2016-06-02T19:10:42+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: aws_opsworks_scm_checkout<a>custom cookbooks</a> had an error: Mixlib::ShellOut::ShellCommandFailed: s3_file<a>C:/chef/cookbooks/OpsWorks-Deploy.zip</a> had an error: Mixlib::ShellOut::ShellCommandFailed: chef_gem<a>rest-client</a> had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of C:/ProgramData/OpsWorksAgent/71400020160128114716/chef-client/embedded/bin/gem install rest-client -q --no-rdoc --no-ri -v "1.7.3" ----
STDOUT:<br>STDERR: ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError)<br>SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://rubygems.global.ssl.fastly.net/quick/Marshal.4.8/rest-client-1.7.3.gemspec.rz)
---- End output of C:/ProgramData/OpsWorksAgent/71400020160128114716/chef-client/embedded/bin/gem install rest-client -q --no-rdoc --no-ri -v "1.7.3" ----
Ran C:/ProgramData/OpsWorksAgent/71400020160128114716/chef-client/embedded/bin/gem install rest-client -q --no-rdoc --no-ri -v "1.7.3" returned 1</code>
</pre></div>jaredtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-03T14:57:57Z2016-06-03T14:57:57Zssl_verify has to be set to false due to updated cert?<div><p>I have a hunch this is due to open ssl upgrades on
rubygems.global.ssl.fastly.net.</p>
<p>My setup all worked for a few years until a few months or so ago
and this issue popped up. Since upgrading openssl on my side(client
side) isn't really an option right now to perhaps resolve the
mismatching, I think that is why I am where I am at and had to use
:ssl_verify_mode: 0 in my .gemrc.</p>
<p>I haven't been able to confirm rubygems.global.ssl.fastly.net
was upgraded os wise/open ssl wise, etc - but would be nice to know
one way or another why this stopped working.</p></div>Dougtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-03T15:04:40Z2016-06-03T15:04:40Zssl_verify has to be set to false due to updated cert?<div><p>I will say that after retrying a little later yesterday, I
didn't encountering this issue again.</p>
<p>I'm not sure if maybe it was just resolving to another host or
something, I'll see if I can find any other information.</p></div>jaredtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-03T17:23:27Z2016-06-03T17:23:27Zssl_verify has to be set to false due to updated cert?<div><p>If this comes up again, can you get a log of the handshake?</p>
<pre>
<code>openssl s_client -host rubygems.global.ssl.fastly.net -port 443</code>
</pre></div>Eric Hodeltag:help.rubygems.org,2010-01-19:Comment/400129372016-06-03T19:42:50Z2016-06-03T19:42:51Zssl_verify has to be set to false due to updated cert?<div><p>do you have another way to do that, not through openssl command?
I need to pass a proxy to openssl, but the version of openssl I
have does not support -proxy.</p></div>Dougtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-03T21:43:32Z2016-06-03T21:43:32Zssl_verify has to be set to false due to updated cert?<div><p>Looks like proxytunnel is the way to go:</p>
<p><a href="http://stackoverflow.com/questions/3220419/openssl-s-client-using-a-proxy#answer-22504506">
http://stackoverflow.com/questions/3220419/openssl-s-client-using-a...</a></p></div>Eric Hodeltag:help.rubygems.org,2010-01-19:Comment/400129372016-06-05T17:48:42Z2016-06-05T17:48:43Zssl_verify has to be set to false due to updated cert?<div><p>So this happened again. Using the command you said (with the
cacert file that Chef is using)</p>
<pre>
<code>openssl s_client -host rubygems.global.ssl.fastly.net -port 443 -CAfile "C:\opscode\chef\embedded\ssl\certs\cacert.pem"</code>
</pre>
<p>I get a valid response back <em>most</em> of the the time.</p>
<pre>
<code>C:\Users\USERNAME\Desktop\OpenSSL\bin>openssl s_client -host rubygems.global.ssl.fastly.net -port 443 -CAfile "C:\opscode\chef\embedded\ssl\certs\cacert.pem"
Loading 'screen' into random state - done
CONNECTED(00000164)
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
verify return:1
depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
verify return:1
depth=0 /C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=a.ssl.fastly.net
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=a.ssl.fastly.net
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIL6TCCCtGgAwIBAgIQBigdNnW0H8yz/xj67Pj93zANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xNDEyMDgwMDAwMDBaFw0xODAyMDYxMjAwMDBa
MGwxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1T
YW4gRnJhbmNpc2NvMRUwEwYDVQQKEwxGYXN0bHksIEluYy4xGTAXBgNVBAMTEGEu
c3NsLmZhc3RseS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU
JUiQsaVP/vC4Mb3aJUmA9KnMQa7EJfjYLsE4F0VehrOp8jlSSXmQLELlUAwPp2F2
PNyB32DDOFBHZIYwFrApFEzsJdTKQUYk6xHPZOdYoIijpmfb5xRMdTjqxThGkk+k
hU0+ipPWiErJNRkapLgPwPD4ctd5X8rnKF8lMHIxx5Xhdg6PqZC3F7y45Nym2a3M
8xIKIkB77o1bkuDpGnV9ZESC/Yf9Mc4NmWrQjqQc+8yIabir+n7/YcM5UdUjZPNS
hgL4jLYVJ+KDRZcjIT/dXRZoPpJgRFL9NIep/eSAzQa3g659uW7tjN6tg5iQm4hw
ksaWp+zfTAJc4IXNtlndAgMBAAGjggiBMIIIfTAfBgNVHSMEGDAWgBRRaP+QrwIH
dTzM2WVkYqISuFlyOzAdBgNVHQ4EFgQUwIj0Y03ka1Q28RLCtKWy4nN7FIgwggax
BgNVHREEggaoMIIGpIIQYS5zc2wuZmFzdGx5Lm5ldIISKi5hLnNzbC5mYXN0bHku
bmV0gg9mYXN0Lndpc3RpYS5jb22CEHB1cmdlLmZhc3RseS5uZXSCEm1pcnJvcnMu
ZmFzdGx5Lm5ldIIOKi5wYXJzZWNkbi5jb22CDSouZmFzdHNzbC5uZXSCCXZveGVy
LmNvbYINd3d3LnZveGVyLmNvbYIOKi5maXJlYmFzZS5jb22CEHNpdGVzLnlhbW1l
ci5jb22CGHNpdGVzLnN0YWdpbmcueWFtbWVyLmNvbYIPKi5za2ltbGlua3MuY29t
ghMqLnNraW1yZXNvdXJjZXMuY29tghBjZG4udGhpbmdsaW5rLm1lggwqLmZpdGJp
dC5jb22CEiouaG9zdHMuZmFzdGx5Lm5ldIISY29udHJvbC5mYXN0bHkubmV0gg8q
Lndpa2lhLWluYy5jb22CFSoucGVyZmVjdGF1ZGllbmNlLmNvbYILKi53aWtpYS5j
b22CEmYuY2xvdWQuZ2l0aHViLmNvbYIVKi5kaWdpdGFsc2Npcm9jY28ubmV0ggoq
LmV0c3kuY29tghAqLmV0c3lzdGF0aWMuY29tgg0qLmFkZHRoaXMuY29tghAqLmFk
ZHRoaXNjZG4uY29tgg9mYXN0Lndpc3RpYS5uZXSCDnJhdy5naXRodWIuY29tgg93
d3cudXNlcmZveC5jb22CEyouYXNzZXRzLXlhbW1lci5jb22CGyouc3RhZ2luZy5h
c3NldHMteWFtbWVyLmNvbYIWYXNzZXRzLmh1Z2dpZXMtY2RuLm5ldIISb3JiaXQu
c2hhemFtaWQuY29tgg9hYm91dC5qc3Rvci5vcmeCFyouZ2xvYmFsLnNzbC5mYXN0
bHkubmV0gg13ZWIudm94ZXIuY29tgg9weXBpLnB5dGhvbi5vcmeCCyouMTJ3YnQu
Y29tghJ3d3cuaG9sZGVyZGVvcmQubm+CGnNlY3VyZWQuaW5kbi5pbmZvbGlua3Mu
Y29tghBwbGF5LnZpZHlhcmQuY29tghhwbGF5LXN0YWdpbmcudmlkeWFyZC5jb22C
FXNlY3VyZS5pbWcud2ZyY2RuLmNvbYIWc2VjdXJlLmltZy5qb3NzY2RuLmNvbYIQ
Ki5nb2NhcmRsZXNzLmNvbYIVd2lkZ2V0cy5waW50ZXJlc3QuY29tgg4qLjdkaWdp
dGFsLmNvbYINKi43c3RhdGljLmNvbYIPcC5kYXRhZG9naHEuY29tghBuZXcubXVs
YmVycnkuY29tghJ3d3cuc2FmYXJpZmxvdy5jb22CEmNkbi5jb250ZW50ZnVsLmNv
bYIQdG9vbHMuZmFzdGx5Lm5ldIISKi5odWV2b3NidWVub3MuY29tgg4qLmdvb2Rl
Z2dzLmNvbYIWKi5mYXN0bHkucGljbW9ua2V5LmNvbYIVKi5jZG4ud2hpcHBsZWhp
bGwubmV0ghEqLndoaXBwbGVoaWxsLm5ldIIbY2RuLm1lZGlhMzQud2hpcHBsZWhp
bGwubmV0ghtjZG4ubWVkaWE1Ni53aGlwcGxlaGlsbC5uZXSCG2Nkbi5tZWRpYTc4
LndoaXBwbGVoaWxsLm5ldIIcY2RuLm1lZGlhOTEwLndoaXBwbGVoaWxsLm5ldIIO
Ki5tb2RjbG90aC5jb22CDyouZGlzcXVzY2RuLmNvbYILKi5qc3Rvci5vcmeCDyou
ZHJlYW1ob3N0LmNvbYIOd3d3LmZsaW50by5jb22CDyouY2hhcnRiZWF0LmNvbYIN
Ki5oaXBtdW5rLmNvbYIaY29udGVudC5iZWF2ZXJicm9va3MuY28udWuCG3NlY3Vy
ZS5jb21tb24uY3Nuc3RvcmVzLmNvbYIOd3d3LmpvaW5vcy5jb22CJXN0YWdpbmct
bW9iaWxlLWNvbGxlY3Rvci5uZXdyZWxpYy5jb22CDioubW9kY2xvdGgubmV0ghAq
LmZvdXJzcXVhcmUuY29tggwqLnNoYXphbS5jb22CCiouNHNxaS5uZXSCDioubWV0
YWNwYW4ub3JnggwqLmZhc3RseS5jb22CCXdpa2lhLmNvbYIKZmFzdGx5LmNvbYIR
Ki5nYWR2ZW50dXJlcy5jb22CFnd3dy5nYWR2ZW50dXJlcy5jb20uYXWCFXd3dy5n
YWR2ZW50dXJlcy5jby51a4IJa3JlZG8uY29tghZjZG4tdGFncy5icmFpbmllbnQu
Y29tghRteS5iaWxsc3ByaW5nYXBwLmNvbYIGcnZtLmlvMA4GA1UdDwEB/wQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKg
MIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItaGEtc2VydmVyLWc1LmNy
bDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItaGEtc2VydmVy
LWc1LmNybDBMBgNVHSAERTBDMDcGCWCGSAGG/WwBATAqMCgGCCsGAQUFBwIBFhxo
dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAgGBmeBDAECAjCBgwYIKwYBBQUH
AQEEdzB1MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wTQYI
KwYBBQUHMAKGQWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNI
QTJIaWdoQXNzdXJhbmNlU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZI
hvcNAQELBQADggEBAKLWzbX7wSyjzE7BVMjLrHAaiz+WGSwrAPrQBJ29sqouu9gv
I7i2Ie6eiRb4YLMouy6D+ZNZ+RM+Hkjv+PZFxCcDRmaWi+74ha5d8O155gRJRPZ0
Sy5SfD/8kqrJRfC+/D/KdQzOroD4sx6Qprs9lZ0IEn4CTf0YPNV+Cps37LsVyPJL
fjDlGIM5K3B/vtZfn2f8buQ9QyKiN0bc67GdCjih9dSrkQNkxJiEOwqiSjYtkdFO
dYpXF8d1rQKV7a6z2vJloDwilfXLLlUX7rA3qVu7r4EUfIsZgH7hgB4bbst7tx+7
PgUEq2334kKPVFpsxgsj5++k4lh7tNlakXiBUtw=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Francisco/O=Fastly, Inc./CN=a.ssl.fastly.net
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
---
No client certificate CA names sent
---
SSL handshake has read 4423 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: 30A567D2011AAAD9DD36C15E959E9A455DB3694EF5DE80506B2FFBB042280FBD
Session-ID-ctx:
Master-Key: 40D3DBD64053551CB6B0470BFB2512F027E54BC279086273DD257709DE7DE57A1E368C3413C2F1DBA176BCE40C94620F
Key-Arg : None
Start Time: 1465147021
Timeout : 300 (sec)
Verify return code: 0 (ok)
---</code>
</pre>
<p>Occasionally though, it looks like it's resolving to different
hosts (other than 23.235.40/44.249 which seem to work):<br></p>
<pre>
<code>C:\Users\USERNAME>nslookup
Default Server: <dnsServer>
Address: <dnsServerIP><br><br>
<br>> rubygems.global.ssl.fastly.net
Server: <dnsServer>
Address: <dnsServerIP><br><br>
<br>Non-authoritative answer:
Name: fallback.global-ssl.fastly.net
Addresses: 199.27.76.249
23.235.46.249
Aliases: rubygems.global.ssl.fastly.net
global-ssl.fastly.net<br><br>
<br>> rubygems.global.ssl.fastly.net
Server: <dnsServer>
Address: <dnsServerIP><br><br>
<br>Non-authoritative answer:
Name: fallback.global-ssl.fastly.net
Addresses: 199.27.76.249
23.235.46.249
Aliases: rubygems.global.ssl.fastly.net
global-ssl.fastly.net<br><br>
<br>> rubygems.global.ssl.fastly.net
Server: <dnsServer>
Address: <dnsServerIP><br><br>
<br>Non-authoritative answer:
Name: fallback.global-ssl.fastly.net
Addresses: 23.235.46.249
23.235.39.249
Aliases: rubygems.global.ssl.fastly.net
global-ssl.fastly.net</code>
</pre>
<p>At which point, I get the following error with that command:</p>
<pre>
<code>C:\Users\USERNAME\Desktop\OpenSSL\bin>openssl s_client -host rubygems.global.ssl.fastly.net -port 443 -CAfile C:\opscode\chef\embedded\ssl\certs\cacert.pem
Loading 'screen' into random state - done
CONNECTED(00000164)
2012:error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version:.\ssl\s23_clnt.c:596:</code>
</pre></div>jaredtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-05T18:43:35Z2016-06-05T18:43:35Zssl_verify has to be set to false due to updated cert?<div><p>RubyGems bundles it's own certs, so you shouldn't be using or
testing with<br>
the Chef certs.</p>
<hr>
<p>David Radcliffe</p></div>David Radcliffetag:help.rubygems.org,2010-01-19:Comment/400129372016-06-10T12:06:05Z2016-06-10T12:06:08Zssl_verify has to be set to false due to updated cert?<div><p>looks like there is a local issuer certificate for some
reason...</p>
<p>proxytunnel -p notimportant:8080 -d
rubygems.global.ssl.fastly.net:443 -a 7000 & openssl s_client
-showcerts -connect localhost:7000<br>
[1] 4733 CONNECTED(00000003)<br>
depth=2 /CN=Cisco Umbrella Primary SubCA/O=Cisco<br>
verify error:num=20:unable to get local issuer certificate</p>
<h2><a name="verify-return-0-" href="#verify-return-0-" class="anchor"></a>verify
return:0</h2></div>Dougtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-10T12:07:06Z2016-06-10T12:07:06Zssl_verify has to be set to false due to updated cert?<div><p>That's probably related to your proxy.</p></div>David Radcliffetag:help.rubygems.org,2010-01-19:Comment/400129372016-06-10T16:22:26Z2016-06-10T16:22:27Zssl_verify has to be set to false due to updated cert?<div><p>were the rubygems.global.ssl.fastly.net servers updated recently
OS wise, ssl wise, etc?</p></div>Dougtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-10T16:39:38Z2016-06-10T16:39:38Zssl_verify has to be set to false due to updated cert?<div><p>My problem ended up being that HTTPS inspection wasn't completed
turned off on our Checkpoint firewall, so we were presented with a
self-signed cert that was not trusted. Not sure why it was
intermittent though.</p></div>jaredtag:help.rubygems.org,2010-01-19:Comment/400129372016-06-10T17:30:43Z2016-06-10T17:30:43Zssl_verify has to be set to false due to updated cert?<div><p>rubygems.global.ssl.fastly.net is an alias to the <a href="https://www.fastly.com">Fastly CDN</a>. Since they're running at
2.6 million requests/second right now I'm fairly certain they would
notice and fix SSL issues on their end quickly.</p></div>Eric Hodel