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.
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 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 use Net::Jabber::Client to send messages via XMPP.
The server I am connecting to uses self-signed certificate:
DEBUG: .../IO/Socket/SSL.pm:2853: new ctx 45728400
DEBUG: .../IO/Socket/SSL.pm:1540: start handshake
DEBUG: .../IO/Socket/SSL.pm:717: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:750: using SNI with hostname my.host.name
DEBUG: .../IO/Socket/SSL.pm:785: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:806: set socket to non-blocking to enforce timeout=10
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:2754: did not get stapled OCSP response
DEBUG: .../IO/Socket/SSL.pm:2707: ok=0 [0] /CN=my.host.name/CN=my.host.name
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:825: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:825: local error: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:828: fatal SSL error: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:1963: downgrading SSL only, not closing socket
DEBUG: .../IO/Socket/SSL.pm:2875: free ctx 45728400 open=
DEBUG: .../IO/Socket/SSL.pm:2879: free ctx 45728400 callback
DEBUG: .../IO/Socket/SSL.pm:2886: OK free ctx 45728400
I have found that I can pass SSL_fingerprint and/or SSL_verifycn_name to pass verification of self-signed certificate.
To make it just work I hack this
my %ssl_params = (
SSL_verify_mode => $self->{SIDS}->{newconnection}->{ssl_verify},
SSL_hostname => 'my.host.name',
SSL_verifycn_name => 'my.host.name',
);
without success =(
I try to use ->get_fingerprint to obtain finger print and pass it to SSL_fingerprint parameter, but:
IO::Socket::SSL->start_SSL(
$self->{SIDS}->{$sid}->{sock},
$self->{SIDS}->{$sid}->{ssl_params}
) or die "$IO::Socket::SSL::SSL_ERROR";
fail with error:
SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed at
Which option to pass to IO::Socket::SSL to verify self-signed certificate?
Using the fingerprint is probably the easiest way to verify a self-signed certificate which is in your own control. When using SSL_fingerprint it will not care about any other kind of validations, i.e. not check the name, revocation, expiration etc anymore - so if you want to have checks for this too you should not use SSL_fingerprint.
Getting the fingerprint of a site can be done by connecting to the site once without validation (since you have no trust in the certificate yet) and getting the fingerprint or by getting the fingerprint from the certificate directly.
To get the fingerprint by asking the server, assuming that the connection is not intercepted so that you get the correct fingerprint:
use IO::Socket::SSL;
print IO::Socket::SSL->new(
PeerHost => 'example.com:443',
# switch off validation since the certificate is not trusted yet
SSL_verify_mode => SSL_VERIFY_NONE,
)->get_fingerprint,"\n";
This currently gives sha256$642de54d84c30494157f53f657bf9f89b4ea6c8b16351fd7ec258d556f821040 which can be directly used as argument for SSL_fingerprint.
If you have instead the certificate for the site already you can compute the fingerprint directly on it:
# get the certificate
$ openssl s_client -connect example.com:443 -servername example.com
...
-----BEGIN CERTIFICATE-----
MIIF8jCCBNqgAwIBAgIQDmTF+8I2reFLFyrrQceMsDANBgkqhkiG9w0BAQsFADBw
...
-----END CERTIFICATE-----
# take this PEM certificate and get fingerprint
$ openssl x509 -fingerprint -sha256 -noout -in cert.pem
SHA256 Fingerprint=64:2D:E5:4D:84:C3:04:94:15:7F:53:F6:57:BF:9F:89:B4:EA:6C:8B:16:35:1F:D7:EC:25:8D:55:6F:82:10:40
The shown fingerprint is practically the same as before, only written in a different way. By removing all ':' (which are only there for readability) one gets 642DE5....1040 and by prefixing it with the used hash algorithm sha256 one gets something to be usable in SSL_fingerprint: sha256$642DE5...1040.
To use the fingerprint then to connect to the site:
my $cl = IO::Socket::SSL->new(
PeerHost => 'example.com:443',
SSL_fingerprint => 'sha256$642DE5...1040'
);
IO::Socket::SSL can verify self signed certificate only if it trusts the certificate authority file that you use to self sign the certificate.
I think you need to pass proper SSL_ca_file or SSL_ca_path to IO::Socket::SSL so that certificate authority file is accessible to it. This is the first thing mentioned in common usage errors section of IO::Socket::SSL docs.
Typically this occurs when encrypting via localhost, where a certificate per se hardly plays a role.
Modules that involve IO::Socket::SSL can be used with an additional parameter to prevent crashing with "certificate verify failed".
To solve that issue in the long-term, at the top, add this line:
use IO::Socket::SSL qw(SSL_VERIFY_NONE);
$smtp = Net::SMTPS->new('localhost',
doSSL => 'starttls',
Port => 587,
SSL_verify_mode => SSL_VERIFY_NONE
);
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.
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