Best Practices – HARICA https://www.harica.gr/ Hellenic Academic and Research Institutions Certification Authority Thu, 15 Oct 2026 04:05:40 +0000 en-US hourly 1 https://wordpress.org/?v=7.1.3 Best Practices for Code Signing Certificates https://www.harica.gr/en/posts/post-5682 Tue, 01 Mar 2022 09:00:50 +0000 https://d6e22a41ec31e3639b464.admin.hardypress.com/?p=5682
Code Signing Certificates are used to sign applications, drivers, executables and software programs (code executed on Operating Systems and Java), so that relying parties are aware of its software publisher and can verify the integrity of the code.

The biggest issue with code signing is the protection of the private key associated with the certificate. For example, if a key is stolen, the certificate could be used to fraudulently sign malicious code and deliver an application that contains a trojan or virus that appears to originate from a legitimate software publisher, jeopardizing the software that is already signed.

It is therefore prudent for software publishers to implement policies defining how to protect private keys, who approves code signing operations and how to ensure high quality, virus-free code is signed and released to the relying parties.

Software publishers should consider the following code signing best practices when implementing their code signing process and securing the private keys associated with their signing certificates:

Minimize access to private keys
  • Allow minimal connections to computers with keys.
  • Minimize the number of users who have key access.
  • Use physical security controls to reduce access to keys.
Protect private keys with cryptographic hardware products
  • Cryptographic hardware does not allow export of the private key to software where it could be attacked.
  • Use a FIPS 140 Level 2-certified product or a Common Criteria EAL 4+
  • Use an EV code signing certificate which requires the private key to be generated and stored in hardware.
  • Keep the token physically separate from the device that hosts the code signing function until a signing session is begun.
  • If private keys will be transported, ensure that passwords are randomly generated with at least 16 characters containing uppercase letters, lowercase letters, numbers, and symbols.
Time-stamp code
  • Time-stamping allows code to be verified after the certificate has expired or been revoked. Time-stamp certificates can be issued for a maximum of 135 months which can support the signed software to be validated for up to 11 years.
Understand the difference between test-signing and release-signing
  • Test-signing private keys and certificates requires less security access controls than production code signing private keys and certificates.
  • Test-signing certificates can be self-signed or come from an internal test CA.
  • Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products; this precaution helps ensure that test certificates are trusted only within the intended test environment.
  • Establish a separate test code signing infrastructure to test-sign pre-release builds of software.
Authenticate code to be signed
  • Any code that is submitted for signing should be strongly authenticated before it is signed and released.
  • Implement a code signing submission and approval process to prevent the signing of unapproved or malicious code.
  • Log all code signing activities for auditing and/or incident-response purposes.
Virus scan code before signing
  • Code signing does not confirm the safety or quality of the code; it confirms the publisher and whether or not the code has been changed.
  • Take care when incorporating code from other sources.
  • Implement virus-scanning to help improve the quality of the released code.
Do not over-use any one key (distribute risk with multiple certificates)
  • If code is found with a security flaw, then publishers may want to prompt a User Account Control dialogue box to appear when the code is installed in the future; this can be done by revoking the code signing certificate so a revoked prompt will occur.​
  • If the code with the security flaw was issued before more good code was issued, then revoking the certificate will impact the good code as well.
  • Changing keys and certificates often will help to avoid this conflict.
Revoke stolen keys
  • Report key theft or signed malware to your issuing Certification Authority. Stolen keys or signed malicious code will require the code signing certificate to be revoked.
  • If signed code is time-stamped, then the revocation date can be selected before the time of theft. This means that any code signed before the revocation date will remain valid.
For more information, PKI Consortium provides a best practices whitepaper on Code Signing
]]>