After an SSL certificate change on my virtual server running plesk and ubuntu I suddenly run into an email issue.
Cert Hostname DOES NOT VERIFY (mail.koemanmotoren.nl != www.koemanmotoren.nl)
http://www.checktls.com/perl/TestReceiver.pl
mail: e.g. kleding#koemanmotoren.nl
Indeed this site seems to verify that the hostname is mail.koemanmotoren.nl
https://www.ssllabs.com/ssltest/analyze.html?d=koemanmotoren.nl
However I have changed every single hostname I could find, while changing it in plesk or via SSH it automatically changes it anyway everywhere, but somewhere must been another hostname noted?
The certificate is purchased and verified for koemanmotoren.nl and www.koemanmotoren.nl
It appears you are using the same certificate on mail.koemanmotoren.nl and www.koemanmotoren.nl (see below). Both Subject Key Identifiers are 26:61:81:B0...4A:F8:4F:5B.
It looks like your DNS is incorrect. You are using the same IP address for both mail.koemanmotoren.nl and www.koemanmotoren.nl.
$ dig mail.koemanmotoren.nl a
;; QUESTION SECTION:
;mail.koemanmotoren.nl. IN A
;; ANSWER SECTION:
mail.koemanmotoren.nl. 21164 IN A 176.28.10.250
And:
$ dig www.koemanmotoren.nl a
...
;; QUESTION SECTION:
;www.koemanmotoren.nl. IN A
;; ANSWER SECTION:
www.koemanmotoren.nl. 21223 IN A 176.28.10.250
If that's correct, then the certificate is missing a Subject Alternative Name (SAN) for mail.koemanmotoren.nl.
According to DNS, your mail server is mail.koemanmotoren.nl:
$ dig koemanmotoren.nl mx
...
;; ANSWER SECTION:
koemanmotoren.nl. 21219 IN MX 10 mail.koemanmotoren.nl.
;; ADDITIONAL SECTION:
mail.koemanmotoren.nl. 13180 IN A 176.28.10.250
However, it appears your mail server is using your web server's certificate.
$ openssl s_client -connect mail.koemanmotoren.nl:993 2>&1 | openssl x509 -text -noout
Subject: OU=Domain Control Validated, CN=www.koemanmotoren.nl
...
X509v3 Subject Alternative Name:
DNS:www.koemanmotoren.nl, DNS:koemanmotoren.nl
...
And it appears you don't have anything on 465:
$ openssl s_client -connect mail.koemanmotoren.nl:465
CONNECTED(00000003)
140735144829404:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:787:
---
no peer certificate available
---
...
$ openssl s_client -connect mail.koemanmotoren.nl:443 2>&1 | openssl x509 -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
11:21:13:40:67:18:79:8f:1d:3f:c5:48:48:f4:2c:f1:24:b6
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Domain Validation CA - SHA256 - G2
Validity
Not Before: Jun 10 11:20:11 2014 GMT
Not After : Jul 15 10:12:25 2015 GMT
Subject: OU=Domain Control Validated, CN=www.koemanmotoren.nl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:eb:cf:e0:55:34:52:79:43:8b:49:1b:65:1c:b1:
ed:ad:93:52:12:b9:3a:55:d7:c2:10:10:cc:3f:2c:
e0:11:9a:4b:5b:ba:eb:3b:5f:f7:ad:74:e2:15:ba:
04:14:bc:52:84:ce:4b:a3:e7:a5:48:45:0f:09:cc:
b9:98:2d:1c:0a:00:75:0d:d0:ac:d6:88:52:5b:50:
fb:bb:10:8b:8d:17:ce:1b:ba:61:23:46:7e:77:70:
0e:d4:89:17:bb:2a:76:62:17:d9:12:ae:7a:1d:8e:
f1:b6:ff:f3:53:76:cd:74:fb:c9:c4:99:27:c8:4c:
5d:9d:07:53:53:d5:16:42:f5:0f:cd:75:01:82:20:
05:07:d6:19:a7:9d:77:85:84:97:cb:61:5a:f9:10:
d1:88:e4:7c:09:97:8c:9a:c1:4f:b9:a6:bf:57:87:
ab:87:59:01:fa:48:3f:86:5e:fe:15:49:8c:32:de:
6b:01:23:ea:6c:d3:fc:77:f8:c5:3f:41:89:18:74:
1b:44:87:b8:76:e4:cd:b8:be:33:0b:71:7d:4e:7f:
83:0a:46:7e:ef:63:ce:0a:20:7e:7c:aa:2a:d4:82:
af:95:a9:29:3d:13:e6:52:51:f2:74:ef:93:70:d9:
71:9b:1f:19:a5:d0:f7:9e:cc:c8:3d:63:6a:a6:35:
7c:75
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
CPS: https://www.globalsign.com/repository/
X509v3 Subject Alternative Name:
DNS:www.koemanmotoren.nl, DNS:koemanmotoren.nl
X509v3 Basic Constraints:
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.globalsign.com/gs/gsdomainvalsha2g2.crl
Authority Information Access:
CA Issuers - URI:http://secure.globalsign.com/cacert/gsdomainvalsha2g2r1.crt
OCSP - URI:http://ocsp2.globalsign.com/gsdomainvalsha2g2
X509v3 Subject Key Identifier:
26:61:81:B0:89:19:AF:DC:BE:01:DC:59:C1:28:F0:D4:4A:F8:4F:5B
X509v3 Authority Key Identifier:
keyid:EA:4E:7C:D4:80:2D:E5:15:81:86:26:8C:82:6D:C0:98:A4:CF:97:0F
Signature Algorithm: sha256WithRSAEncryption
7a:84:d6:2e:31:44:25:95:aa:d0:30:b6:2e:8c:1b:a9:a3:f3:
2e:f3:9c:0d:cf:a9:51:29:5f:39:ac:f2:1d:4b:f7:e0:50:05:
bf:b6:51:f1:0b:a9:43:42:32:9e:40:45:f3:e9:a7:7a:97:7e:
aa:80:c6:0f:f3:89:5c:87:d4:51:c3:44:a1:55:0a:16:3f:66:
8e:1e:af:74:95:18:98:ef:be:08:e5:20:f0:b2:20:4c:88:8e:
8b:00:c3:5d:0b:aa:cc:b6:80:23:83:3a:24:83:8d:fa:13:14:
bf:76:be:60:d0:c8:ce:6e:8d:22:01:90:0f:f4:5e:fa:d6:80:
25:e9:ff:d6:07:1d:95:41:4b:74:c2:a7:a3:e3:02:c4:d3:77:
3e:c9:e2:71:49:ba:4b:71:f8:92:0d:92:24:72:3c:ac:47:ef:
5e:54:2b:c4:ed:5c:78:9d:75:17:f5:7f:23:bd:af:ee:35:4a:
54:0e:72:00:45:45:0a:be:8f:ba:d5:3b:18:f9:8b:e0:0a:25:
74:76:21:01:67:50:6a:0b:7a:3c:fb:c4:b5:ab:f5:01:56:97:
8f:28:d0:28:54:0c:38:5d:7d:36:8d:89:6b:27:62:dd:93:e2:
ea:7f:88:e8:cb:df:0b:4c:74:19:1f:7e:be:54:08:6b:85:e0:
28:52:c9:d7
Related
I am new to learning about certificates & their use in cybersecurity. I was experimenting around with my browser's certificate issued by GTS which is google trust services.
Now, I am confused about what the signature algorithm field means. I tried to google search this and found that the signature algorithm refers to the algorithm used to sign the certificate. If that is the case, I don't understand why I see 3 different signature algorithm fields in my cert. Also, 2 of them have a key size associated with them while the first field does now.
The first signature algorithm is under the category of "Issuer" so I thought maybe this is the algorithm being used to sign the cert. The second & third fields, shown in the second image, are under the category of public key. So what are they being used to sign?
Also, I don't see any key associated with the first signature algorithm, so I am a bit confused with this. Any help is much appreciated! Thank you!
Meta: this is not a programming issue, but I can't fit this in a comment. I am not voting to close because it is inappropriate to do so after answering, but if I am notified the question is closed I will delete (or I authorize a mod to do so) to ensure Q can be deleted or roombad.
I don't know what program you are using to get that decode, or if you have modified it beyond the black-outs, but it appears to be seriously misleading. Here is a better decode from OpenSSL, which follows the ASN.1 structure, with <<# marks added by me:
(redacted)>openssl s_client -connect www.google.com:443 <NUL 2>NUL | openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:48:e6:58:30:39:c0:ad:0a:00:00:00:00:ff:65:fa
Signature Algorithm: sha256WithRSAEncryption <<#1A
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Sep 13 04:06:57 2021 GMT
Not After : Nov 20 04:06:56 2021 GMT
Subject: CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:27:92:c3:bb:e0:95:f4:20:46:a4:1a:5f:96:
78:a7:58:9d:cb:7c:2a:9c:7c:cb:2d:be:30:e9:c1:
71:80:11:da:c3:57:c4:c1:74:5c:a6:26:64:c3:49:
53:7c:44:19:f2:b3:c4:b3:5f:fc:90:30:b3:d4:31:
d1:16:09:b2:97:44:43:99:d6:13:19:20:ef:92:9e:
6e:41:44:56:32:c8:1c:5b:54:48:38:6b:5d:c5:00:
a4:62:be:7e:51:76:26:f6:5b:9c:e0:ed:b3:b8:dd:
16:eb:c6:9d:fc:b6:16:c0:60:1a:84:d8:b1:a5:d1:
5d:1f:35:eb:40:08:f0:2b:a1:a8:e8:d0:93:8f:85:
c6:25:a3:63:d0:d8:09:2e:fa:d2:6f:12:73:4e:aa:
ad:6f:c6:cb:b0:24:b4:65:e3:e3:fd:03:f9:d4:64:
07:2a:4b:6b:df:6b:ae:b2:90:eb:7e:57:f0:a8:3e:
08:d1:07:06:e8:04:dc:a6:bd:02:ee:07:97:1f:cf:
41:2c:8a:b0:15:bc:de:c9:13:b9:0a:8f:38:78:4c:
03:d1:46:36:e6:54:e4:3b:5f:eb:f4:02:14:82:09:
d9:0e:60:ea:29:b4:e3:7e:81:8d:4c:81:ee:4b:6d:
6e:a8:7f:f5:79:39:21:20:01:eb:77:4d:ea:22:d8:
15:13
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C0:43:06:E9:20:B5:1E:51:86:CF:27:BB:3B:91:D5:0B:AE:F8:99:A6
X509v3 Authority Key Identifier:
keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
Authority Information Access:
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der
X509v3 Subject Alternative Name:
DNS:www.google.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.pki.goog/gts1c3/QqFxbi9M48c.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
Timestamp : Sep 13 05:06:59.644 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#2
30:45:02:21:00:84:00:48:E0:6F:E9:0F:D7:AF:A6:67:
22:C8:D3:D3:A8:E4:FB:38:11:3E:5B:C2:EF:AC:E2:54:
7A:94:AC:1A:47:02:20:1E:84:FB:69:49:C2:1B:2E:0B:
84:8C:AD:CA:13:FF:97:19:3C:57:8A:0A:AC:23:DD:61:
C2:AB:7F:07:46:45:65
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
Timestamp : Sep 13 05:06:59.161 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#3
30:45:02:21:00:D5:16:13:47:CE:39:C6:60:AF:11:24:
61:A3:D3:B6:50:BF:32:01:0D:6F:5F:5F:2E:37:E4:F8:
1E:60:9E:70:E6:02:20:09:6A:39:F4:15:FC:36:6C:5F:
9B:C7:E1:B5:48:64:7F:BC:FD:36:6E:1D:7B:E5:74:6A:
55:B0:6E:0F:AF:CF:FF
Signature Algorithm: sha256WithRSAEncryption <<#1B
3a:11:f4:ac:db:fe:63:eb:40:ae:09:4e:d2:3a:89:90:37:c2:
bd:f5:bf:8e:69:7b:48:4e:33:6a:35:46:35:50:bc:94:2e:c3:
87:b4:66:e4:d6:bd:2f:98:99:d4:ba:0f:56:04:de:20:44:86:
61:35:50:3f:66:95:fc:4a:2a:69:b7:3b:0c:70:0f:17:cc:60:
a4:fe:1d:b3:f8:90:0c:b9:fa:3d:69:d0:2f:a9:15:91:cd:89:
bb:92:7d:f5:c6:7f:2f:b8:89:0a:95:f3:71:93:1c:52:77:22:
e8:af:54:f1:b2:0f:9c:4f:9b:28:59:c4:de:ed:63:0f:7b:06:
69:ac:af:5d:bd:1c:52:ca:67:3a:db:52:10:f3:16:55:20:dd:
db:4c:e7:93:e5:d1:56:d1:1f:07:12:0c:da:8c:df:c8:d7:91:
98:5c:c2:f7:f4:dc:ff:66:6b:35:95:f8:b9:cc:cd:1d:0b:cf:
d1:99:5e:ce:1a:d9:97:f3:c5:85:65:e0:17:b9:88:c6:1e:5f:
51:01:97:21:4e:49:6b:a6:ed:3d:df:8d:95:b5:be:54:5a:e4:
58:0d:4c:50:64:5f:47:91:48:45:d4:2b:37:50:bf:d5:fb:cd:
54:f3:c5:a2:72:38:fd:44:da:f9:6f:6a:2a:45:2c:ac:c5:a5:
37:3f:e8:fe
#1A and #1B are the algorithm of the signature on the cert by the issuer, which is in the block following #1B. Yes, there are two copies of this AlgorithmIdentifier in the ASN.1 structure, at the places shown, because X.509 was designed back in the 1980s and people then were concerned about algorithm substitution attacks based on experience with symmetric/secret-key systems, which turned out not to be a significant problem for asymmetric/public-key systems. It is SHA256withRSA because the issuing CA, GTS CA 1C3, uses an RSA (2048-bit) key. Edit: found crossdupes https://security.stackexchange.com/questions/24788/signaturealgorithm-vs-tbscertificate-signature and https://security.stackexchange.com/questions/114746/why-is-the-signature-algorithm-listed-twice-in-an-x509-certificate .
#2 and #3 are the algorithms for signatures on the two Signed Certificate Timestamps (SCTs) embedded in the certificate to support Certificate Transparency. You can see each one is part of an indented block under a heading Signed Certificate Timestamp:. The SCTs are created and signed by various transparency log systems, identified by their logid, and the two log systems GTS CA 1C3 chose to use happen to both have used ecdsa-with-sha256 signatures with P-256 keys. (We can directly see only that the R,S values are 256 bits corresponding to some curve group with a 256-bit order, but RFC6962 confirms that the only acceptable ECDSA curve is P-256.)
Aside: I don't understand why you thought it necessary to black-out some information from a certificate that everyone in the world can easily get and look at. The entire purpose of a certificate (at least an Internet server certificate) is to be publicly known to everybody.
I am using mitmproxy on two different machines. The versions are
Mitmproxy: 4.0.4
Python: 3.8.2
OpenSSL: OpenSSL 1.1.1f 31 Mar 2020
Platform: Linux-5.4.0-33-generic-x86_64-with-glibc2.29
and
Mitmproxy: 5.1.1
Python: 3.8.2
OpenSSL: OpenSSL 1.1.1g 21 Apr 2020
Platform: macOS-10.15.4-x86_64-i386-64bit
One thing, that really puzzles me: How come that the ca-certificates have the same hash value?
AFAIK, the key-pair of which the public one will go into the cert are created dynamically on installation or whenever someones deletes them in .mitmproxy.
But interestingly, both have the same hash value:
> openssl x509 -in .mitmproxy/mitmproxy-ca-cert.pem -noout -hash
8bbe0e8d
This applies actually to a few more installations i did in order to investigate this behaviour.
when I have a look at the modulus, all look different, so this seems to indicate that the keys are in fact different. But AFAIK the hash key is calculated over the key/modulus as well so I would like to know, why I find the same hash value 8bbe0e8d everywhere?
This leads to some interesting side effect:
E.g. on linux the root ca certs are usually in /etc/ssl/certs.
They are deployed there with a sensible name and in addition there is a a symlink pointing to that file.
The name of the symlink ist the hash-value of the cert followed by a sequence number. This is generated by the c_rehash tool of openssl. Normally there are no hash collisions and all sequence numbers are 0.
But in the case of a linux system containing ca-certs of two different mitmproxy-instances we have something like this
# ls -l /etc/ssl/certs/ | grep mitm
lrwxrwxrwx 1 root root 21 Jun 1 21:45 8bbe0e8d.0 -> mitmproxy-systema-ca-cert.pem
-rw-r--r-- 1 root root 1318 Jun 1 21:44 mitmproxy-systema-ca-cert.pem
lrwxrwxrwx 1 root root 21 Jun 1 22:34 8bbe0e8d.1 -> mitmproxy-systemb-ca-cert.pem
-rw-r--r-- 1 root root 1318 Jun 1 22:34 mitmproxy-systemb-ca-cert.pem
So to repeat my question:
Why is the hash value always 8bbe0e8d?
Is - contrary to my belief - the modulus not calculated into the hash
value?
are all mitmproxies using the same keys (which I hope they don´t)?
Any different reason?
Thanks in advance
Christian
Please find the relevant openssl output below:
>> openssl x509 -in mitmproxy-systema-ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15904961119818 (0xe77298ec64a)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=mitmproxy, O=mitmproxy
Validity
Not Before: May 24 12:28:31 2020 GMT
Not After : May 26 12:28:31 2023 GMT
Subject: CN=mitmproxy, O=mitmproxy
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d3:60:2a:3a:8b:bc:9a:2c:fb:da:90:33:fa:a1:
a9:7a:96:52:e4:73:56:c8:c8:7f:8b:f8:ab:4b:e0:
55:2e:05:75:5b:55:4d:6d:58:b0:82:56:23:ac:ee:
ba:d4:4e:b0:ab:8e:52:25:2c:12:ef:fe:23:3b:f5:
0d:26:9e:cd:1e:d5:7c:5a:7b:e0:c6:6b:af:b6:b0:
cd:d1:5b:8b:12:ea:a1:d4:15:78:37:84:f2:d1:48:
61:7b:9b:c6:ec:e3:2c:41:32:72:15:15:d1:5f:7b:
87:01:40:86:6a:cf:5f:2a:0f:19:71:c5:37:08:94:
8c:4d:18:af:5d:5d:80:89:46:e9:04:23:f4:e7:84:
4e:97:ee:81:91:07:c8:18:5e:eb:64:3a:47:9e:c1:
29:50:2c:27:c7:80:35:b9:d6:ec:61:91:de:23:af:
04:7d:0c:e8:43:32:52:09:c9:34:ba:fd:98:51:ef:
78:13:2c:83:4a:e9:31:6e:d8:53:6b:12:79:44:e9:
5b:70:7a:b5:79:2e:00:a9:9f:53:f3:2f:c6:75:b0:
90:1b:00:b4:50:21:5e:fe:b5:a3:36:18:c5:42:cd:
fc:d5:33:e4:1b:c1:26:12:04:05:95:e5:99:7c:23:
2a:ea:de:f3:45:7e:3b:9d:e9:56:a5:83:07:61:e9:
dd:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Netscape Cert Type:
SSL CA
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection, Time Stamping, Microsoft Individual Code Signing, Microsoft Commercial Code Signing, Microsoft Trust List Signing, Microsoft Server Gated Crypto, Microsoft Encrypted File System, Netscape Server Gated Crypto
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
03:9C:EC:D3:BD:2A:C4:A8:E8:23:04:F2:AD:69:C9:2E:CF:CE:85:85
Signature Algorithm: sha256WithRSAEncryption
6d:98:36:7e:e6:2f:54:7d:7f:0a:9b:85:d5:ef:e6:c3:c7:df:
c8:c4:1b:3e:78:51:ee:48:8c:c2:0c:ac:8f:89:67:06:22:3f:
fe:05:f4:17:2b:1c:23:0e:53:1f:0e:7b:23:e1:fe:ac:9c:52:
ac:13:11:06:be:00:55:13:36:1a:47:22:29:41:79:f8:ca:8e:
2b:5a:26:57:b6:26:80:da:7d:ac:10:5f:53:b9:00:e4:d9:ed:
51:04:52:af:d0:7c:33:ce:24:6f:eb:06:d0:49:c6:da:71:25:
64:fe:66:0b:29:90:99:7f:b7:c4:3d:f9:17:5b:24:21:ae:7c:
3f:b1:33:b5:af:64:e2:bc:44:d4:41:df:35:ca:45:8a:08:61:
7a:76:8b:4c:7c:23:80:1d:87:97:29:98:78:a3:38:bf:3c:8d:
5c:79:43:64:95:77:4d:50:cb:a2:17:fd:cf:f9:9f:42:b4:d5:
20:8a:2c:12:af:9d:cd:34:b4:be:53:ad:e4:d8:33:bb:fe:7d:
a1:57:e6:cf:b7:a6:30:a2:3d:f6:8f:4d:4b:f6:2b:cc:19:df:
d2:d5:6e:25:d2:92:13:db:60:f9:6c:e4:bc:09:56:07:5a:30:
6f:89:67:1a:e4:93:52:bd:f6:89:ab:1f:71:17:6b:78:97:69:
05:46:a6:2f
-----BEGIN CERTIFICATE-----
MIIDoTCCAomgAwIBAgIGDncpjsZKMA0GCSqGSIb3DQEBCwUAMCgxEjAQBgNVBAMM
CW1pdG1wcm94eTESMBAGA1UECgwJbWl0bXByb3h5MB4XDTIwMDUyNDEyMjgzMVoX
DTIzMDUyNjEyMjgzMVowKDESMBAGA1UEAwwJbWl0bXByb3h5MRIwEAYDVQQKDAlt
aXRtcHJveHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTYCo6i7ya
LPvakDP6oal6llLkc1bIyH+L+KtL4FUuBXVbVU1tWLCCViOs7rrUTrCrjlIlLBLv
/iM79Q0mns0e1Xxae+DGa6+2sM3RW4sS6qHUFXg3hPLRSGF7m8bs4yxBMnIVFdFf
e4cBQIZqz18qDxlxxTcIlIxNGK9dXYCJRukEI/TnhE6X7oGRB8gYXutkOkeewSlQ
LCfHgDW51uxhkd4jrwR9DOhDMlIJyTS6/ZhR73gTLINK6TFu2FNrEnlE6VtwerV5
LgCpn1PzL8Z1sJAbALRQIV7+taM2GMVCzfzVM+QbwSYSBAWV5Zl8Iyrq3vNFfjud
6Valgwdh6d0ZAgMBAAGjgdAwgc0wDwYDVR0TAQH/BAUwAwEB/zARBglghkgBhvhC
AQEEBAMCAgQweAYDVR0lBHEwbwYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcD
BAYIKwYBBQUHAwgGCisGAQQBgjcCARUGCisGAQQBgjcCARYGCisGAQQBgjcKAwEG
CisGAQQBgjcKAwMGCisGAQQBgjcKAwQGCWCGSAGG+EIEATAOBgNVHQ8BAf8EBAMC
AQYwHQYDVR0OBBYEFAOc7NO9KsSo6CME8q1pyS7PzoWFMA0GCSqGSIb3DQEBCwUA
A4IBAQBtmDZ+5i9UfX8Km4XV7+bDx9/IxBs+eFHuSIzCDKyPiWcGIj/+BfQXKxwj
DlMfDnsj4f6snFKsExEGvgBVEzYaRyIpQXn4yo4rWiZXtiaA2n2sEF9TuQDk2e1R
BFKv0HwzziRv6wbQScbacSVk/mYLKZCZf7fEPfkXWyQhrnw/sTO1r2TivETUQd81
ykWKCGF6dotMfCOAHYeXKZh4ozi/PI1ceUNklXdNUMuiF/3P+Z9CtNUgiiwSr53N
NLS+U63k2DO7/n2hV+bPt6Ywoj32j01L9ivMGd/S1W4l0pIT22D5bOS8CVYHWjBv
iWca5JNSvfaJqx9xF2t4l2kFRqYv
-----END CERTIFICATE-----
>> openssl x509 -in mitmproxy-systemb-ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15891076851956 (0xe73edfda8f4)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=mitmproxy, O=mitmproxy
Validity
Not Before: May 8 10:48:05 2020 GMT
Not After : May 10 10:48:05 2023 GMT
Subject: CN=mitmproxy, O=mitmproxy
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d4:27:ef:99:12:9b:84:9d:82:a7:d1:96:e6:fe:
14:cf:a5:1a:d5:95:f5:1f:b3:25:fc:10:df:1a:f1:
20:4a:a5:e9:e9:b9:20:ba:d3:c2:88:e9:cb:fe:66:
43:5e:4a:1d:9c:39:f4:a8:64:50:51:f6:18:0b:f2:
a2:b3:da:1d:a5:0d:01:c5:bd:c0:6c:b7:a7:25:cd:
6d:d7:21:2b:ba:a8:35:b6:a4:a3:33:0d:15:8d:44:
8e:bb:70:d6:1a:9b:c2:21:09:f9:70:fc:42:8c:d6:
a9:1b:d2:d1:0c:4b:03:f2:44:ca:c7:bf:8f:8b:e2:
fe:0c:ff:99:fe:61:f2:8f:6e:26:ae:ec:60:6c:ff:
ec:51:db:3e:3c:3e:a9:32:38:61:13:52:8e:40:15:
b0:8d:f7:7b:b8:d9:11:84:d6:dc:bd:9e:12:58:5c:
03:13:d6:73:6e:95:84:5f:8d:21:72:bb:17:27:a7:
19:b4:00:43:7b:bc:2e:f2:d9:8a:68:53:0d:de:bc:
03:6c:f8:78:c9:e6:43:1f:45:1e:b0:d0:7d:3b:a7:
cc:05:f2:cb:b1:5f:9c:5f:7f:ee:f3:4e:94:99:28:
33:6f:65:eb:24:a2:44:f1:22:13:a7:71:cd:88:15:
c3:14:77:a2:3c:dc:59:6c:10:81:0f:f1:89:ef:90:
1d:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Netscape Cert Type:
SSL CA
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, E-mail Protection, Time Stamping, Microsoft Individual Code Signing, Microsoft Commercial Code Signing, Microsoft Trust List Signing, Microsoft Server Gated Crypto, Microsoft Encrypted File System, Netscape Server Gated Crypto
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
FE:50:10:81:42:BA:C2:85:01:CB:D2:B4:2E:FF:F1:B3:CD:B2:63:16
Signature Algorithm: sha256WithRSAEncryption
00:d0:fe:58:df:07:90:b9:03:25:b9:0c:6d:37:e4:65:aa:0f:
f9:d4:ea:9a:42:b7:3e:0f:8f:d3:1e:c4:26:03:ff:57:5b:6f:
3d:36:fb:cd:61:4f:4a:5a:20:71:5e:96:25:b3:d2:31:4b:da:
ec:6c:6e:30:e9:0f:77:5b:fe:34:95:5d:31:2a:bf:53:b9:f4:
94:98:5c:fa:b9:c5:27:1a:7e:51:2e:dd:75:f5:c6:51:f7:8d:
69:66:77:9c:e6:0f:7c:79:1a:2f:ca:be:16:9e:45:3f:4b:ff:
49:d8:5d:37:5f:d5:2c:f4:cd:bd:06:fd:09:b0:7b:4b:2b:21:
99:40:24:0a:f6:5f:c3:9c:2f:58:f6:60:b6:b4:3c:b6:89:43:
a6:be:a0:4a:9b:d4:2d:06:b3:2c:b3:eb:c6:18:5a:e4:b1:2b:
f7:b3:7a:a6:41:96:1e:09:19:39:37:25:e0:2c:7a:31:aa:bf:
f8:1a:c2:76:9b:32:30:b7:20:28:ea:63:a9:f7:16:ba:4d:23:
a5:90:7c:0f:31:b9:cd:f8:77:64:8f:28:5f:b8:10:64:4d:08:
f8:6a:9c:45:6f:c7:28:2e:4c:2c:34:09:ef:57:ed:c6:0e:c3:
6d:db:a4:de:8c:72:30:2d:59:8d:c1:e1:2c:6d:29:89:d5:9d:
86:c3:fb:65
-----BEGIN CERTIFICATE-----
MIIDoTCCAomgAwIBAgIGDnPt/aj0MA0GCSqGSIb3DQEBCwUAMCgxEjAQBgNVBAMM
CW1pdG1wcm94eTESMBAGA1UECgwJbWl0bXByb3h5MB4XDTIwMDUwODEwNDgwNVoX
DTIzMDUxMDEwNDgwNVowKDESMBAGA1UEAwwJbWl0bXByb3h5MRIwEAYDVQQKDAlt
aXRtcHJveHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUJ++ZEpuE
nYKn0Zbm/hTPpRrVlfUfsyX8EN8a8SBKpenpuSC608KI6cv+ZkNeSh2cOfSoZFBR
9hgL8qKz2h2lDQHFvcBst6clzW3XISu6qDW2pKMzDRWNRI67cNYam8IhCflw/EKM
1qkb0tEMSwPyRMrHv4+L4v4M/5n+YfKPbiau7GBs/+xR2z48PqkyOGETUo5AFbCN
93u42RGE1ty9nhJYXAMT1nNulYRfjSFyuxcnpxm0AEN7vC7y2YpoUw3evANs+HjJ
5kMfRR6w0H07p8wF8suxX5xff+7zTpSZKDNvZeskokTxIhOncc2IFcMUd6I83Fls
EIEP8YnvkB21AgMBAAGjgdAwgc0wDwYDVR0TAQH/BAUwAwEB/zARBglghkgBhvhC
AQEEBAMCAgQweAYDVR0lBHEwbwYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcD
BAYIKwYBBQUHAwgGCisGAQQBgjcCARUGCisGAQQBgjcCARYGCisGAQQBgjcKAwEG
CisGAQQBgjcKAwMGCisGAQQBgjcKAwQGCWCGSAGG+EIEATAOBgNVHQ8BAf8EBAMC
AQYwHQYDVR0OBBYEFP5QEIFCusKFAcvStC7/8bPNsmMWMA0GCSqGSIb3DQEBCwUA
A4IBAQAA0P5Y3weQuQMluQxtN+Rlqg/51OqaQrc+D4/THsQmA/9XW289NvvNYU9K
WiBxXpYls9IxS9rsbG4w6Q93W/40lV0xKr9TufSUmFz6ucUnGn5RLt119cZR941p
Znec5g98eRovyr4WnkU/S/9J2F03X9Us9M29Bv0JsHtLKyGZQCQK9l/DnC9Y9mC2
tDy2iUOmvqBKm9QtBrMss+vGGFrksSv3s3qmQZYeCRk5NyXgLHoxqr/4GsJ2mzIw
tyAo6mOp9xa6TSOlkHwPMbnN+HdkjyhfuBBkTQj4apxFb8coLkwsNAnvV+3GDsNt
26TejHIwLVmNweEsbSmJ1Z2Gw/tl
-----END CERTIFICATE-----
For example on a freshly installed ubuntu 20.04 box or a fresh container,
issueing the following commands reproduces the issue not only for me:
apt update
apt install mitmproxy
mitmdump
<CTRL-C>
openssl x509 -in /root/.mitmproxy/mitmproxy-ca-cert.pem -hash -issuer_hash
8bbe0e8d
8bbe0e8d
Of course both hashes are the same, it is a self-signed root cert. But I find it surprising that I always get the hash value of 8bbe0e8d. Everywhere.
The answer to solve this riddle is documented in the OpenSSL man page:
-issuer_hash
outputs the "hash" of the certificate issuer name.
And as you can see in the output of your certificate the issuer of the certificate is fixed and therefore the same on each and every system mitmproxy is installed: CN=mitmproxy, O=mitmproxy
A fixed input always outputs the same hash value of course.
One Root CA certificate can have multiple child certificates. Hence all those child certificates have the same issuer and therefore are all mapped to the same hash. Therefore it is nothing unusual that multiple certificates in /etc/ssl/certs/ are mapped to the same hash value. This seems to be some sort of grouping.
Using at that point the certificate fingerprint (or the issuer certificate fingerprint) does not make much sense, because when you use /etc/ssl/certs/ usually you want to find exactly the data of this certificate. If you would already know the certificate fingerprint you also have the certificate and hence doe not have to search for the certificate data.
I'm trying to upload an SSL certificate for a custom domain in Bluemix, but I'm getting a generic error:
BXNUI2081E: An unknown error occurred when modifying certificates and keys: local:///deploySNIArtifacts/mbaasUtilities.xsl:793: Type of the left-hand side of / operator must be a nodeset..
I've followed the documentation, using openssl to generate a self-signed certificate, using the wildcard form of my domain. Any ideas on what I might have missed?
Here's a slightly redacted version of the output from the certificate:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 17167458275182091963 (0xee3f10581c919ebb)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Littleton, O=IBM, OU=CLMServices, CN=*.clmsvcs.ibmcloud.com/emailAddress=<email removed>
Validity
Not Before: Apr 19 13:36:39 2016 GMT
Not After : May 19 13:36:39 2016 GMT
Subject: C=US, ST=Massachusetts, L=Littleton, O=IBM, OU=CLMServices, CN=*.clmsvcs.ibmcloud.com/emailAddress=<email removed>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<<data removed>>
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
<<data removed>>
The only case I've seen this error was when the private key you are using does not match the certificate.
You can run the following 2 commands to check if the private key and certificate you are trying to upload match:
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
Output from both commands needs to be the same.
This problem went away after a few days. I was able to upload the keys successfully.
I am using Perl script (with HTTP::Proxy 0.303, Net::SSLeay 1.66 and IO::Socket::SSL 2.012 modules) with OpenSSL on Win7 and getting error:
failure during X509V3_EXT_conf_nid() for nid=177
6896:error:2208B08F:X509 V3 routines:V2I_AUTHORITY_INFO_ACCESS:invalid syntax:v3_info.c:1
1:
failure during X509V3_EXT_conf_nid() for nid=89
6896:error:22082086:X509 V3 routines:R2I_CERTPOL:invalid policy identifier:v3_cpols.c:160:
section:,name:Policy,value:1.3.6.1.4.1.11129.2.5.1
Is this a Perl, or OpenSSL, or certificate error?
URL: www.google.hr:443
Output from:
openssl s_client -connect www.google.com:443 -tls1 -servername www.google.com | openssl x509 -text -noout
is:
Loading 'screen' into random state - done
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6a:f4:e4:88:96:4e:ef:db
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
Validity
Not Before: Apr 22 13:46:42 2015 GMT
Not After : Jul 21 00:00:00 2015 GMT
Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c0:07:f5:b5:1c:4f:d9:03:c3:6f:07:fa:0e:ae:
0e:96:37:8c:ca:ea:f7:6d:f6:ea:93:a6:4d:ca:01:
0c:d0:fd:ed:aa:c3:2e:56:a1:ec:0d:98:98:31:f5:
13:cb:22:e1:d1:79:31:fe:3a:b8:7c:bc:5d:63:93:
6e:eb:0b:cf:4f:9e:cf:6b:46:c1:3f:15:58:e9:69:
e7:cd:1e:2d:ed:ad:51:5b:0c:77:15:76:b5:3a:25:
6d:17:8e:c1:b5:fb:06:cb:f2:e4:94:bc:33:22:7b:
2e:19:36:a5:1f:a2:95:f7:30:9e:8b:1e:91:6b:e4:
58:2b:45:6d:51:b1:e9:93:b3:f0:5f:5e:30:b8:32:
80:5d:c2:7b:7a:c6:89:63:87:e2:87:cf:27:32:f0:
e8:26:09:55:cf:38:db:9b:c9:42:94:79:8f:d4:8b:
d3:da:5f:41:96:87:97:44:e6:e1:7b:da:31:bc:35:
53:ec:eb:b2:bb:aa:97:e6:ad:d5:52:18:7b:d1:c4:
7d:cf:03:00:3d:d1:e2:a5:6a:47:a5:a8:24:9f:72:
b6:57:0f:ca:bb:12:c3:01:42:f4:50:6d:b1:5e:ba:
1f:d3:7b:17:62:5f:ef:21:03:53:d7:34:c1:14:44:
ae:72:d8:40:73:e6:30:1b:2e:eb:8b:6d:03:cd:fc:
3a:99
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:www.google.com
Authority Information Access:
CA Issuers - URI:http://pki.google.com/GIAG2.crt
OCSP - URI:http://clients1.google.com/ocsp
X509v3 Subject Key Identifier:
A0:01:08:F5:54:1F:91:E6:20:3D:67:2B:20:80:45:F1:83:EA:11:17
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.11129.2.5.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://pki.google.com/GIAG2.crl
Signature Algorithm: sha1WithRSAEncryption
65:56:21:57:c6:67:5d:33:a2:7a:71:58:14:04:75:b0:f6:7b:
12:a0:96:da:4a:ec:07:13:70:5f:a3:da:eb:83:35:7c:d0:c6:
b3:78:36:8c:fe:d7:55:48:20:80:e2:30:ff:f2:3c:89:af:78:
e5:e3:0b:5a:cc:7f:5f:92:7e:e8:05:4c:58:10:2d:b6:5f:2e:
bc:b7:19:ca:32:ee:4b:37:37:be:78:c6:d2:b3:b3:0a:4a:a7:
0f:77:56:5d:52:6f:b7:c5:cb:27:49:cd:db:9a:f9:bf:02:e3:
9d:e1:63:ee:78:c8:58:76:be:1c:ab:05:21:b7:ec:85:48:1a:
84:a7:ce:7a:26:3c:6c:60:39:57:eb:58:7d:8b:b2:aa:d8:40:
0f:c4:0f:bd:1a:f4:f6:73:98:fd:ba:95:17:99:46:15:9c:ba:
f1:e3:18:d7:2e:a6:db:6a:19:6c:29:df:9f:c2:f6:59:ed:b1:
52:bb:21:52:f3:3b:39:1d:17:cb:d6:4b:96:d6:2e:fd:70:7a:
6e:36:a4:26:cc:2f:83:ac:51:76:a2:e2:62:ee:e0:91:fc:0e:
98:7d:ad:83:17:ae:e8:c8:76:4a:5e:ea:20:57:09:28:f9:c7:
d5:7b:dd:6f:f9:a0:10:57:29:6d:93:30:1c:67:2f:f1:6b:2a:
48:f1:61:63
Everything works after updating IO::Socket::SSL to version 2.014.
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