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.
Related
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.
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
We have a wildcard SSL certificate for our domains. If I setup the Secure Canvas URL, we get the dreaded empty response error. My understanding is that this is because Facebook has a problem with our SSL cert.
Is there any recommendations on how to figure out what is wrong with our SSL certificate?
I read this blog post: http://developers.facebook.com/blog/post/567/
I ran the test on the site they recommended, it looks pretty good to me. Could that Beast mode warning be causing this problem? Here are the results I get back:
Certificate Information
Common names *.mydomain.com
Alternative names *.mydomain.com mydomain.com
Prefix handling Not required for subdomains
Valid from Tue Jul 19 00:00:00 UTC 2011
Valid until Wed Jul 18 23:59:59 UTC 2012 (expires in 8 months and 18 days)
Key RSA / 2048 bits
Signature algorithm SHA1withRSA
Server Gated Cryptography Netscape Step-Up, Microsoft Server Gated Cryptography
Weak key (Debian) No
Issuer EssentialSSL CA
Next Issuer COMODO Certification Authority TRUSTED
Chain length (size) 2 (2581 bytes)
Chain issues None
Validation type Domain-validated (DV)
Revocation information CRL, OCSP
Revocation status Good (not revoked)
Trusted Yes
Protocols
TLS 1.2 No
TLS 1.1 No
TLS 1.0 Yes
SSL 3.0 Yes
SSL 2.0+ upgrade support Yes
SSL 2.0 Yes N
(*) N next to protocol version means the protocol has no cipher suites enabled
Cipher Suites (sorted by strength; server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) 168
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) 256
Miscellaneous
Test date Thu Nov 03 19:37:27 UTC 2011
Test duration 55.590 seconds
Server signature Apache
Server hostname dev.mydomain.com
Session resumption Yes
BEAST attack Vulnerable INSECURE (more info)
Secure Renegotiation Supported, with client-initiated renegotiation disabled
Insecure Renegotiation Not supported
Strict Transport Security No
TLS version tolerance 0x0304: 0x301; 0x0399: 0x301; 0x0499: fail
PCI compliant No
FIPS-ready No
Ephemeral DH 1024 bits (p: 128, g: 1, Ys: 128)
Are you missing the intermediate certificates? Check at http://www.sslshopper.com/ssl-checker.html to see if you have a full chain
Also good is the checker at https://www.ssllabs.com/
If the app is FBML Facebook is very strict about which certificates it will accept when connecting to your site to download the content - if your app uses iFrames it's mostly up to the user's browser settings and you'll get away with less strict checking
The quote from that blog post which seems to have tripped up most FBML apps is:
If you enable SSL for your FBML app, please make sure that your SSL certificate includes all intermediate certificates in the chain of trust as our SSL validation is strict. You can use third-party SSL analysis tools (e.g., https://www.ssllabs.com/index.html) to check your certificate status and fix any errors (and warnings). If your SSL certificate has problems, you may see "Empty response received" error when you load your FBML canvas app.