Keep signing available through failures, and recover the portal data and keys when something goes wrong.
CodeSign Secure runs on a single Windows server by default. For high availability, run several CodeSign Secure servers as a cluster behind a load balancer, share one database cluster between them, and run your HSMs in a high-availability configuration. Because the REST API is stateless, any server in the cluster can handle any request.
| Layer | Single server | Cluster |
|---|---|---|
| CodeSign Secure server | One server; recover by reinstalling and restoring a backup | Two or more servers behind a load balancer |
| Database | Local MongoDB | Shared MongoDB cluster (replica set) used by every server |
| HSM | One HSM or an HA HSM group | HA HSM group, for example an nShield Security World shared by several HSMs or a Luna HA group |
| Recovery | Restore from backup | Remaining nodes keep serving; replace the failed node |
Every server runs the same CodeSign Secure version.
Every server connects to the same database cluster.
Every server has the HSM client configured for the same HSM or HA group, so every key is available on every node.
The load balancer publishes the portal DNS name and forwards traffic to the servers.
Clients authenticate with mutual TLS. Configure the load balancer for TLS pass-through so the client certificate reaches the CodeSign Secure servers, unless Encryption Consulting has validated a different setup for you.
All servers, the database members, and the HSMs use the same time source (NTP), because tokens and request timers depend on accurate time.
Use an HTTPS health check against each server’s portal URL so the load balancer stops sending traffic to a server that doesn’t respond.
| Included in a CodeSign Secure backup |
|---|
| CodeSign Secure logs |
| Apache logs |
| A dump of the database: users, roles, applications, teams, environments, certificate records, signing requests, and logged events |
| Key reference files used by CodeSign Secure |
Important: A CodeSign Secure backup can’t restore keys on its own. You need to manually recover the files from a CodeSign Secure backup to continue signing. Back up HSM keys using vendor-provided tools and utilities.
Set the schedule in Backup. Choose a Frequency of Daily, Weekly or Monthly, and a Location of Server or Cloud (SharePoint).
Recovery point: you can lose everything created since the last backup, so for production use Daily.
Keep a copy off the server: a backup stored only on the server is lost with the server. Use the Cloud location or download each backup to protected storage.
Protect backup files: they contain the full database dump and logs. Store them with the same access controls as the server.
Important: Restore overwrites the entire database with the backed-up dump. Everything created after that backup, such as new users, certificates, applications, requests and audit events, is removed.
Tell users and pipeline owners that signing is paused, and stop automated pipelines.
Create a new backup of the current state and download it, so you can go back if needed.
In System Setup > Backup, find the backup you want and select Restore.
Manually restore the key files from the backup. Back up HSM keys using vendor-provided tools and utilities.
Sign in and check the Dashboard, HSM Health Check, the certificate list, and recent Audit Trail entries.
Re-create anything made after the backup.
Resume pipelines and confirm that a test signing succeeds.
Build a new Windows Server 2022 machine and give it the same portal DNS name, or point the DNS name at it.
Install and connect the HSM client to the same HSM or HA group, and confirm the keys are visible with the vendor tools.
Install the same CodeSign Secure version. See Installing the server.
Restore the most recent backup.
Import the portal TLS certificate, restart the Apache monitor, check the Dashboard, and run a test signing.
Follow your HSM vendor’s backup procedure, such as backing up the nShield Security World and its key files, or backing up or cloning the Luna partition.
Keep HSM backup media and administrator cards under dual control, and record who can use them.
Test that keys can be restored to a replacement HSM, not just that the backup job ran.
Keys for publicly trusted code-signing certificates must stay protected in certified hardware, including in backup copies.
The latest backup was completed, and a copy exists off the server.
The backup was restored on a test server, and users, certificates, and applications appear as expected.
The HSM backup was restored or verified, and the keys are visible from the test server.
A test file was signed and verified from the recovered environment.
The time taken was recorded and compared with your recovery time objective.