25 January 2019

Goal

The goal is to get a Code Signing certificate to sign legacy Java Applets. Current signatures are based on expired code signing certificate. Code Signing works by signing your code with a private key which can then be verified using a public key. Private keys are secret and public keys are not.

Process Overview

Using the Java utility “keytool” we generate a Certificate Signing Request (CSR). A CSR is a text file you provide to a Certificate Authority (CA) that contains a public key and other information. There is also a private key that is stored in the “.keystore” file located on the server/workstation where you generated the CSR. CAs are organizations that provide your public keys to others. They do this by signing your public key with their private key. They then give out their public key to responsible parties. These responsible parties in practice turn out to be those who make your browsers. Organizations like Microsoft, Google and Firefox.

Overview of CSR and Signed Code Process

Walk Through

Using the “keytool” provided by the Java JDK we generate a CSR. This command will store the information into your default keystore. It is possible to specify a different keystore. My default keystore was /home/chris/.keystore.

terminal on Linux workstation


[chris@workstation Downloads]$ keytool -genkey -keyalg RSA -sigalg SHA256withRSA -keysize 2048 -alias 20190111_MYKEY
Enter keystore password:  
Re-enter new password:
What is your first and last name?
  [Unknown]:  Chris Smith
What is the name of your organizational unit?
  [Unknown]:  IT
What is the name of your organization?
  [Unknown]:  Fake Company Name
What is the name of your City or Locality?
  [Unknown]:  NoWhere
What is the name of your State or Province?
  [Unknown]:  KY
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=Chris Smith, OU=IT, O=Fake Company Name, L=NoWhere, ST=KY, C=US correct?
  [no]:  yes

Enter key password for <20190111_MYKEY>
	(RETURN if same as keystore password):  

Warning:
The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /home/chris/.keystore -destkeystore /home/chris/.keystore -deststoretype pkcs12".
[chris@workstation Downloads]$ 

Now we print out the CSR so that we can go to the CA website and place our request.

terminal on Linux workstation

[chris@workstation Downloads]$ keytool -certreq -alias 20190111_MYKEY
Enter keystore password:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBpDCCAQ0CAQAwZDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAktZMRAwDgYDVQQHEwdGdCBLbm94
MRAwDgYDVQQKEwdVUyBBcm15MQ4wDAYDVQQLEwVVU0FBQzEUMBIGA1UEAxMLQ2hyaXMgTHluY2gw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJm3jUy+0erLXhJdwKy7ceNAj7mJywyo0jA9nkM0
...redacted...
i4Db6fuKjYDpJBZeQ6BP7tdDqiyaOD0Ag1gfIfMtacuJ3kCS83VSrYIzAgMBAAGgADANBgkqhkiG
9w0BAQQFAAOBgQBkJq9n+/Oytwd9GTiaGLxwULTUHhghIBypQPV0AXqrHCCQ4mY2qjaCWXVh8r6D
+uWqSNWuLvGQIo+Nl8x/ixJ/FX6NTirN1gTeHUy3UO+a8XHL1KHoj05cC4qz27AWXocBMWmFLraK
VCO7xZxKf1L91gngIitdeH380Sv00wCuWQ==
-----END NEW CERTIFICATE REQUEST-----

Placing the request using a secure browser connection you would cut and past the certificate including the starting and ending lines with the hypens. We were provided two options when placing the request. “SHA256 with root SHA1” and “SHA256 with root SHA256”. This means do you want your CA to sign your key with SHA1 or SHA2. SHA1 is no longer considered secure enough. Strangely enough SHA1 was still the recommended option. I guess that it is still the most widely supported. We chose the second option. Once you place your request the CA will verify who you are and if you are allowed to place the request. This process can be quite involved for government agencies.

One you are verified, they will provide you a certificate to import into your local keystore. I trusted my CA so I answered yes to the “not trusted” question.

terminal on Linux workstation

[chris@workstation]$ keytool -import -alias 20190111_MYKEY -file ssl_certificate.p7b
Enter keystore password:  

Top-level certificate in reply:

Owner: CN=Symantec Class 3 SHA256 Code Signing CA - G2, OU=Symantec Trust Network, O=Symantec Corporation, C=US
Issuer: CN=VeriSign Universal Root Certification Authority, OU="(c) 2008 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
Serial number: 7c1b35354ae7db74e7415f1169ca6ba8
Valid from: Mon Jul 21 20:00:00 EDT 2014 until: Sun Jul 21 19:59:59 EDT 2024
Certificate fingerprints:
	 MD5:  B9:02:47:5B:09:77:5C:59:1A:C1:FF:55:38:01:11:B1
	 SHA1: 13:92:E4:C7:FF:25:B9:51:7E:93:10:FF:BB:E2:66:4D:C8:7E:F7:0D
	 SHA256: 20:42:E3:8F:C5:73:88:F1:DB:32:22:FF:AB:5B:E1:1C:6E:DB:7E:45:4B:F4:54:87:AE:44:FF:2D:6A:2B:76:45
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

#1: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: ocsp
   accessLocation: URIName: http://s.symcd.com
]
]

#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: B6 77 FF 69 48 47 9F 53   12 FF C2 EA 07 32 76 07  .w.iHG.S.....2v.
0010: D1 97 07 19                                        ....
]
]

.......stuff redacted

... is not trusted. Install reply anyway? [no]:  y
Certificate reply was installed in keystore

You are ready to sign your code.


Less Is More ~ Older posts are available in the archive.