In https://learn.microsoft.com/en-us/xamarin/android/deploy-test/signing/keystore-signature?tabs=windows, it gives an example of the signature information:
Alias name: androiddebugkey
Creation date: Aug 19, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Android Debug, O=Android, C=US
Issuer: CN=Android Debug, O=Android, C=US
Serial number: 53f3b126
Valid from: Tue Aug 19 13:18:46 PDT 2014 until: Sun Nov 15 12:18:46 PST 2043
Certificate fingerprints:
MD5: 27:78:7C:31:64:C2:79:C6:ED:E5:80:51:33:9C:03:57
SHA1: 00:E5:8B:DA:29:49:9D:FC:1D:DA:E7:EE:EE:1A:8A:C7:85:E7:31:23
SHA256: 21:0D:73:90:1D:D6:3D:AB:4C:80:4E:C4:A9:CB:97:FF:34:DD:B4:42:FC:
08:13:E0:49:51:65:A6:7C:7C:90:45
Signature algorithm name: SHA1withRSA
Version: 3
Regarding "Owner: CN=Android Debug, O=Android, C=US", O may stand for organisation, and C may stand for country.
What does CN stand for?
"CN" stands for "Common Name".
See https://docs.oracle.com/cd/E24191_01/common/tutorials/authz_cert_attributes.html for the list of all attributes of the certificate.
In Android, the CN does not have any particular significance so you can put whatever string you want, but if that certificate is used for SSL, there are some requirements: https://www.ssl.com/faqs/common-name/
Related
I have errors with my local OCSP and local certification authority when doing some OCSP stapling in Apache. My website is accessible by https without any issues (I have added the root to authorities) whatsoever but apache is returning an error :
[Fri Nov 25 19:03:09.049310 2022] [ssl:error] [pid 1001] AH01935: stapling_check_response: certificate ID not present in response!
[Fri Nov 25 19:03:09.049429 2022] [ssl:error] [pid 1001] AH01943: stapling_renew_response: error in retrieved response!
Here is the openssl s_client attempt :
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C17DC2EDAF9ABBD01FF2DC7FB5C7C2C4593047AF
Produced At: Nov 25 18:03:09 2022 GMT
Responses:
Certificate ID:
Hash Algorithm: sha256
Issuer Name Hash: 5FE12EE96C3771B8F6FA83E828A2F69067078B850E3A19B608371119E9C6AFA1
Issuer Key Hash: 1183E9B1BB88058B7A99ADD680EFB295805E61B62D9C98137B2E8B98665AD53A
Serial Number: 221D839F050959811CE852B66C532FDE69B581DB
Cert Status: good
This Update: Nov 25 18:03:09 2022 GMT
Next Update: Nov 26 10:03:09 2022 GMT
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
9e:2c:7a:55:4a:f0:ab:dc:d2:93:96:45:01:97:cf:7b:d3:81:
33:8e:0f:b9:06:d3:8c:18:c5:3b:5a:e7:a4:f2:3d:5d:2e:12:
5c:10:17:ef:5c:03:d8:20:20:99:16:02:be:8c:48:97:73:57:
16:fb:81:56:43:4f:6f:48:33:60:8b:92:e0:2f:21:de:54:84:
0e:cf:8f:f0:67:51:39:b6:8f:47:6a:2f:6b:b9:d8:b8:fa:c4:
3f:c6:6d:37:1d:48:11:19:07:84:15:d9:63:bb:5e:cb:53:ba:
1f:85:44:3f:82:dc:2a:68:7d:e9:60:70:3f:3a:5e:b2:18:fe:
d2:dc:07:22:e9:b0:0f:f2:f4:d9:69:53:98:21:3a:35:67:6f:
45:f5:b1:39:1a:d7:19:48:c2:b3:ce:cd:97:0e:de:19:18:58:
38:31:78:0f:a5:10:14:07:ac:c1:d1:0e:a7:c9:76:80:c6:58:
eb:85:ee:fa:0f:4c:ec:6c:30:ec:69:5c:34:8e:88:1d:dc:c7:
c6:a8:92:83:21:5e:d6:ee:de:9b:87:ac:6a:28:bc:b6:31:18:
cf:00:6f:0f:8e:ba:a1:30:3b:24:64:fc:1a:98:aa:72:c9:76:
f9:6e:10:18:86:09:79:58:6e:d7:4f:70:b8:db:33:a1:df:3d:
d7:45:25:39
======================================
---
Certificate chain
0 s:CN = sslvpn.local, C = FR, O = Internet Widgits Pty Ltd, OU = IT
i:CN = SSL VPN Services, C = FR, O = SSL VPN
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Nov 17 19:52:50 2022 GMT; NotAfter: Nov 17 19:52:50 2023 GMT
1 s:CN = SSL VPN Services, C = FR, O = SSL VPN
i:CN = SSL VPN Root, C = FR, O = SSL VPN Inc.
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Nov 16 00:00:00 2022 GMT; NotAfter: Dec 31 23:59:59 2029 GMT
2 s:CN = SSL VPN Root, C = FR, O = SSL VPN Inc.
i:CN = SSL VPN Root, C = FR, O = SSL VPN Inc.
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Nov 16 00:00:00 2022 GMT; NotAfter: Dec 31 23:59:59 2049 GMT
---
The certificate is as follows :
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
22:1d:83:9f:05:09:59:81:1c:e8:52:b6:6c:53:2f:de:69:b5:81:db
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = SSL VPN Services, C = FR, O = SSL VPN
Validity
Not Before: Nov 17 19:52:50 2022 GMT
Not After : Nov 17 19:52:50 2023 GMT
Subject: CN = sslvpn.local, C = FR, O = Internet Widgits Pty Ltd, OU = IT
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b0:ec:15:24:d8:06:68:1a:f8:09:ae:90:3e:2a:
9b:e2:7d:35:ec:cd:c5:cf:5b:7d:e3:ac:76:35:08:
37:01:a2:56:14:e3:34:7d:69:38:c0:e6:6e:e7:ae:
72:bd:03:f7:68:6e:ae:e6:72:c2:bf:0d:88:ad:95:
de:97:50:51:15:50:de:08:99:e7:ea:10:a3:df:89:
f5:d4:34:81:3d:79:67:ae:39:69:4a:b7:f7:34:3a:
cc:f3:a4:05:84:fc:b9:61:94:8a:50:bf:09:70:8a:
99:c0:44:5f:b8:65:d5:f9:a6:69:00:94:39:b9:bc:
08:aa:a5:23:6f:31:6b:86:14:81:45:53:23:a4:78:
ec:23:c9:45:e8:95:55:7a:44:11:95:73:fc:45:27:
e5:49:0c:ff:c6:10:24:4b:1c:6a:b0:0d:82:3c:01:
da:98:de:82:ac:4b:2d:ee:6d:17:c1:ef:9b:cd:25:
b9:b7:71:50:92:e7:9e:aa:28:55:47:f7:a7:6f:ea:
b6:d3:37:96:89:af:f4:f2:18:f3:32:a5:88:be:12:
d1:24:08:99:40:e2:ac:31:49:d5:52:c5:3e:a9:38:
4e:21:d9:28:4b:ed:90:86:62:53:f3:04:d0:5c:f8:
37:82:9c:2e:d9:7c:02:a8:1b:b3:96:3e:27:c5:e7:
40:35
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
9B:FE:4D:F9:81:90:DF:52:AB:0A:53:66:45:AA:99:06:29:95:82:7F
X509v3 Authority Key Identifier:
C1:7D:C2:ED:AF:9A:BB:D0:1F:F2:DC:7F:B5:C7:C2:C4:59:30:47:AF
X509v3 Subject Alternative Name:
DNS:sslvpn.local, DNS:*sslvpn.local, email:*******
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
Authority Information Access:
OCSP - URI:*******
X509v3 Certificate Policies:
Policy: Policy Qualifier CPS
CPS: *******
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
64:32:ed:c5:ca:6a:e8:2d:58:b7:7c:0e:0f:6b:f5:51:38:df:
42:2c:c6:13:60:26:f6:ae:13:23:be:83:95:d7:ad:88:7c:38:
dc:9f:01:61:e2:f3:5d:cf:16:b6:6e:9c:3e:76:07:ee:68:67:
17:d7:83:d2:38:b3:df:3a:cd:bb:f6:34:fd:1b:85:11:bb:a4:
06:97:a5:c0:60:81:f9:a1:40:67:70:e9:cb:d3:76:43:1c:10:
b2:1a:7c:1a:5f:3d:48:5a:ee:88:8b:fc:62:fb:c9:f3:33:ef:
bb:84:f3:14:aa:9d:4c:ac:52:d0:da:c8:48:1d:c8:8b:bb:34:
cf:b9:41:28:95:21:ae:76:b2:42:5b:ed:89:fa:6c:3a:a2:8a:
66:ad:af:2d:ae:f3:fa:6d:fb:2f:2d:56:75:d4:9e:b3:88:90:
c2:4c:c2:cf:f5:b8:2d:75:45:22:6d:ed:6c:46:36:ad:a7:fa:
dd:13:e5:b0:f0:c2:24:13:8b:08:ef:65:4b:82:08:62:a6:9b:
06:e5:63:25:f0:2e:fc:87:9c:f7:8e:5a:42:6a:a6:99:90:c9:
3d:06:be:c1:15:1d:92:b0:38:d7:0d:fe:68:43:41:f6:63:5c:
62:9e:9a:0a:0f:68:f1:4a:bb:d4:3a:b2:50:2e:d1:5c:1c:54:
51:46:df:70
-----BEGIN CERTIFICATE-----
MIIEVDCCAzygAwIBAgIUIh2DnwUJWYEc6FK2bFMv3mm1gdswDQYJKoZIhvcNAQEL
BQAwOjEZMBcGA1UEAwwQU1NMIFZQTiBTZXJ2aWNlczELMAkGA1UEBhMCRlIxEDAO
BgNVBAoMB1NTTCBWUE4wHhcNMjIxMTE3MTk1MjUwWhcNMjMxMTE3MTk1MjUwWjBU
MRUwEwYDVQQDDAxzc2x2cG4ubG9jYWwxCzAJBgNVBAYTAkZSMSEwHwYDVQQKDBhJ
bnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxCzAJBgNVBAsMAklUMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsOwVJNgGaBr4Ca6QPiqb4n017M3Fz1t946x2
NQg3AaJWFOM0fWk4wOZu565yvQP3aG6u5nLCvw2IrZXel1BRFVDeCJnn6hCj34n1
1DSBPXlnrjlpSrf3NDrM86QFhPy5YZSKUL8JcIqZwERfuGXV+aZpAJQ5ubwIqqUj
bzFrhhSBRVMjpHjsI8lF6JVVekQRlXP8RSflSQz/xhAkSxxqsA2CPAHamN6CrEst
7m0Xwe+bzSW5t3FQkueeqihVR/enb+q20zeWia/08hjzMqWIvhLRJAiZQOKsMUnV
UsU+qThOIdkoS+2QhmJT8wTQXPg3gpwu2XwCqBuzlj4nxedANQIDAQABo4IBNjCC
ATIwHQYDVR0OBBYEFJv+TfmBkN9SqwpTZkWqmQYplYJ/MB8GA1UdIwQYMBaAFMF9
wu2vmrvQH/Lcf7XHwsRZMEevMD0GA1UdEQQ2MDSCDHNzbHZwbi5sb2NhbIINKnNz
bHZwbi5sb2NhbIEVY2VydHNAc2VjdXJlbXl2cG4uY29tMAwGA1UdEwEB/wQCMAAw
DgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMDcGCCsGAQUFBwEB
BCswKTAnBggrBgEFBQcwAYYbaHR0cDovL3NlY3VyZW15dnBuLmNvbS9vY3NwMEUG
A1UdIAQ+MDwwOgYIKwYBBQUHAgEwLjAsBggrBgEFBQcCARYgaHR0cDovL3NlY3Vy
ZW15dnBuLmNvbS9jZXJ0cy9jcHMwDQYJKoZIhvcNAQELBQADggEBAGQy7cXKaugt
WLd8Dg9r9VE430IsxhNgJvauEyO+g5XXrYh8ONyfAWHi813PFrZunD52B+5oZxfX
g9I4s986zbv2NP0bhRG7pAaXpcBggfmhQGdw6cvTdkMcELIafBpfPUha7oiL/GL7
yfMz77uE8xSqnUysUtDayEgdyIu7NM+5QSiVIa52skJb7Yn6bDqiimatry2u8/pt
+y8tVnXUnrOIkMJMws/1uC11RSJt7WxGNq2n+t0T5bDwwiQTiwjvZUuCCGKmmwbl
YyXwLvyHnPeOWkJqppmQyT0GvsEVHZKwONcN/mhDQfZjXGKemgoPaPFKu9Q6slAu
0VwcVFFG33A=
-----END CERTIFICATE-----
Why apache returns this error ?
After many researches, I have understand the issue.
During a request, Apache and browsers use SHA-1 hash to computer issuer key hash and issuer key name like this :
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 467F6C7AF3946017DA85E1ACE9BA717A2CCEF939
Issuer Key Hash: C17DC2EDAF9ABBD01FF2DC7FB5C7C2C4593047AF
Serial Number: 094E315FA6ADB9BC3EA20564A7B22EE6EBAA55E0
This is due to RFC 5280. However my OCSP was hashing using SHA-256 so the issuer name hash and key hash was different. It was not a big issue for Firefox as it was not checking this but Apache stapling is checking issuer key hash and therefore was returning an error.
My return :
Certificate ID:
Hash Algorithm: sha256
Therefore you should extract the algorithm from OCSP request to computer hashes for the OCSP response. However, it is recommended to use SHA256 to compute the private key signature hash because SHA1 is not considered secure.
Changing the hash algorithm deletes Apache error and stapling is working fine.
I'm switching my CI process from producing APK files to App Bundles. One stage in my pipeline will, after producing the signed binary, dump the signature and validate the signature on the APK to make sure it's signed properly before continuing.
> apksigner verify --print-certs my-signed-binary.apk
Signer #1 certificate DN: CN=<NAME>, OU=<GROUP>, O=<COMPANY>, L=<CITY>, ST=<STATE>, C=<COUNTRY>
Signer #1 certificate SHA-256 digest: <DIGEST1>
Signer #1 certificate SHA-1 digest: <DIGEST2>
Signer #1 certificate MD5 digest: <DIGEST3>
Is there an equivalent to dump the signature on the overall App Bundle once it's been produced?
I tried using jarsigner, but ended up with hundreds of lines of output.
> jarsigner -verbose -verify -certs my-signed-binary.aab
...
smk 12 Wed Dec 31 16:00:00 PST 1969 base/assets.pb
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
smk 85 Wed Dec 31 16:00:00 PST 1969 base/native.pb
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
smk 2075002 Wed Dec 31 16:00:00 PST 1969 base/resources.pb
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
542451 Tue Jan 01 00:00:00 PST 1980 META-INF/MYAPP.SF
1390 Tue Jan 01 00:00:00 PST 1980 META-INF/MYAPP.RSA
s k 542352 Tue Jan 01 00:00:00 PST 1980 META-INF/MANIFEST.MF
>>> Signer
X.509, CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY> (myapp)
[certificate is valid from 5/31/13 1:27 PM to 10/16/40 1:27 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
- Signed by "CN=<NAME>, OU=<GROUP>, O=<ORGANIZATION>, L=<CITY>, ST=<STATE>, C=<COUNTRY>"
Digest algorithm: SHA-256
Signature algorithm: SHA256withRSA, 2048-bit key
jar verified.
Is the very last part of this ("Signed by...") the signature of the overall App Bundle? Is there an easier way to get the signature of the App Bundle than hacking this output with sed?
I used keytool and I think it produces correct results
keytool -printcert -jarfile my-signed-binary.aab
I am trying to set up an HTTPS server with client certificate authentication using the Play Framework (2.7). But the client authentication always fails with unable to find valid certification path to requested target.
The client certificate is signed by a custom certificate authority that uses a self-signed certificate. In my setup, this custom CA is the only CA that the server should trust.
In application.conf I added the following configuration to set up the HTTPS server and to replace the default trust store with the custom CA certificate.
play {
server {
https {
keyStore {
path = "/path/to/store",
password = "password",
type = "PKCS12"
}
needClientAuth = true
}
}
}
ssl-config {
trustManager = {
stores = [
{ type = "PEM", path = "path/to/ca/certificate" }
]
}
}
With debug enabled, when the application is initializing, I see the custom CA certificate is loaded :
adding as trusted cert:
Subject: EMAILADDRESS=ca#mydomain.com, CN=CustAuth, O=MyOrg, L=City, ST=12345, C=FR
Issuer: EMAILADDRESS=ca#mydomain.com, CN=CustAuth, O=MyOrg, L=City, ST=12345, C=FR
Valid from Wed Jul 06 15:38:40 CEST 2005 until Tue Jul 01 15:38:40 CEST 2025
However, I also see the following lines a little further in the logs :
trustStore is: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts
trustStore type is : jks
trustStore provider is :
init truststore
I did not expect nor want the server to use the default JRE trust store. How can I completely disable it ?
Anyway, that should not stop the server to authenticate correctly the client - unless the trust store gets completely overridden (I hope that is not the case but I haven't proven it so far).
When the client connects, I see in the logs that its certificate is correctly read :
chain [0] = [
Subject: EMAILADDRESS=devnull#mydomain.com, CN=My User, OU="User#41183", O=MyOrg, C=FR
Validity: [From: Thu Jan 11 10:17:12 CET 2018, To: Tue Jan 10 10:17:12 CET 2023]
Issuer: EMAILADDRESS=ca#mydomain.com, CN=CustAuth, O=MyOrg, L=City, ST=12345, C=FR
]
chain [1] = [
Subject: EMAILADDRESS=ca#mydomain.com, CN=CustAuth, O=MyOrg, L=City, ST=12345, C=FR
Validity: [From: Wed Jul 06 15:38:40 CEST 2005, To: Tue Jul 01 15:38:40 CEST 2025]
Issuer: EMAILADDRESS=ca#mydomain.com, CN=CustAuth, O=MyOrg, L=City, ST=12345, C=FR
]
The client issuer matches the previously loaded custom CA certificate. However, the following error is thrown :
application-akka.actor.default-dispatcher-2, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
What do I miss or what am I doing wrong ?
Edit : I noticed that if I import the custom CA certificate into the default trust store, the authentication is working.
Edit 2 : seems to be linked to the default implementation of the SSL engine provider :
2019-04-08 13:21:46 +0200 [DEBUG] from play.core.server.ssl.DefaultSSLEngineProvider in application-akka.actor.default-dispatcher-3 - Using default trust store for client side CA verification
Custom SSL engine provider must be set, see docs since DefaultSSLEngineProvider supports only play.server.https.trustStore.noCaVerification = (true|false) and fallback to default JVM trust store.
Don't be confused with some log messages and better debug the app. Your CA is loaded but to other SSL context than you need.
I had slightly different problem and ended up with overriding JVM cacerts because Play config does not provide me configuration I need.
I have been attemping to code sign a dll using a code signing certiticate I have purchased from Comodo. The intention for the signing is to be verifiable via the kernel signing policy. However, in the the EventLog explaining that there are CodeIntegrity errors relating to per-page image hashes not being able to be found.
Below is a summary I what I am doing, if you could please provide advice on where I have gone wrong, or where to look next that would be greatly appreciated.
I have signed a previously signed dll for the sake of testing using the following commands, the result is the same if I used a newly built dll.
"C:\WinDDK\7600.16385.1\bin\amd64\SignTool.exe" sign /v /ph /ac "addtrustexternalcaroot_kmod.crt" /f css-certificate.pfx /p <password> /t http://timestamp.verisign.com/scripts/timstamp.dll VBoxVRDP.dll
The output is as follows
The following certificate was selected:
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Cross certificate chain (using machine store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 05:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 12:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Done Adding Additional Store
Successfully signed and timestamped: VBoxVRDP.dll
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
I now validate the signing using the following command
"C:\WinDDK\7600.16385.1\bin\amd64\SignTool.exe" verify /v /ph /kp VBoxVRDP.dll
The output is as follows
Verifying: VBoxVRDP.dll
Hash of file (sha1): 41909BD87A05CF3E61BBEF7B9DD4C4A8B6E4B2A1
Signing Certificate Chain:
Issued to: AddTrust External CA Root
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: 02FAF3E291435468607857694DF5E45B68851868
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
The signature is timestamped: Mon Dec 15 10:05:37 2014
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 15:59:59 2020
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Wed Dec 30 15:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Tue Dec 29 15:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 05:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 12:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250
Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 02:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0
Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 15:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47
Issued to: S4 Technology
Issued by: COMODO RSA Code Signing CA
Expires: Wed Nov 11 15:59:59 2015
SHA1 hash: 0161DC2D8757B886E626B25B1770C72B789BAF02
Embedded page hashes:
0x00000000 7B54C3ABC3FC7DA85CB40074D653DFB36DF8E0F9
<...>
0x00071a00 0000000000000000000000000000000000000000
Successfully verified: VBoxVRDP.dll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
So it all looks good, however, I have noted when looking at the properties of dll via Explorer, but I end up with a CodeIntegrity errors in the EventLog.
Code Integrity is unable to verify the image integrity of the file <...>\VBoxVRDP.dll because the set of per-page image hashes could not be found on the system.
When I look at the Verbose logs of CodeIntegrity I see the following Verbose events
Code Integrity started validating page hashes of <...>\VBoxVRDP.dll file.
Code Integrity completed validating page hashes. Status 0xc0000428.
From what I can tell 0xc0000428 is Windows cannot verify the digital signature of this file, which seems to imply I am missing something somewhere, but I for the life of me cannot figure out exactly what it is I need to do.
Windows support for SHA2 on Win 7 seems to be problematic at present. https://technet.microsoft.com/en-us/library/security/2949927.aspx
There is a fix but note "Revision V2.0 (October 17, 2014): Removed Download Center links for Microsoft security update 2949927. Microsoft recommends that customers experiencing issues uninstall this update. Microsoft is investigating behavior associated with this update, and will update the advisory when more information becomes available."
When run keytool on a .RSA file for an Android APK I see the following:
Serial number: 4a9c4610
Valid from: Mon Aug 31 14:52:16 PDT 2009 until: Sun Sep 25 14:52:16 PDT 2050
Certificate fingerprints:
MD5: 3F:AD:02:4F:2D:CB:E3:EE:69:3C:96:F3:50:F8:E3:76
SHA1: 8A:3C:4B:26:2D:72:1A:CD:49:A4:BF:97:D5:21:31:99:C8:6F:A2:B9
Signature algorithm name: MD5withRSA
Version: 1
Why does it show both SHA1 and MD5 fingerprints even though the algorithm name seems to suggest MD5?
If the question is better answered by me reading some introductory article on this topic, feel free to point me to it.
The fingerprint is simply a hash of parts of the certificate data. It's not related to the hash used in the signature mechanism, so it doesn't have to be MD5.