Code Signing Requires Four Different Components for the Code Signing Architecture

As a software developer, you know the role of a code signing certificate, how important it is, and how helpful it is to provide trust to the users. If you have purchased a code signing certificate, then it won’t be new to say what’s the process to get one and how this Code Signing Certificate Works.

But, today, we’ll dig a little deeper to understand the architecture of a code signing certificate and the sets of components that are responsible for the code signing process. You might know the basics, but let’s explore it for the ones who don’t.

A code signing architecture has four different components

• Code Signing System (CSS)
• Certification Authorities (CA)
• Time Stamp Authority (TSA)
• Verifiers

Let’s look at each one in order…

1. Code Signing System (CSS)

The code signing system (CSS), the first component of the process, is where the code is actually signed. Typically, code goes through a series of steps such as authentication and authorization of the one who submitted code, then finally, generation of the signature. To generate the signature, the code signing system uses a certificate and a private signing key, which is kept securely to prevent unauthorized usage.

2. Certificate Authorities (CAs)

The code signing system relies on the developer having a certificate issued by Certificate Authorities such as Sectigo. To get a certificate, the developer will need to purchase the certificate and submit documents for validation. And, once all the information and details are provided, (it’s for the security controls and practices that CAs need to follow) the CA issues a code signing certificate.

The requirements mandated by the CA for issuing a code signing certificate, are based on guidelines from the CA/Browser Forum and the CA Security Council, who specify the required documents that are needed for the issuance of a code signing certificate.

3. Time Stamp Authority (TSA)

Code Signing process and architecture involves the use of a time stamp authority (TSA). Although this part is optional it’s recommended. A TSA is used for specifying at what time and date a piece of code are signed. This is so the signature will be valid even after the certificate has expired. Whenever a Time Stamp Authority (TSA) is used, the signature is sent to it. Then the TSA applies its signature along with the signing time to be added to the software package or other executable files.

Code Signing process and architecture involves the use of a time stamp authority (TSA). Although this part is optional it’s recommended. A TSA is used for specifying at what time and date a piece of code is signed. This is so the signature will be valid even after the certificate has expired. Whenever a Time Stamp Authority (TSA) is used, the signature is sent to it. Then the TSA applies its signature along with the signing time to be added to the software package or other executable files.

Know what is Code Signing Time Stamping?

4. Verifiers

Once your software package or executable file is signed and timestamped, any client that attempts to use the file will first attempt to verify the signature. As a developer, it’s recommended that you verify the signature yourself before publishing the file.

The clients or verifiers manage trust anchors that are used for validating certificates.

Trust Anchors

Verifiers use trust anchors for validating the signature, generally by verifying issued code signing certificates.

Trust anchors are typically public keys for root certificates that are installed and securely stored on the verifying platform. For example, a self-signed root certificate using standard X.509 architecture works as a trust anchor for applications, if that certificate is included in the verifier’s trust store. A web browser like Google Chrome and Mozilla Firefox and operating systems also provide the list of their trust anchors.

These trust anchors do not verify code directly, but they’re public keys of root CAs which are used for signing code signing certificates of CAs like Sectigo or DigiCert.

Closing Thoughts

We hope this article gives you a better understanding of how code signing certificates work, while making you aware about the different components involved to make the signing of an executable file or software package successful. In the end, the goal is to assure users that the signed file they’re downloading or installing is trustworthy, genuine, and coming from the original publisher without being tampered with.