keytool -list shows different aliases for p12 keystore, depending on whether you provide the password - alias

Really weird behaviour on a particular p12 file.
If I run
keytool -list -storetype pkcs12 -keystore my_debug_keystore.p12 -storepass debug
keytool -v -list -storetype pkcs12 -keystore my_debug_keystore.p12 -storepass debug
I get,
Alias name: 1
Creation date: Aug 17, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=sixminute, OU=, O=, C=IE
Issuer: CN=sixminute, OU=, O=, C=IE
Serial number: xxxxxxxxxxxxxxxxx
Valid from: Wed Nov 07 13:34:40 GMT 2012 until: Sun Nov 08 13:34:40 GMT 2037
Certificate fingerprints:
MD5: xxxxxxxxxxxxxxxxx
SHA1: xxxxxxxxxxxxxxxxx
Signature algorithm name: SHA1withRSA
Version: 3
and
Your keystore contains 1 entry
1, Aug 17, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): xxxxxxxxxxxxxxxxx
However, if I don't provide the password in the commands,
keytool -list -storetype pkcs12 -keystore my_debug_keystore.p12
keytool -v -list -storetype pkcs12 -keystore my_debug_keystore.p12
the output is different,
Alias name: 2
Creation date: Aug 17, 2014
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=sixminute, OU=, O=, C=IE
Issuer: CN=sixminute, OU=, O=, C=IE
Serial number: 2d36623161363935353a31336165303361636133313a2d38303030
Valid from: Wed Nov 07 13:34:40 GMT 2012 until: Sun Nov 08 13:34:40 GMT 2037
Certificate fingerprints:
MD5: xxxxxxxxxxxxxxxxx
SHA1: xxxxxxxxxxxxxxxxx
Signature algorithm name: SHA1withRSA
Version: 3
and
Your keystore contains 1 entry
2, Aug 17, 2014, PrivateKeyEntry,
Certificate fingerprint (MD5): xxxxxxxxxxxxxxxxx
Specifically a different alias for the same key (the MD5 and SHA1 are still the same for the keys).
Any idea at all why this would be the case?

Aliases are not quite a PKCS 12 concept. There is a Friendly Name attribute but it is very optional. So I would guess that Java is just making up the Alias names it reports. No idea why it would be different though, as the safe bag order should be the same.

Related

Create a keystore with a CA-signed PrivateKeyEntry

I would like to refresh a small Java keystore, updating dates to 10 years in the future.
My keystore contains 2 entries, seen with keytool -v -list :
Alias name: myCA
Creation date: Feb 5, 2018
Entry type: trustedCertEntry
...
Owner: contains all properties needed for myCA ...
Issuer: same properties as myCA (so self-signed certificate)
...
Alias name: myHost
Creation date: Feb 5, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=myhost, etc ...
Issuer: same properties as myCA
...
Certificate[2]:
Owner: same properties as myCA
Issuer: same properties as myCA
...
I only achieved to create 2 entries of type trustedCertEntry in my new keystore, I would like to create a trustedCertEntry and a PrivateKeyEntry
What commands can I do to create a myCA-signed private key and add it to the new keystore ?
PS will peers which are today validating myCa sefl-signed certificate validate the new one if I only use the same properties for myCA ? is it enough ?
With patience ....
openssl pkcs12 -export -out temp.p12 -inkey myHost.key -in myHost.crt -certfile myCA.crt
keytool -v -importkeystore -srckeystore temp.p12 -srcstoretype PKCS12 -destkeystore mystore

What does CN stand for in a mobile app apk signature information?

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/

Unable to add CA cert [crt] to JKS as PrivateKeyEntry

Below is my current JKS
bash-3.2$ keytool -list -keystore /web/myfolder/maincert.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 4 entries
root, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
maincert, Aug 1, 2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): A0:BF:8A:61:D7:AE:82:A6:EE:4B:EB:E0:22:19:73:2E:FC:85:F8:AC
intermediate2, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 70:60:8B:40:D0:B7:76:17:4A:4E:D8:54:16:58:27:70:B3:07:B9:05
intermediate1, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): EA:B0:40:68:9A:0D:80:5B:5D:6F:D6:54:FC:16:8C:FF:00:B7:8B:E3
I then deleted the "maincert" using this command
keytool -delete -alias maincert -keystore /web/myfolder/maincert.jks
Then i added the CA signed new cert [maincert.crt_2018] with the same old alias name as shown below:
keytool -import -file /web/myfolder/maincert.crt_2018 -alias maincert -keystore /web/myfolder/maincert.jks
But the new cert now shows as trusted entry in the JKS instead of PrivateKeyEntry like before. Please see below:
bash-3.2$ keytool -list -keystore /web/myfolder/maincert.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 4 entries
root, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68
maincert, Aug 28, 2018, trustedCertEntry,
Certificate fingerprint (SHA1): D2:7F:D0:86:79:0D:F3:06:66:C4:09:2E:29:A0:8F:8A:F3:E2:09:10
intermediate2, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): 70:60:8B:40:D0:B7:76:17:4A:4E:D8:54:16:58:27:70:B3:07:B9:05
intermediate1, Aug 1, 2017, trustedCertEntry,
Certificate fingerprint (SHA1): EA:B0:40:68:9A:0D:80:5B:5D:6F:D6:54:FC:16:8C:FF:00:B7:8B:E3
Can you please suggest what is the problem here ?
The issue was that the crt certificate file was corrupt.
With the correct crt I did not have to delete anything from the JKS ... simply adding the crt worked and now it shows PrivateKeyEntry

Export trusted certificates from jks file to .pem and get the private key as .pem

I have a 'test6r.jks' file which conatins 1 private key and 3 trusted certs I would like to get 3 crts as public.pem and private key as private.pem
keytool -list -keystore test6r.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 4 entries
symantecclass3secureserverca-g4, Mar 25, 2015, trustedCertEntry,
Certificate fingerprint (SHA1):
FF:67:36:7C:5C:D4:DE:4A:E1:8B:CC:E1:D7:0F:DA:BD:7C:86:61:35
verisignsvrg3, Mar 25, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 5D:EB:8F:33:9E:26:4C:19:F6:68:6F:5F:8F:32:B5:4A:4C:46:B4:76
verisignroot, Mar 25, 2015, trustedCertEntry,
Certificate fingerprint (SHA1): 4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
test6r, Nov 9, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): C9:E4:A7:CB:A1:31:89:DA:EE:59:A3:50:CD:0E:04:7D:36:6B:23:CB
How do I export trusted certificates from jks file to .pem and get the private key as .pem?

CodeSigning results in 'Code Integrity completed validating page hashes. Status 0xc0000428.'

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."