VSoft Technologies Blogs

Signotaur 2.0: managing certificates, not just signing with them

Fri, 26 Jun 2026 01:39:43 GMT

In this article:

A brief introduction to certificates and Certificate Authorities
Signotaur's built-in Certificate Authority and Microsoft AD CS integration
Management of the TLS certificate used by the web interface
Encrypted backups and stronger protection for secrets at rest
Rate limiting and other administration improvements

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.

Signing files that can't carry a signature: detached CMS for ZIPs, ISOs and more

Fri, 12 Jun 2026 02:25:05 GMT

In this article:

Why some files can't carry an embedded signature
What a detached .p7s signature is, and when Signotaur writes one
Signing archives and disk images with no extra flags
Extending detached signing to arbitrary files with --detached
Controlling the output path, and verifying with Signotaur or OpenSSL

Most of the file types Signotaur signs have somewhere to put the signature. A PE binary has a certificate table, an MSI has a digital-signature stream, a NuGet package has a reserved ZIP entry. You sign the file, the signature goes inside it, and the file still works exactly as before.

Plenty of files people need to sign have no standard embedded-signature format. A .zip, a .tar.gz, an .iso, a firmware blob, a plain .json manifest — several of these do have comment or metadata areas you could stash bytes in, but there's no agreed-upon signing format that other tools would recognise. You can wrap the whole file inside a signature structure, but that changes the file itself: your zip is no longer a zip, it's a CMS structure containing the zip.

The standard answer to this is a detached signature: sign the bytes, leave the original artifact untouched, and write the signature to a separate file. Signotaur now supports this directly, producing a standard CMS/PKCS#7 .p7s signature next to the file it signed.

CMS (Cryptographic Message Syntax, RFC 5652) is the IETF standard format for digitally signed data; PKCS#7 is the older format CMS was based on, and the names are still often used interchangeably. The .p7s extension is the conventional one for a detached CMS signature, which is why you'll see it throughout this post.

Archives and disk images: nothing to do

Signing a zip while keeping it usable is by far the most common case, so Signotaur automatically uses detached signatures for common archive and disk-image formats, with no extra flags:

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] release.zip

That signs release.zip and writes the signature to release.zip.p7s alongside it. release.zip itself is not touched — same bytes, same hash, still opens in any zip tool. The formats handled this way are .zip, .7z, .tar, .gz, .tgz, .bz2, .xz, .iso, .img, .vhd and .vhdx.

Files that do have a native embedded format — PE, MSI, NuGet, VSIX, RDP, ClickOnce manifests, .mobileconfig — keep using it. You don't have to think about which is which; the sign command routes each file by its type.

Other file types: `--detached`

To produce a detached signature for a file type that Signotaur would not otherwise sign as an embedded format — for example a .txt, a .json, an arbitrary binary — add --detached (--dt):

SignotaurTool.exe sign -a [APIKey] -s [SignServer] -t [Thumbprint] --detached manifest.json

This writes manifest.json.p7s and leaves manifest.json alone. The flag is ignored for file types that have their own embedded signature, so it's harmless to leave on in a script that signs a mix of things.

Choosing where the signature lands

By default the signature is written next to each signed file as [file].p7s. To put signatures somewhere else, use --signature-file (--sf). For a single file you can give an exact path:

SignotaurTool.exe sign release.zip --signature-file C:\sigs\release.sig ...

When signing many files at once, use placeholders so each output is distinct:

{name} — the file name including extension (archive.zip → archive.zip.p7s).
{name-no-ext} — the file name without extension (archive.zip → archive.p7s).
{rel-path} — the file path relative to the current directory, or to --base-directory if specified. This avoids collisions when different folders contain files with the same name.

SignotaurTool.exe sign src\**\*.zip --signature-file sigs\{rel-path}.p7s ...

Any directories in the output path are created for you. An exact (placeholder-free) path is only valid when signing a single file — otherwise every file would write to the same signature file.

Verifying

A .p7s file is a plain CMS/PKCS#7 SignedData structure, so it's not locked to Signotaur. Point verify at either the original or its .p7s signature and it auto-detects the pairing:

SignotaurTool.exe verify release.zip

And because it's standards-compliant, OpenSSL — or anything else that speaks CMS — can verify it too:

openssl cms -verify -binary -inform DER -in release.zip.p7s -content release.zip -CAfile root.pem -out NUL

That example assumes a signer certificate issued directly by the root in root.pem; in practice, use whichever CA bundle or certificate chain is appropriate for the signer certificate. (-out NUL just discards the recovered content so the zip isn't dumped to the console.)

If you only need an integrity check — confirm the signature matches the content, without deciding whether the signer is trusted — add -noverify. It skips chain validation, so no root.pem is required:

openssl cms -verify -noverify -binary -inform DER -in release.zip.p7s -content release.zip -out NUL

This confirms the bytes haven't changed since signing, but it does not establish that you trust the signer — for that, use the chain-validating form above.

RFC 3161 timestamping works on detached signatures the same as everywhere else — pass --tr (and optionally --st) and the timestamp is embedded into the .p7s.

Wrapping up

Detached signing extends Signotaur beyond formats with a built-in signature slot. Where a file has a native signing format, Signotaur continues to use it. Where it does not, Signotaur can write a clean .p7s signature alongside the untouched original.

The result is still standards-compliant CMS/PKCS#7, so consumers are not tied to Signotaur for verification. More to come, but this removes a "you can't sign that" answer we'd rather not give.

For the full option reference see the sign and verify command pages in the Signotaur documentation. As always, the private key never leaves your signing server — detached or embedded, only the digest is ever sent for signing.