SSLError: hostname "WXYZ" does not match server certificate

I just started learning Ruby and after some basic things, I'm trying to figure out how to call REST on a service in ruby. I can easily get requests for the foursquare API. On the other hand, calls to the Cisco CMX API give an error. My ruby ​​version is 2.1.2. I searched a lot of solutions on the Internet, but still had problems. This is my shell command that I run.

Working

$resclient >> RestClient.get 'https://api.foursquare.com/v2/venues/search?ll=40.7,-74&oauth_token=0ZDO1JMJ0PW2QTCDK50OGZ21UENHZ0Y3KIDQZJLLURTQNRQ2&v=20150106' 

It gives an error

 $restclient >> RestClient.get 'https://learning: learning@64.103.26.61 /api/contextaware/v1/maps/.json' 

My error log:

 OpenSSL::SSL::SSLError: hostname "64.103.26.61" does not match the server certificate from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/2.1.0/openssl/ssl.rb:139:in `post_connection_check' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/2.1.0/net/http.rb:922:in `connect' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/2.1.0/net/http.rb:863:in `do_start' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/2.1.0/net/http.rb:852:in `start' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/rest-client-1.7.2/lib/restclient/request.rb:413:in `transmit' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/rest-client-1.7.2/lib/restclient/request.rb:176:in `execute' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/rest-client-1.7.2/lib/restclient/request.rb:41:in `execute' from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/rest-client-1.7.2/lib/restclient.rb:65:in `get' from (irb):3 from /Users/apple/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/rest-client-1.7.2/bin/restclient:93:in `<top (required)>' from /Users/apple/.rbenv/versions/2.1.2/bin/restclient:23:in `load' from /Users/apple/.rbenv/versions/2.1.2/bin/restclient:23:in `<main>' 

Could you give some advice? Thanks you

+5
source share
3 answers

Could you give some advice?

Here is a more detailed answer and how to fix the problem in Ruby with something other than the pathetic OpenSSL::SSL::VERIFY_NONE .

 $ openssl s_client -connect 64.103.26.61:443 | openssl x509 -text -noout depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2 ... Subject: C=US, ST=CA, L=San Jose, O=Cisco Systems, Inc., CN=msesandbox.cisco.com ... X509v3 Subject Alternative Name: DNS:msesandbox.cisco.com 

So, the device has the DNS name msesandbox.cisco.com. nslookup tells you a good hostname:

 $ nslookup msesandbox.cisco.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: msesandbox.cisco.com Address: 64.103.26.61 

So, the first thing you need to do is connect to it by DNS name, not IP address.

If you issue certificates for the cisco.com domain (or you can make a request), you can ask to add the IP address 64.103.26.61 as the Subject Alternative Name (SAN). Thus, the certificate will have two SANs.


Now, if you go back to the openssl command:

 $ openssl s_client -connect 64.103.26.61:443 | openssl x509 -text -noout depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2 verify error:num=19:self signed certificate in certificate chain ... Issuer: C=US, O=HydrantID (Avalanche Cloud Corporation), CN=HydrantID SSL ICA G2 ... Subject: C=US, ST=CA, L=San Jose, O=Cisco Systems, Inc., CN=msesandbox.cisco.com 

You will see that the issuer and the entity are different from each other. This means that this is not a self-signed certificate. The certificate was issued by HydrantID (Avalanche Cloud Corporation).

If you look further, you will see that the Issuer's public key (Authorization Key Identifier) ​​is different from the Subject public key (Keyword Identifier):

 X509v3 Authority Key Identifier: keyid:98:6A:B6:2D:2E:BF:A7:AA:9F:F6:F7:D6:09:AF:D5:8B:57:F9:8A:B7 ... X509v3 Subject Key Identifier: B5:3D:50:53:0A:A2:06:9E:9A:29:89:7A:AB:96:90:FE:9D:6B:57:A0 

Again, he is not himself signed.


If you return to the OpenSSL team again, you will see that the issuer has HydrantID SSL ICA G2 , and its issuer is QuoVadis Root CA2 G3 :

 depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2 verify return:1 depth=1 C = US, O = HydrantID (Avalanche Cloud Corporation), CN = HydrantID SSL ICA G2 verify return:1 depth=0 C = US, ST = CA, L = San Jose, O = "Cisco Systems, Inc.", CN = msesandbox.cisco.com verify return:1 

This means QuoVadis Root CA2 G3 issued by HydrantID SSL ICA G2 ; and HydrantID SSL ICA G2 issued by msesandbox.cisco.com . QuoVadis Root CA2 G3 is the pinnacle of the food chain.

You can get the QuoVadis Root CA2 G3 from the CA QuoVadis CA Certificate Download :

 $ curl -O -J -L https://www.quovadisglobal.bm/Repository/~/media/Files/Roots/quovadis_rca2g3_der.ashx % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1380 100 1380 0 0 1808 0 --:--:-- --:--:-- --:--:-- 5726 curl: Saved to filename 'quovadis_rca2g3_der.cer' $ openssl x509 -in quovadis_rca2g3_der.cer -inform DER -out quovadis-ca.pem -outform PEM $ cat quovadis-ca.pem -----BEGIN CERTIFICATE----- MIIFYDCCA0igAwIBAgIURFc0JFuBiZs18s64KztbpybwdSgwDQYJKoZIhvcNAQEL BQAwSDELMAkGA1UEBhMCQk0xGTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHjAc BgNVBAMTFVF1b1ZhZGlzIFJvb3QgQ0EgMiBHMzAeFw0xMjAxMTIxODU5MzJaFw00 ... -----END CERTIFICATE----- 

IF trusts QuoVadis to certify the device, and then:

 $ openssl s_client -connect msesandbox.cisco.com:443 -CAfile quovadis-ca.pem CONNECTED(00000003) depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2 verify return:1 depth=1 C = US, O = HydrantID (Avalanche Cloud Corporation), CN = HydrantID SSL ICA G2 verify return:1 depth=0 C = US, ST = CA, L = San Jose, O = "Cisco Systems, Inc.", CN = msesandbox.cisco.com verify return:1 ... Start Time: 1420616960 Timeout : 300 (sec) Verify return code: 0 (ok) 

OpenSSL notification completed with Verify return code: 0 (ok) . This tells you that you have a good chain. OpenSSL does not perform host name matching, but we already know that the host name in the certificate is good.


Now for the Ruby code. All you have to do is connect the CA to Ruby:

 #!/usr/bin/ruby require 'net/http' require 'net/https' require 'openssl' uri = URI('https://msesandbox.cisco.com:443') options_mask = OpenSSL::SSL::OP_NO_SSLv2 | OpenSSL::SSL::OP_NO_SSLv3 | OpenSSL::SSL::OP_NO_COMPRESSION http = Net::HTTP.new(uri.host, uri.port) request = Net::HTTP::Get.new(uri.request_uri) if uri.scheme == "https" http.use_ssl = true http.verify_mode = OpenSSL::SSL::VERIFY_PEER http.ca_file = File.join(File.dirname(__FILE__), "quovadis-ca.pem") # http.ssl_options = options_mask end response = http.request request 

And here’s the run:

 $ ./Connect-Test.rb $ 

There are no exceptions, not OpenSSL::SSL::VERIFY_NONE .

You should try using options_mask as it removes weak / wounded / broken protocols. But Ruby is so broken and undocumented from time to time, I could never get it to work.


I managed to trust both HydrantID SSL ICA G2 and QuoVadis Root CA2 G3 using OpenSSL (which means I got Verify Result 0 (OK) from OpenSSL). But Ruby could only handle QuoVadis Root CA2 G3 (it could not chain to HydrantID SSL ICA G2 ). More ruby ​​breakdown.

+12
source

If you go to your host using a browser, for example

 > https://64.103.26.61/ 

You will see that you get the same error. The certificate on this server is invalid because the server responds to a different host name than the one specified in the certificate.

You can find a more complex description by entering the server address of the Digicert Help Center . Certificate issued by msesandbox.cisco.com . If this is the address you are trying to reach, use it instead of IP. If this is your server, change the name of the response

+1
source

One almost always bad workaround is to ignore SSL certificate validation:

 :verify_ssl => OpenSSL::SSL::VERIFY_NONE 

UPDATE: This workaround is almost never preferred, as it usually represents a clear security hole that is easy to forget. In most cases, when it seems to you that you want to use SSL without certificate verification, it would be better if you create a self-signed certificate and block the use of both sides by the same one.

-4
source

Source: https://habr.com/ru/post/1210458/


All Articles