Signotaur 2.0: managing certificates, not just signing with them

The first release of Signotaur focused on one central task: keeping code-signing private keys on a server you control and signing files without exposing those keys to build agents or users.

Signotaur 2.0 extends that approach to certificate management. It can now issue and renew certificates through its own internal Certificate Authority, or request them from an existing Microsoft Active Directory Certificate Services deployment. It can also manage the TLS certificate presented by its own web interface.

The release also introduces encrypted backups and easier server migration, machine-bound protection for stored secrets, per-API-key rate limiting and a range of administration improvements. This article covers the main changes, beginning with a short introduction to the PKI concepts behind the new certificate-management features.

A brief PKI refresher

A certificate associates an identity, such as a person, organisation or server name, with a public key. Its authenticity is established by a digital signature from a recognised Certificate Authority (CA).

When software verifies a signed file or establishes a TLS connection, it checks the certificate chain from the certificate in use back to a trusted CA certificate. If the chain is valid and terminates at a root certificate trusted by the machine, the certificate can be accepted.

Certificate Authorities are commonly organised as a hierarchy. A root CA forms the trust anchor and is normally kept offline or used only rarely. One or more intermediate CAs then issue certificates for everyday use. Machines trust the root certificate, and that trust extends through the signed chain to certificates issued by the intermediate CA.

Certificates that must be trusted publicly, such as those used by public websites or widely distributed software, are generally issued by a commercial CA whose root certificates are already included in operating systems and browsers. Internal services, build infrastructure and private signing systems often need trust only within an organisation. In those cases, an internally managed CA can provide greater control without requiring a publicly trusted certificate.

Built-in Certificate Authority

Signotaur can now create and manage its own CA hierarchy, consisting of a root CA and an intermediate CA. It can use that hierarchy to issue code-signing certificates for build pipelines and web certificates for internal services.

The CA private keys are generated and stored on the Signotaur server and are protected using the same server-side key-custody model as signing keys. They do not need to be copied to build agents or administrator workstations.

The managed-certificate features include:

• On-demand issuance. Administrators can issue certificates from the admin web interface without using separate command-line tools or manually maintained configuration files.
• Automatic renewal. Managed certificates can be renewed before they expire, reducing the risk of failed builds or unavailable internal services.
• Expiry notifications. Email notifications provide advance warning when a certificate requires attention.
• Centralised tracking. The managed-certificate list records current certificates and the certificates they replace, providing a single view of issued certificates and their status.

The CA hierarchy is created only when it is first needed. Enabling the feature does not immediately generate or store CA keys. The root and intermediate certificates are created when the first certificate is issued.

Once the hierarchy exists, the root certificate must be added to the trust stores of the machines that need to trust certificates issued by Signotaur.

Issuing certificates through Microsoft AD CS

Organisations that already use Active Directory Certificate Services can issue Signotaur-managed certificates through their existing PKI instead of creating a separate CA hierarchy.

Signotaur can connect to an AD CS server through either the DCOM interface or the Certificate Services web enrolment service, and request certificates using selected enterprise certificate templates. Certificates issued by AD CS appear in the same managed-certificate list and can use the same tracking and renewal features as certificates issued by Signotaur's internal CA.

This allows organisations to retain their existing templates, policies and trust chain while using Signotaur to manage certificate enrolment and renewal.

Managing the web certificate

Signotaur 2.0 adds a dedicated administration page for the TLS certificate presented by the web interface.

The certificate can come from several sources:

• a self-signed certificate;
• an existing PFX file;
• a certificate in the Windows certificate store; or
• a certificate issued through Signotaur's managed-certificate system.

The administration page displays the active certificate, its certificate chain and its expiry date. Administrators can also download the chain anchor in PEM or DER format for distribution to client trust stores.

Enterprise licensing

The internal CA, AD CS issuance, code-signing with managed certificates, and use of a managed certificate as the ongoing web-certificate source are included in the new Enterprise licence.

Every Signotaur server can issue one managed web certificate during installation without an Enterprise licence. This certificate can be valid for up to 90 days. After that period, the server reverts to a self-signed certificate unless an Enterprise licence is installed.

The allowance applies only to the single web certificate. Issuing or signing with managed code-signing certificates, and continuing to renew the web certificate after 90 days, require an Enterprise licence. The other features described in this article remain available in the existing editions.

Encrypted, portable backups

Signotaur 2.0 introduces encrypted backups for the server configuration, database and certificates.

The new archive command creates a passphrase-protected .sigbak file and supports creating, verifying, restoring and extracting backups:

archive create   -- create a .sigbak bundle
archive verify   -- verify a bundle and its passphrase
archive restore  -- restore a bundle to a server
archive extract  -- extract individual files from a bundle

Backups are portable between servers. When restored on another machine, protected secrets are automatically re-encrypted using that machine's key, making the same format suitable for both disaster recovery and server migration.

Scheduled backups can also create complete .sigbak archives automatically when a backup passphrase is configured. The command runs locally through the Signotaur server executable.

Protecting secrets at rest

Signotaur now protects its master encryption key using machine-bound Data Protection API (DPAPI) encryption.

As a result, a copy of the server files cannot simply be moved to another machine and decrypted there. Configuration secrets, CA private keys and other protected data remain bound to the machine that stored them. A supported .sigbak restore deliberately re-protects those secrets for the destination machine.

Per-API-key rate limiting

Signotaur 2.0 can apply an optional fixed-window rate limit to gRPC signing requests on a per-API-key basis.

Administrators specify the permitted number of requests and the length of the window. When an API key exceeds that limit, further requests are throttled until the next window begins. Rate limiting is disabled by default, so existing installations retain their current behaviour unless it is explicitly enabled.

Administration improvements

The release also includes a number of changes intended to make the server easier to configure and maintain:

• More settings apply immediately. Changes to email, event retention, password policy, session and login expiry, update checks, the PKCS#11 PIN-failure limit, and enabling or disabling rate limiting can take effect without restarting the server. Other settings that require a restart, including hostname and port, OAuth provider, log-file changes, and changes to an already-running rate limiter, now display a clear restart-pending notification.
• Configurable session lifetimes. A login with "Remember me" left unticked can be given a shorter idle timeout than a remembered one, so unattended sessions expire sooner. Administrators can also decide whether sign-ins via external providers (Google, GitHub) stay signed in or last only for the browser session.
• Concurrent-edit protection. Configuration changes use optimistic concurrency. If another administrator changes the same settings before they are saved, Signotaur displays a conflict rather than silently overwriting the newer values.
• Clearer save behaviour. The web interface warns about unsaved changes before navigation and displays a summary of proposed changes before they are saved, including when each change will take effect.
• Improved installer certificate setup. The installer provides separate configuration paths for an existing PFX, a Windows certificate-store certificate, a self-signed certificate, the built-in CA and external AD CS. It validates certificate details, subject names and AD CS connectivity before continuing. It also respects the configured backup directory and creates a pre-upgrade backup.

Summary

Signotaur 1.0 concentrated on protecting signing keys and keeping them on a server under your control. Signotaur 2.0 extends that model to the certificates associated with those keys by adding issuance, renewal and centralised tracking.

It also strengthens server administration through encrypted portable backups, machine-bound protection for stored secrets, rate limiting and clearer configuration management. The underlying signing model remains the same: private keys stay on the Signotaur server, and signing operations do not expose them to build agents or users.

Further information is available in the Signotaur 2.0 documentation, including the managed-certificate, web-certificate and archive command reference pages.