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.
Related
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/
I'm chasing a root certificate from verisign.
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary
Certification Authority
The serial# is: 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
The dates are: Jan 29 00:00:00 1996 GMT -> Aug 1 23:59:59 2028 GMT
I'm not have any success in locating this. Many VeriSign roots are listed here.
Maybe I'm missing something in my cert understanding. Shouldn't CA's be publishing their root CA's? i.e. Shouldn't they be shouting "Here are my roots. Come get em." Why am I having such a hard time finding this root cert?
If you know the serial number the certificate, or thumbprint, or SPKI, you can easily find root and intermediate certificates on crt.sh.
https://crt.sh/?id=162
This certificate is very old and is not trusted by all certificate stores these days (NSS for example). It's 1024-bit RSA with an MD2 digest. I wouldn't be surprised if Symantec / DigiCert considered this root deprecated.
I am creating SSL enabled connection between oracle 11g database (11.2.0.1), and java client using thin client jdbc driver (type 4). We are creating the client/server/root certificates using orapki utility and putting the certificates in oracle wallet.
It seems the default hash algorithm for encryption, when we create certificates using orapki utility (in oracle 11g db) is md5. This was working fine, until we upgraded to jdk1.7 u101. This version of jdk no longer supports MD5. So it seems we need to use SHA-256 as the hash algorithm. I keep getting references that oracle wallet manager 11.2.0.1+ supports SHA-256, but I cannot find any documentation on how to specify SHA-256 as the hash algorithm while creating the certificates.
Is there a way I can generate certificates through orapki/wallet manager with SHA-256 as the hash algorithm?
You can use orapki with -sign_alg sha256 to sign your certificates with sha256 instead of md5.
For example: Creating a self signed certificate used as the trusted authority
orapki wallet create -wallet ./root -pwd welcome123 -nologo
orapki wallet remove -trusted_cert_all -wallet ./root -pwd welcome123 -nologo
orapki wallet add -wallet ./root -dn CN=Certification\ Authority\ For\ Testing,\ O=MyCompany,\ C=US -keysize 2048 -self_signed -validity 7300 -pwd welcome123 -sign_alg sha256 -nologo
orapki wallet export -wallet ./root -dn CN=Certification\ Authority\ For\ Testing,\ O=MyCompany,\ C=US -cert ./root/rootcertificate.crt -pwd welcome123 -nologo
keytool -printcert -file root/rootcertificate.crt
orapki wallet display -wallet ./root -pwd welcome123 -nologo
And the output is:
Owner: CN=Certification Authority For Testing, O=MyCompany, C=US
Issuer: CN=Certification Authority For Testing, O= MyCompany, C=US
Serial number: 0
Valid from: Wed Mar 09 03:35:42 PST 2016 until: Tue Mar 04 03:35:42 PST 2036
Certificate fingerprints:
MD5: D1:EB:E4:27:FB:B1:C9:4A:CB:9D:28:A6:5A:C7:E7:20
SHA1: 39:DD:C2:4A:EA:97:BD:47:52:8C:E6:B9:2C:97:F9:F4:A8:A4:5E:85
SHA256: 04:28:19:01:AC:83:C3:69:D0:C9:1C:6A:94:08:B7:31:0C:65:21:7F:8E:FB:19:50:22:02:C4:9C:69:B1:1E:F6
Signature algorithm name: SHA256withRSA
Version: 1
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."
Hi I am a little new to all this openSSL and PEM stuf, so I thought I would ask you people here. I have a certificate in text(X509) format like this for example
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1f:19:f6:de:35:dd:63:a1:42:91:8a:d5:2c:c0:ab:12
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=Thawte SGC CA,O=Thawte Consulting (Pty) Ltd.,C=ZA"
Validity:
Not Before: Fri Dec 18 00:00:00 2009
Not After : Sun Dec 18 23:59:59 2011
Subject: "CN=mail.google.com,O=Google Inc,L=Mountain View,ST=Californ
ia,C=US"
............................................
............................................
How do I convert this into a .pem file for openssl to understand, so that I can verify certificates? Any ideas/help/suggestions would be greatly appreciated. Thanks a lot in advance to all.
Regards
Hari
If all you have is the certificate in text form (hopefully with the details of the public key modulus and exponent, and signature), you're going to have to rebuild the ASN.1 structure and its DER format (the PEM representation is the base-64 encoding of the DER form).
You'll also have to rebuild the exact list of extensions in the certificate. Most text forms I know (for example, the output of openssl x509 -text or the browser's display tool) will convert the OIDs and values of the extensions into a more human-readable format, based on the specifications describing these extensions, if known to the developers of these tools.
Doing it in the reverse order systematically more or less implies reading a large number of specifications describing the potential extensions and working out what the human-readable text coming out of these tools was representing. The PKIX RFC is one of these specifications, and it's not going to be an easy thing to read, especially if you're beginning in the field.
On top of this, you might not be able to form the ASN.1 structure in the exact same order as it was in the actual certificate. You need to be able to reconstruct the exact binary structure if you want to be able to verify the signature of the certificate.
In the general case, I'd say doing this successfully is unlikely.
EDIT: Considering what you said, you seem to be using LibNSS's certutil:
Try:
certutil -L -r -n "the-cert-nickname" -d . | openssl x509 -inform DER -outform PEM
I am not sure what you are presenting in your post.
This seems the visualization of an existing certificate.
Are you viewing it via windows? I.e. opening a .der or .cer file?
If this is the case if you go in the details tab, press copy to file and save it as pem.
If you need to save it that format that is.