Internal CA

Signotaur's Internal CA issues certificates without depending on any external PKI. It is opt-in: it is enabled when you select the Internal CA as the web-certificate source in the installer, or turn it on from the Managed Certificates → Settings tab. Once enabled, the CA hierarchy is generated automatically. No manual key ceremony is required.

This guide covers configuring and operating the Internal CA. For the certificate hierarchy concepts, see the Certificate Management overview; for delegating issuance to an existing enterprise CA instead, see the ADCS guide.

Issuing and renewing certificates from the Internal CA requires an Enterprise license. Without one, managed renewals are skipped, an unlicensed bootstrap web certificate is capped at 90 days before reverting to self-signed, and managed code-signing certificates cannot be used for signing. See Managed CA Licensing and Editions & Licensing.

First-Run Generation

When the Internal CA is enabled, Signotaur generates its CA hierarchy automatically the first time it is actually needed: when the first certificate is issued from the Internal CA, when the renewal service touches the Intermediate, or when an operator triggers a Renew Intermediate or Regenerate Root action. Enabling the Internal CA on the Settings tab does not by itself materialise the Root or Intermediate.

The hierarchy is:

  1. A self-signed Root CA certificate.
  2. An Intermediate CA certificate signed by the Root.

Both are stored as password-protected .pfx files under %ProgramData%\VSoft\Signotaur\Server\CertificateManagement\. The hierarchy is generated once; on later restarts it is loaded from disk, not regenerated.

Because the Root is freshly generated and self-signed, client machines will not trust it until you distribute it; see Distributing the Root Certificate below.

Configuring the Internal CA

The Internal CA is configured from the Internal CA tab of the Managed Certificates admin page. The defaults are suitable for most deployments; change them before the hierarchy is first generated if you want different values.

The settings are organised into three groups, documented in full on the Internal CA settings tab:

  • Root CA defaults: subject, validity period (default 20 years), and key size (default 4096-bit RSA).
  • Intermediate CA defaults: subject, validity period (default 5 years), key size, and the renewal threshold.
  • Certificate defaults: the validity, key size, and other issuance defaults applied to new web and code-signing certificates.

Changing the Root or Intermediate subject after the hierarchy already exists has no effect on the existing certificates; it applies only if the hierarchy is regenerated. To change an existing Root or Intermediate, use Regenerate Root or Renew Intermediate as described below.

Offline Root Mode

In a conventional PKI the Root CA key is used rarely (only to sign Intermediate CAs) so it can be kept offline and protected far more aggressively than a key in daily use. Signotaur supports this through Offline Root mode.

When Offline Root mode is enabled:

  • After the hierarchy has been generated, the Root CA .pfx file can be moved off the server to secure storage (for example, an encrypted offline volume or a safe).
  • Day-to-day issuance is unaffected; end-entity certificates are signed by the Intermediate, which remains on the server.
  • Operations that need the Root key (renewing the Intermediate CA and regenerating the Root) are blocked until the Root .pfx file is restored to its expected location.
  • Signotaur will not silently generate a replacement Root if the file is missing. It reports an actionable error instead, so a misplaced Root key can never be masked by an unexpected new one.

To renew the Intermediate while Offline Root mode is in use, temporarily restore the Root .pfx file, perform the renewal, then remove it again.

Renewing the Intermediate CA

The Intermediate CA is renewed automatically when it comes within its renewal threshold (180 days before expiry by default), provided the Root CA is reachable. You can also renew it on demand from the Renew Intermediate action on the Managed Certificates page.

When the Intermediate is renewed:

  • A new Intermediate certificate is generated and signed by the Root.
  • New certificates are issued from the new Intermediate.
  • Certificates that were already issued continue to chain through the previous Intermediate, which remains valid until its own expiry. Nothing already deployed breaks.
  • The previous Intermediate is marked Replaced and is eventually cleaned up according to the retention policy.

Regenerating the Root CA

Regenerating the Root creates a brand-new Root and Intermediate, replacing the entire hierarchy.

Regenerating the Root is destructive. Every certificate previously issued by the Internal CA chains to the old Root. Until the new Root certificate is distributed and trusted, clients will reject the new web certificate and signatures made with newly issued certificates. Only regenerate the Root when you genuinely intend to rebuild trust from scratch, for example after a suspected key compromise.

Because of this, the Regenerate Root action requires you to type a confirmation word before it will proceed. After regenerating, distribute the new Root certificate to every client machine.

Distributing the Root Certificate

For clients to trust the web certificate and the code signatures Signotaur produces, the Root CA certificate must be installed in their trusted-root store. The Root certificate (never the private key) can be downloaded from the Web Certificate page, which also provides step-by-step installation instructions for Windows, Linux, and macOS on its Trust Distribution tab.

Related Pages

  • Internal CA settings tab: field-by-field reference.
  • Managed Certificates: issuing and renewing certificates.
  • Renewal and Retention: the full certificate lifecycle.