Self signed SSL certificate generated by New-SelfSignedCertificateEx isn't trusted in Ubuntu - powershell

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.

Related

Is there a way to check if a certificate is client cert or server cert?

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:

Unable to get the new paypal SSL CA certificates to be recognized. Handshake to Sandbox failing

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.

EJBCA adminweb Authorization denied

I am currently testing with EJBCA while having a problem in accessing the administration page.
The EJBCA-4.0.13 is running on CentOS 6.2, with apache-ant-1.8.4, jboss-5.1.0-GA, mysql and mysql-connector-java. Installation is OK and no error occured in the jboss server log and I can access the EJBCA public web page with the url: https://:8443/ejbca. While I cannot access the administration page(https://:8443/ejbca/adminweb) with this information:
Authorization Denied
Cause: Your certificate is revoked or cannot be located in the database.
Any idea will be appreciated!
This is done in LocalCertificateStoreSessionBean.authenticate method. This could mean that you have not properly generated SuperAdmin certificate, or it is revoked, timed out or is issued by another CA that EJBACA's AdminCA.
Check your superadmin.p12 with:
openssl pkcs12 -nokeys -in ./superadmin.p12 -out superadmin.pem
openssl x509 -in ./superadmin.pem -text

Apple Push Certificate - Invalid Certificate Signing Request

I've created my own CSR with the following command
openssl req -new -newkey rsa:2048 -nodes -out bgsisson_com.csr -keyout bgsisson_com.key -subj "/C=US/ST=CA/L=Los Angeles/O=Benjamin Sisson/OU=Development/CN=bgsisson.com/emailAddress=myemail#dom.com"
Then I created a CRT with the following command
openssl x509 -req -days 365 -in bgsisson_com.csr -signkey bgsisson_com.key -out bgsisson_com.crt
When I try to upload this cert to https://identity.apple.com/pushcert/ I get a invalid certificate signing request.
Am I creating the certificate wrong? Does the cert need to be verified?
Thanks!
Update - Removed wildcard from CN. I'm still getting an Invalid Cert signing request.
Update - added CSR and CRT. I test uploading both of them, but I think I just need to upload the CSR
Update - added emailAddress to CSR
bgsisson_com.csr
-----BEGIN CERTIFICATE REQUEST----- MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCdXMxCzAJBgNVBAgTAkNBMRQwEgYDVQQH
EwtMb3MgQW5nZWxlczEYMBYGA1UEChMPQmVuamFtaW4gU2lzc29uMRQwEgYDVQQL
EwtEZXZlbG9wbWVudDEVMBMGA1UEAxMMYmdzaXNzb24uY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAudmpTvmnWLivwLaFNx6w/kgwUbPCr8ujZOtx
1Lu/+alpuHPoQ4Kpyt3rsj9wc/PSWXBFjIV607YCINTJrQfHUJMq55s3aWxeroB9
llqXn0qTJ2GujAmuWBX2nvIZucQVF1xX3/V1179CKM/+z/rE4ehiJdEnMQk6Otrv
HT1W/eIL5rzSjky+ZpaRSguUpyQSsSuD4Cdfo6NMiY5RVvh9N/Q/O+jEpAJxEHOd
nAbJj8WU2WW9MxtUw21UODh5kHX+b8sLfuKB9EJ2XUqwvdJt9MgnrAiYVkvjq1iT
dZFd2nHiKZnLRr2jBZ74u9duqwm9kD8zoOAiMzbFUTjD1AZIHwIDAQABoAAwDQYJ
KoZIhvcNAQEFBQADggEBAK+Zr5pdtcqVUtMD8843wz7h3bAOVIvrJpbr2/g1mUvo
4Pn27Xlw/CZL2aqOniTTCOeGvWAvHtckxaTxPL3Ruid2/QTnOgKecUnqVPAoqaBP
0SPJDo3X1rbWKVTTJOvT67Kywtd8q+Msx46IqE/2YWur+XO47dnKWR4lPJipgjjY
p+zt9TPTAqu+M6xwqsslUy9r68GaQGTdRdQSyZB5XAg+I271mtxrSrImaAPEi1MY
2ch9r4NaFWH9X7CH67Y0QCKsGjKU4Ftz6x8c1cf4n8TuWgD5/S2UeY+zj3JvjVgj
DJlQyKGmYCC6G0FcoWSD7yCvJ+k0DcoJuGUO3094RIg=
-----END CERTIFICATE REQUEST-----
bgsisson_com.crt
-----BEGIN CERTIFICATE----- MIIDajCCAlICCQCMvMl8OXFb3jANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJ1
czELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRgwFgYDVQQKEw9C
ZW5qYW1pbiBTaXNzb24xFDASBgNVBAsTC0RldmVsb3BtZW50MRUwEwYDVQQDEwxi
Z3Npc3Nvbi5jb20wHhcNMTIwMzIyMTY1MzA1WhcNMTMwMzIyMTY1MzA1WjB3MQsw
CQYDVQQGEwJ1czELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRgw
FgYDVQQKEw9CZW5qYW1pbiBTaXNzb24xFDASBgNVBAsTC0RldmVsb3BtZW50MRUw
EwYDVQQDEwxiZ3Npc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC52alO+adYuK/AtoU3HrD+SDBRs8Kvy6Nk63HUu7/5qWm4c+hDgqnK3euy
P3Bz89JZcEWMhXrTtgIg1MmtB8dQkyrnmzdpbF6ugH2WWpefSpMnYa6MCa5YFfae
8hm5xBUXXFff9XXXv0Ioz/7P+sTh6GIl0ScxCTo62u8dPVb94gvmvNKOTL5mlpFK
C5SnJBKxK4PgJ1+jo0yJjlFW+H039D876MSkAnEQc52cBsmPxZTZZb0zG1TDbVQ4
OHmQdf5vywt+4oH0QnZdSrC90m30yCesCJhWS+OrWJN1kV3aceIpmctGvaMFnvi7
126rCb2QPzOg4CIzNsVROMPUBkgfAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBALa5
1rkRjCAJF1WU2TIM9FA7A7upb8YVKnagthCIn3kLYBqI4wRHO28HPm53IWJP/hUG
80rjczKY03PFjuiikrlPzUdBR99n4jq6UhcFdG4Z948lXoS2WsIJc6vZmA6wBAIE
h+Xe4SjdPvhsKKrVLFEgpSb/67mUdHF2qVkhvkqs8EgJ65fozjW2adyF6NxOWrmG
5Q++Dp/+K1TSkLM/yZieWWbQ042OyYCZ+agIuwpduW5waKbN1+TERKJo0eFlwQUi
w7KsgLpfoyGji4FzznODGxRq/2Ja5VPnnfa4pxG+l0qkn5VoW27qFHJy5E6Z7Bqb
RqpfbiQ6jeLcqCiWgig=
-----END CERTIFICATE-----
You need to sign the certificate request from a vendor with an Enterprise Developer Account. The information is available at http://www.softhinker.com/in-the-news/iosmdmvendorcsrsigning
I suspect that it is tripping over the wildcard in the CN as AppIDs with wildcards are not accepted.

AWS SES certificate verify failed

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