How to Replace an Expired or Compromised Code Signing Certificate

Start by identifying the replacement scenario

The safest way to replace an old certificate is to decide first what happened to it. An expired certificate can often follow a normal certificate acquisition process. A compromised certificate needs incident response because the private key may have escaped the publisher's control.

Expired, revoked, lost, or compromised: the paths are different

Certificate replacement should not be treated as a single procedure. The status of the certificate and the trustworthiness of the private key determine what needs to happen next.

Assess the signing environment before making changes

A certificate rarely exists in only one place. Before removing an old certificate, map where it is used and establish why it is being replaced. Record the certificate identity, issuer, certificate type, serial number, thumbprint, expiration date, associated key, signing tools, timestamp configuration, and any automated systems that reference it.

Replacing a normally expired certificate

When a certificate simply reaches the end of its validity period, replacement is primarily a transition to a current certificate for future signing. The old certificate can remain useful for examining historical signatures, release records, and previous builds, so avoid deleting evidence before the new workflow has been verified.

Check the old certificate before removing it

Record the details that identify the old certificate and its signing environment. This matters when an organization has several certificates, several signing machines, or more than one release pipeline. The old certificate's thumbprint or serial number can also become a useful reference when checking that automation has stopped selecting it.

Obtain the replacement certificate

The replacement should match the publisher and signing requirements unless the organization is intentionally changing its identity or certificate profile. The general transition is straightforward: select the appropriate certificate, complete the required CA validation, generate or provision the key, receive the certificate, and associate it with the intended signing environment.

Should the private key change when a certificate expires?

For a normally expired certificate, the old private key may not have been compromised. Whether it can be reused depends on the CA's current requirements and the signing environment. Generating a new key is often a clean way to establish the new certificate, but the governing certificate requirements and provider workflow should decide the actual process.

That answer changes completely after a private-key compromise. A compromised key should not be reused for a replacement certificate because the problem is the secrecy of the key itself, not the metadata in the certificate.

Install or provision the new certificate across the signing stack

The certificate has to reach the system that actually performs signing. For local signing, that means the signing tool must be able to access the matching key. For an HSM, the certificate must be associated with the intended protected key. For cloud signing, the service and signing policy must point to the new certificate. Dedicated signing servers and CI/CD systems need their certificate references and credentials updated as well.

Test the new signing workflow before production

Installing a certificate is not the same as replacing a signing workflow. A controlled test should prove that the intended certificate is actually used, that the resulting signature verifies, and that the release environment behaves as expected.

When a private key is compromised, stop treating it as a normal replacement

A compromised signing key changes the objective from certificate maintenance to incident containment. Stop signing with the affected key, restrict access to the signing environment, preserve relevant evidence, determine the likely compromise window, and contact the issuing CA to follow its compromise and revocation process.

Why a compromised private key must not be reused

Once an attacker has copied a private key, the publisher cannot reliably make that same key secret again. Removing it from one computer, changing a password, reinstalling a certificate, or revoking the certificate does not prove that every copy has disappeared.

The recovery principle is therefore simple: a compromised private key is no longer a trusted signing secret. The replacement process needs a new key pair, not merely a new certificate wrapped around the old key.

Revoke the certificate through the issuing CA

When private-key compromise is confirmed or reasonably suspected, the certificate may need to be revoked. The publisher should follow the issuing CA's process rather than assuming revocation is a local switch. Revocation communicates a changed trust status for the certificate, while the compromised private key itself remains compromised.

Generate a completely new key pair

The replacement key must be cryptographically distinct from the compromised one. Think of the transition as two separate pairs rather than one certificate being swapped over an unchanged secret.

The new certificate is issued for the new signing key. This breaks the cryptographic relationship with the compromised secret.

Obtain the replacement certificate after compromise

Once the new key has been generated or provisioned, complete the appropriate certificate request and validation process. The new certificate should be checked for the expected publisher identity, certificate profile, validity period, and public-key association. For a compromised certificate, this is a recovery process rather than simply an ordinary renewal.

Replace the certificate throughout CI/CD

Automated signing is a common place for incomplete replacements. Updating the certificate on one developer machine does not fix a release pipeline that still references the old certificate or its credentials.

After the changes, run a controlled build and inspect the resulting signature. The goal is to prove that the new workflow is signing the artifact, not simply that the new certificate exists somewhere in the environment.

Previously signed software needs separate evaluation

Replacing a certificate primarily changes future signing. It does not automatically mean that every previously released file must be re-signed. Historical software needs to be evaluated according to why the certificate was replaced, when each file was signed, whether a trusted timestamp is present, whether unauthorized software may have been produced, and how the relevant platform verifies signatures.

A trusted timestamp can provide evidence about when a signature existed. It does not prevent a key compromise or automatically settle every post-compromise verification question.

Replacing a certificate does not automatically mean re-signing everything

The new certificate is normally intended for future releases. Previously released software may continue to have historical signatures that need to be verified on their own terms. A publisher should decide whether re-signing is necessary based on the circumstances of the replacement and the integrity of the affected releases.

In a compromise scenario, the question is broader than certificate age. The publisher needs to determine whether unauthorized files were signed and distributed during the suspected compromise window.

Keep the old certificate available for investigation and records

Removing an old certificate from active signing configuration does not mean erasing its history. Certificate details can remain relevant when examining existing software, validating release records, investigating an incident, or explaining a historical signature to customers and auditors.

The practical goal is to remove the old certificate from active signing paths while preserving the information needed to understand software that was signed in the past.

Replacing a certificate in an HSM

An HSM changes how the signing key is protected, but the replacement still needs a controlled certificate and authorization transition. If the key is non-exportable and remains protected, an incident may involve compromised signing credentials or authorization rather than extraction of the private key itself. That distinction should be established during investigation.

Replacing a certificate in a cloud signing service

Cloud signing introduces another boundary: the signing operation may be remote, while the private key remains inside the service's protected environment. Replacement therefore involves certificate provisioning, key handling where applicable, signing policies, identities, API credentials, tokens, service accounts, audit records, and CI/CD integration.

If the cloud account or signing authorization was compromised, replacing the certificate alone is insufficient. The access path that allowed unauthorized signing must also be contained and rebuilt.

What if the old private key is lost?

A lost private key is different from a compromised key, but it still prevents the publisher from continuing to use that key when the signing operation requires it. A public certificate cannot be used to recreate the original private key. Generate a new key pair, obtain a new certificate, and update the signing infrastructure for future releases.

Check whether publisher information has changed

Certificate replacement can also expose an identity change. Before submitting the new certificate request, check whether the legal organization name, address, organizational structure, or publisher status has changed. A merger, acquisition, reorganization, or change from individual publishing to organizational publishing can affect CA validation and the appropriate certificate process.

Verify the replacement from certificate to release

A successful replacement should be demonstrated through the complete signing path. Do not stop at certificate installation. Verify the certificate, signature, trust chain, timestamp, platform behavior, and automated release process.

Confirm that the old certificate is no longer active

After the new workflow works, search the environments that can still sign software. Check build scripts, CI/CD configuration, secret stores, signing servers, HSM configuration, cloud signing configuration, developer machines, and release automation. Search for the old certificate's thumbprint or other stable identifier where appropriate.

A practical replacement checklist

For a normal expiration, the work is primarily certificate transition and verification. For compromise, the first priority is containment and evidence preservation.

Common mistakes during certificate replacement

Code signing certificate replacement FAQs