I have a program that create self-sign certificate of RSA algorithm.
The problem is that if I create certificate of RSAES OAEP parameters,
when I open the certificate I see that the size of the public key is 0 bits .
Do anyone know what is the problem?
I already checked that the ASN 1.0 Encoding of the RSA OAEP Pararmeters is ok.
And if I create certificate RSA without OAEP Parameters than the size of the public key is present ok (not as 0 bits).
I checked in the internet and I didn’t find any certificate of RSA with OAEP pararms for example to compare with my certificate.
I will be glad for any suggestion.
This is the certificate in PEM File:
-----BEGIN CERTIFICATE-----
MIIFyzCCA7OgAwIBAgIDMaTyMA0GCSqGSIb3DQEBBAUAMG0xETAPBgNVBAMTCFN0YW0gSXNo
MRQwEgYDVQQHEwtQZXRhaCBUaWt2YTEPMA0GA1UECBMGSXNyYWVsMQwwCgYDVQQKEwNBUlgx
FjAUBgNVBAsTDVByaXZhdGVTZXJ2ZXIxCzAJBgNVBAYTAklMMB4XDTAwMDEwMTEwMDAwMFoX
DTk5MTAxMzIxNTYxNVowbTERMA8GA1UEAxMIU3RhbSBJc2gxFDASBgNVBAcTC1BldGFoIFRp
a3ZhMQ8wDQYDVQQIEwZJc3JhZWwxDDAKBgNVBAoTA0FSWDEWMBQGA1UECxMNUHJpdmF0ZVNl
cnZlcjELMAkGA1UEBhMCSUwwggJnMFIGCSqGSIb3DQEBBzBFoA8wDQYJYIZIAWUDBAIBBQCh
HDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAIBBQCiFDASBgkqhkiG9w0BAQkEBVRDUEEAA4IC
DwAwggIKAoICAQCizEvm86uS4/f8e7EC81OqNK+fIoCWOYJdc7iDNEbI+7l9C/zD//KiETMD
x1V4WgBXvhokc05a0oLdJ8MlcTFUGsmrX8mxesGnY87wVeJBJ+jPQipZ+ZoA16U9d4xOQU8b
erXUf+w6VFwoL4M3jLyL2lspHiMJPagsukxjzh1Dj/xA6tIVsSnJkffDyRC9l267pP1mXi2u
vAT4zhSX1FLtoO3XkJ0pJarIyJeTnBLMQ5ga1gnDmUFve4tI/cLbb9fxeTF7zA+XNrTTdYrY
9zkiMXBvnT7h0ZpGhfvobC7ULbmO/XyR3tVmuMoTu9mwNgjwCgp5f5Jt7cZbUJNbBateglcv
+Gb9FjFjneCRU4adN87GpyAMfclq5MIO+KCoRWSDRbL/6exYMf0sE3g4ARSru/7Wm82xITNA
fRn2qDErR421SiiuwkIlh97eiyfYeEb+n5eSOr1Qscr+tXOpEuArBDPzg0g5fo0dgomAVZvK
hwfOS+URUmobRPuUN5ecB4dALBJkkN02qaGkCXZmzWicnheXmhTYe3og0fQpajFXUwgwguXl
CDfy91Tn9PBYdRs0G0/gkiRABTP3sZvG3ru9I20W9tdfvN3NssBb+2AadRhSvpgP1wkHIVmZ
/VOQN893TdmaS+WQOiocxh2LxJv7QeC8j8fi9k8LTeM4JCqJ0wIDAQABoy8wLTArBgNVHRAE
JDAigA8xOTk4MDEwMTA4MDAwMFqBDzIwMDAwMTAxMDgwMDAyWjANBgkqhkiG9w0BAQQFAAOC
AgEAODPOHhl4J519jEExA2TIwSWLC23lloBQQPJysE0gelbyTv3xGVmJJZF+JAGvxrkvYado
UMPc9pBF57RsB7tznhCHpcYpSRcEIEArZoxfiVkevheLsm9/gyd5RA/oD6xx8WZBFFjHW+fs
urdJPEfR0lBHGmOKBKTa9aeqwJ5Bfi6Rm6/OvbalWBgZh2+5KYhdtMZH7JnsCCR6ZrJzLp8D
uo5M0iIQ/J6D9pDsPBmYK3/P/c7mVhLhjUBtqelkRGO690VzoBykf9MsWE3IT58gq1Av3dGe
J1LSgijha65s/A+l7zEC0fL7UFSXUnNCghEz+PkpcO14wFeg9UIypM0R85IOO0PBg4FVLACT
hmBmFFJCDOCgMwO+xMQZE+eG5gOEUgESHaQfEUoU7JxPHYB/9Xxl2G69nHr2Fx0KuLrjnrym
SgrFubQ3d+XuSTLxr/Lr7gl7EZP68uEsPcw2CXXdpsq4pvmVbrNspfHGn9SimFkEA8qmPqkt
4wiUPCwLkvY+qZ55JnmtPWoeaekJDx7iox0TtiHlQH6Y+/Rl18zU0lITePKPbc5thPZjiwIl
rR5O1PYzlIzE9m/7mFNitIAR2CixJRNiykgz5Q2gjYu4itmb2aHE1UuzK2mORny2gYnG7mdr
dD2y8hDouRCuxND/kkfdDyspGSRQcnqnmpkt7nQ=
-----END CERTIFICATE-----
Public key is 4096 bits long in the attached certificate. Using MD5 hash with 4k keys is very strange combination as MD5 hash is too weak and all strength of 4k key is eliminated by weakness of a hash.
Related
I working on a project that uses JSON Web Tokens (JWT). I already have the code that creates the token that is signed by an RSA algorithm which was created by the openssl genrsa -des3 -out <private key file name>.pem 3076. I want to check the validity of the tokens I produce on the jwt.io website, but i need "[public/private] Key in...X.509 certificate, or JWK string format".
Format of private key:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,4AE3D092CB847166
(The actual key)
-----END RSA PRIVATE KEY-----
Format of public key:
-----BEGIN PUBLIC KEY-----
(The actual key)
-----END PUBLIC KEY-----
Is there any command/tools that can be used to convert these into X.509 certificates or JWK strings?
I have already tried using the openssl x509 -in <public or private key file name>.pem -inform PEM -out <X509 certificate file name>.der -outform DER command.
That would always return this error:
unable to load certificate
140258002609472: error: 0909006C: PEM routines: get_name:no start line:../crypto/pem/pem lib.c:745: Expecting: TRUSTED CERTIFICATE
All of the commands have been run using the terminal from a replit project. I am not sure if that plays a role or not but I mention it just in case.
Do you use Windows? Check the encoding. Change to UTF-8 through the Notepad and create it.
How to find issuer from X509 certificate String (example given below) in flutter.
Thanks in advance.
-----BEGIN CERTIFICATE-----
MIICiTCCAjCgAwIBAgIUD3Kab5X9kqd9qN1fqB61TUlwbO0wCgYIKoZIzj0EAwIw
cDELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9saW5hMQ8wDQYDVQQH
EwZEdXJoYW0xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh
Lm9yZzEuZXhhbXBsZS5jb20wHhcNMjIxMDA2MTE0NzAwWhcNMjMxMDExMTAwNzAw
WjBHMTAwCwYDVQQLEwRvcmcxMA0GA1UECxMGY2xpZW50MBIGA1UECxMLZGVwYXJ0
bWVudDExEzARBgNVBAMTCnVzZXJUZXN0MDEwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAAQHJXgfHfQ8hDedBuSrthP9B6MB+f1W1FqfecFvvaOYlEsPHrSqATkVNQJ2
2tBxxKTwo7XF2gVqYn7QPUHqwVtgo4HQMIHNMA4GA1UdDwEB/wQEAwIHgDAMBgNV
HRMBAf8EAjAAMB0GA1UdDgQWBBQsiq8NZZh74PK/sMLfhWCq4IbMLjAfBgNVHSME
GDAWgBQdmRqOkqYG/lmxlNopkD99+TOH0jBtBggqAwQFBgcIAQRheyJhdHRycyI6
eyJoZi5BZmZpbGlhdGlvbiI6Im9yZzEuZGVwYXJ0bWVudDEiLCJoZi5FbnJvbGxt
ZW50SUQiOiJ1c2VyVGVzdDAxIiwiaGYuVHlwZSI6ImNsaWVudCJ9fTAKBggqhkjO
PQQDAgNHADBEAiBENbsQCzjg2vux5CWH9S8Xhg9fH2OBF9JZGSibwc4EHAIgBUEo
xQ5UhoNGZtArxDWA97ab7GspkeVF+6wwdakBRlM=
-----END CERTIFICATE-----
tried to decode x509 certificate PEM string, using x509b package, after that generated x509Certificate object from the giving PEM string.
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 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 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.