Issues verifying certificate connecting with HTTPS

[theodorton]

Crystal version

~/code/nabobil/autotoll · (master±)
⟩ crystal -v
Crystal 0.23.1 (2017-10-12) LLVM 4.0.1

How to reproduce

# test.cr
require "http/client"

client = HTTP::Client.new("maps.googleapis.com", tls: true)
client.get "/"

Then run crystal run test.cr.

Expected outcome

No errors raised, or some redirect.

Actual outcome

SSL_connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (OpenSSL::SSL::Error)
0x10d990e45: *CallStack::unwind:Array(Pointer(Void)) at ??
0x10d990de1: *CallStack#initialize:Array(Pointer(Void)) at ??
0x10d990db8: *CallStack::new:CallStack at ??
0x10d98d615: *raise<OpenSSL::SSL::Error>:NoReturn at ??
0x10da33571: *OpenSSL::SSL::Socket::Client#initialize<TCPSocket, OpenSSL::SSL::Context::Client, Bool, String>:Nil at ??
0x10da333ec: *OpenSSL::SSL::Socket::Client::new:context:sync_close:hostname<TCPSocket, OpenSSL::SSL::Context::Client, Bool, String>:OpenSSL::SSL::Socket::Client at ??
0x10da29c91: *HTTP::Client#socket:(OpenSSL::SSL::Socket+ | TCPSocket+) at ??
0x10da299eb: *HTTP::Client#exec_internal_single<HTTP::Request>:(HTTP::Client::Response | Nil) at ??
0x10da26f7c: *HTTP::Client#exec_internal<HTTP::Request>:HTTP::Client::Response at ??
0x10da26e72: *HTTP::Client#exec<HTTP::Request>:HTTP::Client::Response at ??
0x10da26bdd: *HTTP::Client#exec<String, String, Nil, Nil>:HTTP::Client::Response at ??
0x10da26bb7: *HTTP::Client#get<String>:HTTP::Client::Response at ??
0x10d97bcba: __crystal_main at ??
0x10d98c678: main at ??

Notes

• This also happens when running the code within the official docker image for 0.23.1.
• I've managed to get it to pass randomly, but I believe there is some cipher requirement and that the certificates differ somewhat between the servers behind this domain
• When running openssl s_client -connect maps.googleapis.com:443 -tls1_2 I get:

CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.googleapis.com
verify return:1
---
...
...

• It works if I setup a similar example in Ruby:

require 'net/http'
require 'uri'

uri = URI('https://maps.googleapis.com/')

Net::HTTP.start(uri.host, uri.port, use_ssl: true) do |http|
  request = Net::HTTP::Get.new uri
  response = http.request request # Net::HTTPResponse object
  puts response
end

• In other words, I don't believe this is an issue with my openssl configuration.

[Sija]

Duplicate of #3477.

See also composer/composer#3346 and relevant question on SO.

[theodorton]

I'm not sure, I'm able to connect with TLS to github.com:

HTTP::Client.get("https://github.com/") # This works
HTTP::Client.get("https://maps.googleapis.com/") # This doesn't

I belive there might be something with the allowed cipher suites as SSLLabs Test results for maps.googleapis.com show that the root certificate is insecure.

[asterite]

I face this problem with some URLs. I think it depends on the version of openssl. Ruby ships with one version of openssl and that's very good: reproducible builds and behavior no matter what your system is. In Crystal we dynamically link to the openssl that's present in the system and it leads to these random and hard to reproduce problems (because we have to have your version of openssl in our machines).

I wish we could just ship Crystal with one version of openssl, one version of llvm, one version of libpcre, one version of libxml2, etc., so that everything works exactly the same everywhere...

[RX14]

@asterite And then what if openssl has a security bug? If we distribute our own libraries we are now distro maintainers. We have to follow the security bugs closely with a quick response, and possibly backport patches, and deal with a whole bunch of things we don'y have time to do. This is the distro maintainer's job, not ours, it's already done for us.

I've never had an openssl problem with crystal on archlinux, i've only seem people have problems on osx and on debian-based (read: ancient versions of openssl) distros.

[theodorton]

I don't have any strong opinions on whether to bundle openssl with the compiler or not, but I think this doing VERIFY_NONE as a workaround (which is mentioned in the linked issues) here unsatisfactory.

I tried to use OpenSSL::SSL::Context::Client#add_x509_verify_flags(OpenSSL::SSL::X509VerifyFlags:: TRUSTED_FIRST) which was mentioned as a fix in a Stack Overflow issue I found yesterday. I'm unable to find it again now, but the problem I ran into was that OpenSSL::SSL::X509VerifyFlags was not defined. Seems like there's a compiler flag for that constant that wasn't set.

It seems highly related, but I'm not sure? I'm building Crystal via Homebrew. Could it be that it's missing some SSL/crypto lib while compiling? Or that the compiled bottle comes without this support?

Edit: I'm trying to install from homebrew with --build-from-source to see if that resolves the issue.
Update: No, it doesn't help. I'm still getting undefined constant OpenSSL::OPENSSL_102 errors when attempting to use X509VerifyFlags.

[RX14]

It appears to me that openssl's API is a mess, perhaps we should implement the libtls API using openssl (in C, how openssl wants us to), and then use that as the base for crystal's TLS module and remove OpenSSL.

[theodorton]

The workaround here is:

context = OpenSSL::SSL::Context::Client.insecure
client = HTTP::Client.new("maps.googleapis.com", tls: context)

I'm not sure if that's a very good workaround though, as if I point the client to expired.badssl.com, I'm not getting any errors.

[ysbaddaden]

Hence the insecure: you basically accept whatever OpenSSL supports —I'm not even sure it verifies certificates. Would you be willing to take the Client.insecure and tweak it until you find the culprit in defaults?

[theodorton]

@ysbaddaden Yes, we're ok with Client.insecure for now, but it doesn't seem to verify certificates. I think that should probably be noted in the documentation. Currently the docs say:

Use this only if undoing the defaults that new sets is too much hassle.

Not sure if I can spend more time at the moment looking into the defaults. I'm not very fluent in TLS/SSL terminology so I'd just have to guess what the different options represent. The failures were pretty consistent with that hostname, even when I ran it in the Docker image for 0.23.1.

I still think this is highly relevant:

I'm still getting undefined constant OpenSSL::OPENSSL_102 errors when attempting to use X509VerifyFlags.

As I believe using the OpenSSL::SSL::X509VerifyFlags:: TRUSTED_FIRST might work.

[vladfaust]

Any updates? I'm basically unable to connect to any of Google's APIs 😕

require "http/client"
client = HTTP::Client.new(URI.parse("https://google.com"))
p client.get("/")

It raises the same certificate verify failed (OpenSSL::SSL::Error).

[will]

Just chiming into say that I'm having this problem on heroku with google oauth.

Also since the oauth::client doesn't take a tls: context, the workaround of not verifying doesn't work, unless you monkey patch

[waj]

I just sent a PR with a potential fix. Please, let me know if it works for you and also provide some comments on the solution if possible.