5

All of sudden today morning my HTTP client (HTTParty) threw an error OpenSSL::SSL::SSLError: hostname does not match the server certificate

Firstly I'm not able to understand which so today we have been make that api call almost all day number times from past 2 years without any issue

Secondly I don't understand how do I solve it since it internal to HTTParty

The only thing I know of is that I cant set SSL_CERT_FILE in ENV but as said I already have ROOT CA listed in my /etc/ssl/certs (SSL_CERT_DIR)

Here my output

irb(main):001:0> require "openssl"
=> true
irb(main):002:0> puts OpenSSL::OPENSSL_VERSION
OpenSSL 1.0.1 14 Mar 2012
=> nil
irb(main):003:0> puts "SSL_CERT_FILE: %s" % OpenSSL::X509::DEFAULT_CERT_FILE
SSL_CERT_FILE: /usr/lib/ssl/cert.pem
=> nil
irb(main):004:0> puts "SSL_CERT_DIR: %s" % OpenSSL::X509::DEFAULT_CERT_DIR
SSL_CERT_DIR: /usr/lib/ssl/certs

Lastly as said nothing has change on Openssl and code wise only thing that has happen is the patch the openssl version citing HEARTBLEED vulnerability

Mind you we just patch the openssl version but didnt recompile the RUBY could that be a issue for this

Ruby in question is ruby 1.9.3p327

Net::HTTP library is version httparty-0.13.0

NOTE: - As a solution I didn't except to have VERIFY_NONE options in OPENSSL

Ratatouille
  • 1,372
  • 5
  • 23
  • 50
  • Please post the URL so we can inspect things. – jww Apr 21 '14 at 06:04
  • "As a solution I didn't except to have VERIFY_NONE options in OPENSSL" - yeah, that's probably the least desirable choice. You might as well use anonymous Diffie-Hellman and save the server certificate gyrations. – jww Apr 21 '14 at 06:06
  • "All of sudden HTTParty threw hostname does not match the server certificate error... OpenSSL 1.0.1 14 Mar 2012". OpenSSL 1.0.1 and prior *does not* perform hostname matching. Hostname matching is a 1.0.2 feature, and that version of OpenSSL has not yet been released. So something changed in HTTParty or Ruby. – jww Apr 21 '14 at 06:09
  • jww I have crossed checked our ruby version and httparty gem it been same for almost year now not sure what to say other then that – Viren Apr 21 '14 at 08:01

1 Answers1

1

It's hard to be sure without knowing host you are connecting too, but I guess that they simply changed the certificate at the servers end. The problem might be, that your script does not support SNI (server name indication, e.g. multiple host names and certificates behind the same IP), but the server providers now changed the default certificate for this site (the one which is used if client does not support SNI).

But like I said, it's hard to be sure with this lack of details in the question.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • how would I check this that also I notice that Error aren't appearing any longer I have no idea now why did all of sudden stop giving those OPENSSL error – Viren Apr 21 '14 at 08:00
  • 1
    You can check with `openssl s_client -connect .. ` (no SNI) and `openssl s_client -connect .. -servername ...` (with SNI). And that you don't get the error any longer might be caused by changes on the server side again. – Steffen Ullrich Apr 21 '14 at 08:04
  • While using openssl like this is quite new and I must admin i finding it fun but I done have any idea what most of the data means in the follow output of the command you told me to run `https://gist.github.com/anonymous/11136536` – Ratatouille Apr 21 '14 at 08:46
  • Just to check I was able to get a 200 when I did `GET /` on all the three cases – Ratatouille Apr 21 '14 at 08:47
  • I seems like you don't want to add any information about which site is involved, so you've omitted the major information from your `s_client` output. So you must check yourself: either the CN or the subject alternative names (SAN) in the certificate must match as described in RFC2818/RFC6215, or you get the hostname verification error. `s_client` itself does not verification of the hostname, so it does not mean anything that the SSL connection was successfully established. – Steffen Ullrich Apr 21 '14 at 08:52
  • 1
    if you look at the `CN=..` line or paste the certificate (the big base64 blob) into `openssl x509 -text` you see that the CN matches the host name and the subject alternative name matches also www.admin.myvideochatnetwork.com. So currently all is fine and next time the problem occurs you can check with `s_client` if somebody messed with the server setup. – Steffen Ullrich Apr 21 '14 at 09:59
  • It would have been nice to see the DNS response and the certificate that were causing the troubles. I'm always on the lookout for a MitM ;) – jww Apr 21 '14 at 19:59