I am testing a sandbox version of the PayPal IPN system that worked previously, but is now not functioning. The IPN simulator says:
"IPN was not sent, and the handshake was not verified. Please review your information."
I reviewed the documentation about the Verisign G5 CA certificate and followed the instructions shown, but the following command:
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /etc/ssl/certs/
Still produces this output: (Truncated)
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 9E01CD86FA9E600EAD505F17E34C0F9BE07E7894E35B20BAF2946F88596BB047
Session-ID-ctx:
Master-Key: 90F662CD0BD319EB87ACFE89CDACEFED2327AC4C827ED74861166B86423B5404
587A70B65BCEA2FAC23F7DDAAA49F9DC
Key-Arg : None
Start Time: 1445624886
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
I verified that the G3 certificate is no longer in the certificate store, and even removed and reinstalled the new certificate many times. I have spent the last 10 hours on this with no end in sight.
I own my own servers, so there is no other administrator I can turn to... I need to figure out how to solve this myself, and am at my wits end. I know I do not know as much about SSL and certificate chains as I should, but theres no help for that part lol.
Can anyone who has performed this task give me a kick in the right direction, and/or let me know what additional information I can provide to help solicit a solution?
Thank you very much,
Dave
Here's how I did to import the G5 root cert into openssl:
Obtain a G5 root certificate from Verisign (Symantec) HERE (get it in PEM format, save the file with .pem extension)
Put the file into your openssl base dir (should be like "/usr/lib/ssl" on your server, but you may check the base dir by running openssl version -d)
Run the command to install the cert
openssl verify -CApath <ssl-base-dir>certs server-certificate-file
(replace <ssl-base-dir> with your openssl base dir, and replace server-certificate-file with your .pem file, the command would be something like openssl verify -CApath /usr/lib/ssl/certs G5.pem)
The response would be an G5.pem: OK for the installation
Try again with the connection command
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /usr/lib/ssl/certs/
You will see Verify return code: 0 (ok) at the end of the response
I downloaded the VeriSign Class 3 Public Primary Certification Authority - G5.pem certificate file into a local directory, and ran the following command:
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts
-CAfile "ssl\VeriSign Class 3 Public Primary Certification Authority - G5.pem"
Openssl returned a successful result (truncated):
Server certificate
subject=/C=US/ST=California/L=San Jose/O=PayPal, Inc./OU=PayPal Production/CN=api-3t.sandbox.paypal.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 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 3379 bytes and written 344 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 9E01CD86FA9CEB77AD505F17E34C0B9B8A233BD98E30D705F2946F88596F077D
Session-ID-ctx:
Master-Key: 7AC616B7499ED70B6D75FAD3308C332A48B85987685A514365B7507297A3C6A70CD6E7503CE27A9A157045531B54149F
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1445867355
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Note that I used the -CAfile option to directly reference the CA root certificate.
Related
I received a new keystore .jks file for ssl connection to replace an old, but working, .jks keystore file, but I got "unexpected handshake message: serve_hello" error. I was told to make sure the keystore contains a client cert, so I used keytool to export its cert to a pem file, then use openssl to check the purpose. The result shows
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
...
However when I applied the same process to check the old but working jks file I got the same result. Wonder if this is the right way to verify the certificate? And how to troubleshooting this handshake error with the new jks file?
Thanks!
The extended key usage extension contains OIDs which define the purpose:
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
https://datatracker.ietf.org/doc/html/rfc5280 Page 44
See: https://oidref.com/1.3.6.1.5.5.7.3.1 and https://oidref.com/1.3.6.1.5.5.7.3.2
When opening a certificate on Windows you can see the extension here:
I used this tool in this link to generate a self-signed certificate for a Windows webserver.
The command to generate the cert is like following
New-SelfSignedCertificateEx -Subject "CN=192.168.56.111" -SAN "192.168.56.111" -IsCA $true -EKU "Server Authentication", "Client Authentication" -KeyLength 2048 -KeySpec "Signature" -KeyUsage "DigitalSignature" -FriendlyName "192.168.56.111" -NotAfter $([datetime]::now.AddYears(5)) -StoreLocation "LocalMachine" -Exportable
After installing the certificate with IIS, and add the certificate to the trusted root CA store in a Windows 10 client, I was able to browse the website with no certificate errors.
However when I try to do the same in a ubuntu 18.04 client by installing the cert to the CA certs store and test using cURL, it doesn't work
Install cert to Ubuntu ca-certificates
openssl s_client -connect 192.168.56.111:443 -showcerts > out.txt
#then use vim to edit out.txt and save the cert to 192.168.56.111.crt
sudo cp 192.168.56.111.crt /usr/local/share/ca-certificates
sudo update-ca-certificates
Test the connection using cURL
curl https://192.168.56.111
And got the error message
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
When adding the cert to the Chrome Certifiates store, Chrome shows NET::ERR_CERT_INVALID
So my question is, why does it work in Windows client but not in Ubuntu 18.04? I can't see any error indicating what's wrong with the certificate in Ubuntu so I'm stuck at the moment.
Your openssl command is not correct:
jonathan.muller#jonathan-muller-C02ZC4EPLVDQ$ openssl s_client -connect drylm.org:443 -showcerts
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = blog.drylm.org
verify return:1
---
Certificate chain
0 s:/CN=blog.drylm.org
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIFUzCCBDugAwIBAgISA0xYp5ZHU+NGF1EW/RcUuV0fMA0GCSqGSIb3DQEBCwUA
...
you have a lot of noise in the output.
Here is how to extract the certificate:
echo | openssl s_client -connect 192.168.56.111:443 2>/dev/null | openssl x509 > 192.168.56.111.pem
and you can copy this pem file to the truststore.
Edit:
I just made the exercise by creating a self sign certificate on this website
in my shell:
john#kona$ curl https://test.drylm.org
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
then
john#kona$ echo | openssl s_client -connect test.drylm.org:443 2>/dev/null | openssl x509 > test.drylm.org.crt
sudo cp test.drylm.org.crt /usr/local/share/ca-certificates/
john#kona$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
Adding debian:test.drylm.org.pem
done.
done.
and finally:
john#kona$ curl https://test.drylm.org
Path : ~
No more error message with curl.
I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.
I have the following results in certificate validation problems:
use URI;
use Web::Scraper
my $res = $scraper->scrape( URI->new('https://example.com') );
After waiting about 2 min, I get the following error:
GET https://example.com failed: 500 Can't connect to example.com:443
(certificate verify failed)
Per suggestion in comments, I ran openssl s_client -connect olms.dol-esa.gov:443. It output the following to the terminal instantly and then hung for about 2 minutes:
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/CN=olms.dol-esa.gov/O=DEPARTMENT OF LABOR/L=Washington/ST=District of Columbia/C=US
i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
3 s:/O=Digital Signature Trust Co./CN=DST Root CA X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
<SNIP>
-----END CERTIFICATE-----
subject=/CN=olms.dol-esa.gov/O=DEPARTMENT OF LABOR/L=Washington/ST=District of Columbia/C=US
issuer=/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
---
No client certificate CA names sent
---
SSL handshake has read 6233 bytes and written 615 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DES-CBC3-SHA
Session-ID: 3E5B2FBD819EF7880143C874181B7D67D3B1A0CE7C319B35F276E1CE8D9B9A18
Session-ID-ctx:
Master-Key: BE8A24B0350C48FCC3ECFA21AE896BF09F8978C481F3BE01E1E9B904A0BFB87098914DB6CD592BBC7634142A4B5C43FB
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1486034348
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
After waiting about two minutes, the following was output:
read:errno=0
Web::Scraper uses LWP::UserAgent. More modern versions of that attempt to verify the hostnames unless you turn off that feature. Something else may be going on, but this question is low in details.
One of the constructor arguments to LWP::UserAgent is:
LWP::UserAgent->new(
ssl_opts => { verify_hostname => 0 }
...;
}
You can construct your own user agent object and give it to Web::Scraper:
my $scraper = Web::Scraper->new(...);
$scraper->user_agent( $your_own_lwp_useragent_object );
Also see the answer at "Perl LWP::Simple HTTPS error". For more help, we'll need version details for the relevant modules and your openssl details.
I have set up SES successfully on one AWS instance. Now I am trying to use it on a second (not cloned) instance and when I run any of the SES scripts, I get an error:
ses-get-stats.pl -k aws-credentials -q
I get:
Can't connect to email.us-east-1.amazonaws.com:443 (certificate verify failed) LWP::Protocol::https::Socket: SSL connect attempt failed with unknown errorerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at /usr/local/share/perl/5.8.8/LWP/Protocol/http.pm line 51.
Getting the Perl stuff working was a challenge and it is possible I did it differently on the instance. Any place I should be looking to fix this?
When I run:
openssl s_client -CAfile .../cacert.pem -connect email.us-east-1.amazonaws.com:443 < /dev/null
I get:
CONNECTED(00000003)
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFRDCCBCygAwIBAgIQGcGV1HNHcHHJGun1oi7qbTANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwHhcNMTAxMDA4
MDAwMDAwWhcNMTMxMDA3MjM1OTU5WjB2MQswCQYDVQQGEwJVUzETMBEGA1UECBMK
V2FzaGluZ3RvbjEQMA4GA1UEBxQHU2VhdHRsZTEYMBYGA1UEChQPQW1hem9uLmNv
bSBJbmMuMSYwJAYDVQQDFB1lbWFpbC51cy1lYXN0LTEuYW1hem9uYXdzLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuDbIrCnMbnltwoXJfQrV6UgtYTza
VdjQw+ylHg9pmNRUAeI8kIEkJYK6wIUy8MdJL/NAJdw5H9WFouNyDKi6T2FFGOns
JU0Qf3Cbsf3XymLxPsMPZ0xgqFYS5QfpuXSwjegkaerABHCOdp0bGnYbpXGFfRzv
VYO3ej48ku4XAH0CAwEAAaOCAhAwggIMMD0GA1UdEQQ2MDSCHWVtYWlsLnVzLWVh
c3QtMS5hbWF6b25hd3MuY29tghNlbWFpbC5hbWF6b25hd3MuY29tMAkGA1UdEwQC
MAAwCwYDVR0PBAQDAgWgMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9TVlJTZWN1
cmUtRzItY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1cmVHMi5jcmwwRAYDVR0gBD0w
OzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAfBgNV
HSMEGDAWgBSl7wsRzsBBA6NKZZBIshzgVy19RzB2BggrBgEFBQcBAQRqMGgwJAYI
KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTBABggrBgEFBQcwAoY0
aHR0cDovL1NWUlNlY3VyZS1HMi1haWEudmVyaXNpZ24uY29tL1NWUlNlY3VyZUcy
LmNlcjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcG
BSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJp
c2lnbi5jb20vdnNsb2dvMS5naWYwDQYJKoZIhvcNAQEFBQADggEBAF/FIwfH4c0X
iIPmF6yKfyiAWp+YuxSteMQzlPluZdxRVdXmukJMABKMbKLyroTV8g9G28aMFIIR
YLdCZUHci0mlbeTXmfjpMVIvhWlxYFsE+ZHpC3i77fQMtalv8bmlThjMy9aVMB8x
fUzMSvxRJbSdHIATqHx7CI8ogT5xEYrflbPk0J4ba380Vw3VArmNUKv9pYtgStv8
YikXMK5ufw0sSBFSo2GAumkvH/DJi8d3AnronpD5WWLs24N6uZCvWqWtKK/FiUhV
JUMXrDohrbX+88P5fbVymeOShUiE1bU6sGPbhiHzXH7VvSYHmeaTGUNtjG1aV/py
wHMrnJ7V7Xs=
-----END CERTIFICATE-----
subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 3075 bytes and written 300 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: EA1C64EA86BFBE11BE8395F15DBF6B21228719EB215857257CD71AB2EFC3AE9E
Session-ID-ctx:
Master-Key: 9BFE26D5AFD9C1D222DF73A607CD491F617CD87BC7DCD15904954F198692E22ACACBFAA03A6F10B9F87073DA162B4EB3
Key-Arg : None
Start Time: 1302693748
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
DONE
This is the same response as on the instance where ses-get-stats.pl works.
After creating a certificate file as suggested by daxim, running:
openssl s_client -CAfile test.cer -connect email.us-east-1.amazonaws.com:443 < /dev/null
Returns:
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
verify return:1
depth=1 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
verify return:1
depth=0 /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
followed by additional information including the certificate.
For some reason, your OpenSSL does not get the intermediate certificate. (Outdated software?)
Install the intermediate certificate with the subject hash 0xeb99629b, available at https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&actp=CROSSLINK&id=AR1513.
You can use it with the -CAfile parameter in OpenSSL tools and with the environment variable HTTPS_CA_FILE for the Perl HTTPS stack. To use it system-wide, place it in the appropriate ca-certificates directory, e.g. /etc/ssl/certs, and c_rehash the directory.
Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=705044
This might have something to do with it.
Disable verification of SSL peers and retry.
export PERL_LWP_SSL_VERIFY_HOSTNAME=0
try to remove (or rename) this directory:
/usr/local/share/perl