Strange SSL error when trying to get this URL
Closed this issue · 10 comments
Hi,
i am using node-request and when i try to get this URL:
http://biocache.ala.org.au/occurrence/bc5de9c6-41fe-49df-9e7c-2217399112cf
I get this errormessage:
Error: 140063509739328:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:766:
with wget, curl and in the browser the URL is working, any idea why? Or is this a problem with the Openssl- version (the standard one) have on my ubuntu 12.04 LTS?
Thank you,
Max
Hi. Looks like an issue into the library. Reproduced it under OS X with the same errors. Found this: simplecrawler/simplecrawler#40
Since the resource responds with a 302 redirect, I think there's a bug in the code that should handle the client switch from http -> https or https -> http. I'll have a look and keep you posted.
Hi,
great!
Another thing: When i try to get this URL:
https://secure.scout.com/
with noSslValidation:true i get this error:
UNABLE_TO_VERIFY_LEAF_SIGNATURE
After browsing the sourcecode i saw the flag noSslVerifier, when i set this to true the page works, so could it be that the documentation is outdated?
Thank you,
Max
PS: you can also use this URL: https://secure.scout.com/a.z?s=78&p=12 so you dont get redirected. In Chrome the URL works without any security warning.
Hi,
The documentation isn't outdated. http-request has a different documentation than http-get. It can be browsed by using the http-request branch. However, that error usually appears when the certificate validation fails and under normal conditions noSslVerifier should not be enabled. I'll look into it.
Also, for the original issue, there's an issue with the protocol switching from HTTPS to HTTP. I still have to see why as it fails even though I moved the code that sets the client from the constructor.
Regards,
Ștefan
HI,
ok, thank you, my fault, forgot to look at the documentation in this branch.
Thank you,
Max
Fixed the protocol switching issue.
The second URL throws the same error with the node.js bundled CA list. http-get / http-request uses its own bundle list as provided by Mozilla (uses curl's mk-ca-bundle.pl script). This may be an upstream issue:
~/Projects cat scout.js
var https = require('https')
https.get('https://secure.scout.com/', function (res) {
console.log(res.statusCode, res.headers);
});
~/Projects node scout.js
events.js:72
throw er; // Unhandled 'error' event
^
Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE
at SecurePair. (tls.js:1346:32)
at SecurePair.EventEmitter.emit (events.js:92:17)
at SecurePair.maybeInitFinished (tls.js:959:10)
at CleartextStream.read as _read
at CleartextStream.Readable.read (_stream_readable.js:320:10)
at EncryptedStream.write as _write
at doWrite (_stream_writable.js:219:10)
at writeOrBuffer (_stream_writable.js:209:5)
at EncryptedStream.Writable.write (_stream_writable.js:180:11)
at write (_stream_readable.js:573:24)
Still don't know why it fails.
openssl s_client -connect secure.scout.com:443 shows:
CONNECTED(00000003)
depth=0 /C=US/ST=Washington/L=Seattle/O=Scout Media Inc/OU=Scout Media Inc/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.scout.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=Washington/L=Seattle/O=Scout Media Inc/OU=Scout Media Inc/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.scout.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=Washington/L=Seattle/O=Scout Media Inc/OU=Scout Media Inc/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.scout.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Scout Media Inc/OU=Scout Media Inc/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.scout.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFwTCCBKmgAwIBAgIQLQt7uMUcNSeM3H7R2u83YDANBgkqhkiG9w0BAQUFADCB
vDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMt
VmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4X
DTExMTAwNjAwMDAwMFoXDTE3MTAwODIzNTk1OVowgbgxCzAJBgNVBAYTAlVTMRMw
EQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHFAdTZWF0dGxlMRgwFgYDVQQKFA9T
Y291dCBNZWRpYSBJbmMxGDAWBgNVBAsUD1Njb3V0IE1lZGlhIEluYzEzMDEGA1UE
CxQqVGVybXMgb2YgdXNlIGF0IHd3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MRkw
FwYDVQQDFBBzZWN1cmUuc2NvdXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEApDkF8vO6b4ZJtd1V7bt8dQkJlbhyXEvFCPiE7SvMKTaeUZzvM4aS
tpCxw/amMHerfU5OiD5/wjD4jUN8QTvmaWY80hjHiZsBq/+oXTOKEiMSt+YmanJM
6OnylLTR3YfFlxtg0z2ER+QXCYrXdn5czaMQOzxcFxCqRwRx+NYWG1XDm0KHX0PE
SmQArIJYl2c5o3R0czANOi9Iv95m+bOB9oWeAsC9C19d21MmviYX+9LNHjBhny/q
d+dPZZpK+B9jEUqXU/BzMZdo4k3ULxsMRcf+63sR8/dbbIDK43tEa2LMWhlwxWS+
MPKzTBqc/39pAoGRH8ZOfRQ8iWp6OX6rCwIDAQABo4IBvzCCAbswCQYDVR0TBAIw
ADALBgNVHQ8EBAMCBaAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsG
AQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMEEGA1UdHwQ6MDgw
NqA0oDKGMGh0dHA6Ly9TVlJJbnRsLUczLWNybC52ZXJpc2lnbi5jb20vU1ZSSW50
bEczLmNybDA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUHAwIGCWCGSAGG+EIE
AQYKKwYBBAGCNwoDAzByBggrBgEFBQcBAQRmMGQwJAYIKwYBBQUHMAGGGGh0dHA6
Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYwaHR0cDovL1NWUkludGwt
RzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2VyMG4GCCsGAQUFBwEMBGIw
YKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4
mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdp
ZjANBgkqhkiG9w0BAQUFAAOCAQEAeUCAQr2EwvW6/BF7IPI+fVs4QAEO8hG7quMs
IRU6YFS5FhznAIVx5wpH72WpZsADJc8cZSumZRLZnPyjadd6TbkZVsZN6kj2Mpmc
KZa4cfchrXMeBMuon2LAuNt6bNXSxqicY0tNKbMYuKKq1wFcF6r12R3NLfFCJ/qu
aGJ4KuSci7SQzfN8aPiRsIFNXKpveZOE1LkZEI90TGB0y/Np0IXnU+mzQWPfo5y9
pgH3KziK++DSV1BrIJgMfXUUjEYZNe3JuxUnXbns8czOvHPZi3uE/w/AnVD0O/Ew
buRZgbEn1sxBoD8KaVeei4M9ywG/NcNYtkRO0e4MRq9uZCoL+g==
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=Seattle/O=Scout Media Inc/OU=Scout Media Inc/OU=Terms of use at www.verisign.com/rpa (c)05/CN=secure.scout.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 1620 bytes and written 440 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 6A240000AFAAEBCA2E6182774A664D692114B8336609B9B76378BEC23BC6766E
Session-ID-ctx:
Master-Key: E2BF342F598BCA6EEB9F03D64CEF741F862B3BCC3DD0554A70A24D814F781368926D85F87BAEB00FEDF6A41DCA5CBBFF
Key-Arg : None
Start Time: 1372932618
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
read:errno=54
This StackOverflow entry explains the issue: http://stackoverflow.com/questions/7587851/openssl-unable-to-verify-the-first-certificate-for-experian-url
However, VeriSign Class 3 International Server CA - G3 is not part of the Mozilla's "ca-bundle.crt -- Bundle of CA Root Certificates". I'll have to dig for some more info.
For future reference: "VeriSign Class 3 International Server CA - G3" is an intermediate certificate. Servers that behave properly send this as part of the certificate chain which the above server doesn't. The browsers have a feature that cache these intermediate certificates, therefore this issue is not reproducible via a usual HTTP client that uses a cached intermediate cert. Some sort of intermediate cert management could be implemented to mitigate this, but it isn't a trivial operation. Maintaining a separate list is also possible, but may be a daunting task.
Ok, thank you!
You're welcome.