Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re^5: need to fix my installation of IO::Socket::SSL, but how?

by Anonymous Monk
on Nov 29, 2012 at 08:53 UTC ( #1006200=note: print w/ replies, xml ) Need Help??

in reply to Re^4: need to fix my installation of IO::Socket::SSL, but how?

Does this warrant a new thread, or is there a hope of getting help diagnosing why this site fails while all others that I have tested succeed?

wget --debug https...


wget --ca-certificate=cacert.pem --debug https...

Re^6: need to fix my installation of IO::Socket::SSL, but how?
by ted.byers (Scribe) on Nov 29, 2012 at 19:10 UTC

    Thanks. That was helpful. It now seems that the problem is really low level, in terms of openssl not being able to talk to the server. Rather, what I get using 'openssl s_client -connect' suggests that the usual SSL handshaking dies even before the server's certificate is obtained. Here is some of the output it produced:

    Loading 'screen' into random state - done CONNECTED(000000F0) write:errno=10054 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 321 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---

    And here is the result of the same command when the server is google's home page:

    C:\Work>openssl s_client -connect Loading 'screen' into random state - done CONNECTED(000000F0) depth=1 C = ZA, O = Thawte Consulting (Pty) Ltd., CN = Thawte SGC CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/ +m i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Au +thority --- Server certificate -----BEGIN CERTIFICATE----- MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0 ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q== -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA --- No client certificate CA names sent --- SSL handshake has read 2130 bytes and written 443 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-RC4-SHA Session-ID: 5930A80165EBF4CDA0199A366CB1232C54B4F70B3CEE0690561A95 +14AB8A27EB Session-ID-ctx: Master-Key: A107E655BBC4DC3E28B81CA9986414F2D56E942590F794822EC435 +D3F907C45C7E93D866DF3D082DBE3573278899648D Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - c5 c4 5c ba a7 ff ca 4c-59 f9 5e 08 80 e6 76 3c ..\....LY +.^...v< 0010 - e8 13 92 e8 96 2d 91 fd-e2 ad ff 33 fe ab 16 6d .....-... +..3...m 0020 - 18 15 77 3d f1 d4 b8 24-fe 19 ac 46 b9 69 52 1a ..w=...$. +..F.iR. 0030 - ac db e2 2c 92 33 6c a8-8e 69 f6 3a 65 6d 29 91 ...,.3l.. +i.:em). 0040 - a3 d3 08 6e a7 da 64 f0-88 c7 d4 e3 b4 29 ba 20 ...n..d.. +....). 0050 - a6 31 52 e5 c0 0b 42 b5-da 9c 6d 43 59 17 1e dd .1R...B.. +.mCY... 0060 - 8a 09 0c ee 03 9b 6a a7-87 23 ef d6 2d 61 23 d0 ......j.. +#..-a#. 0070 - 0c 16 c4 69 8c 42 d4 35-00 ae a1 c7 e6 c9 75 2d ...i.B.5. +.....u- 0080 - e2 f7 be 82 93 c2 2c ba-35 67 89 98 c5 8f 47 cb ......,.5 +g....G. 0090 - b4 75 9f c2 .u.. Start Time: 1354196309 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- read:errno=0

    I don't, yet, understand all of this output, but it appears that the SSL hand shaking dies before there is an attempt to exchange certificates.

    Is the presence or absence of support for "Secure Renegotiation" the key to this problem? If not, what is? And is this something I can have my client adapt to by setting one or another 'ssl_opt' value to something useful.? Or do I have to ask the company that is responsible for the server in question for aide?

    Thanks again



      its funny how many devices/software fail at handshaking

      So I've been running into this same problem and it's been driving me nuts. I'm replying to this since my search is turning this node up and maybe this will help other people.

      The actual answer is that your problem is specific to this Verisign certificate, for

      Class 3 Public Primary Certification Authority

      Note that you are in fact getting certificates back from the server; your openssl output has "BEGIN CERTIFICATE" in it after all. What is failing is the certificate chain verification because the Mozilla root certificate bundle that everybody uses has two distinct versions of the same root certificate, i.e., same issuer identity, same public key being advertised, different signature algorithms, MD2 (very old, long-obsolete) vs. SHA1 (still has a few years left, though NIST is getting nervous about this one, too). Verisign is evidently embarrassed by having MD2-signed certificates still out in the wild, would like them to go away, but they can't quite yet, so they've requested that Mozilla distribute both versions of the certificate.

      The problem is that Debian's certificate store — and I'm guessing this applies to everyone who uses openssl to manage certificates — currently can't deal with multiple certificates having the same name, so they're just installing the one with the more secure signature, but the server you're talking to is sending you a chain that ends at the MD2-signed root, which you don't have installed, hence fail.

      You can check if you have this problem (if you're using Debian and it's still May of 2013, then you do) by downloading Mozilla::CA from CPAN, grepping through its certificate file for "Class 3 Public Primary Certification Authority" (without any "Gn" suffix); find both versions — see which one is the MD2-signed one by running them through openssl x509 -text — or (better) run them through

      openssl verify -CApath /etc/ssl/certs
      to see which one isn't properly installed (substitute your own -CApath or -CAfile as necessary; make sure you've got the right one by verifying some of the other certificates).

      My way out of the box is to just install the missing MD2 certificate in your /usr/local/share/ca-certificates and rerun update-ca-certificates. Maybe also do this for "Startcom Certification Authority" which is also duplicated in the same way (they upgraded their sig from SHA1 to SHA256). The problem with this is if Mozilla ever decides to remove these certificates, you won't find out so you'll want to leave a note for yourself for two years from now to check to see if it's still in the Mozilla bundle or if Debian has finally fixed the bug referenced below

      Or you could activate CRL (certificate revocation list) checking (I need to figure out how to do that...)

      Note that this is still a valid root certificate; Mozilla still includes it in its bundle and will probably continue to do so until the last servers using it finally upgrade. They're just not absolutely certain there isn't some way of exploiting the known weaknesses in MD2 (nobody's found one yet) -- my understanding is you still have to break RSA in order to forge a fake certificate chain and the real question is how much longer 1024-bit keys will be viable, and presumably if that ever becomes a problem, there'll be a mass certificate revocation with considerable fanfare... knock wood.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1006200]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (14)
As of 2014-07-10 14:43 GMT
Find Nodes?
    Voting Booth?

    When choosing user names for websites, I prefer to use:

    Results (212 votes), past polls