Internal CA

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 an Intermediate, or when an operator issues, reissues or regenerates a CA by hand. Enabling the Internal CA on the Settings tab does not by itself materialise the Root or any Intermediate.

The hierarchy is:

1. A self-signed Root CA certificate.
2. One or more Intermediate CA certificates signed by the Root.

Both are stored as password-protected .pfx files under %ProgramData%\VSoft\Signotaur\Server\CertificateManagement\. Each 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.

The Multi-Intermediate Hierarchy

Signotaur does not use a single shared Intermediate CA. Instead, one Root anchors several purpose-scoped Intermediate CAs, each allowed to issue only certain kinds of certificate.

A purpose-scoped intermediate is an Intermediate CA whose extended key usage (EKU) lists only the purposes it is meant to issue for. An EKU is the standard field that says what a certificate may be used for: server authentication (TLS), code signing, or document signing. Because a certificate can never be used for a purpose its issuing chain does not permit, an intermediate scoped to code signing cannot issue a TLS certificate even by mistake.

The purposes are:

• TLS / Web Server
• Code Signing
• Document Signing
• All purposes, a wildcard intermediate that can issue any of them

Why this matters:

• Blast radius. If one intermediate has to be replaced, only the certificates it signed are affected. Certificates signed by the other intermediates are untouched.
• Separation of duties. You can disable document-signing issuance without disturbing TLS or code signing.
• Honest policy statements. Each intermediate can assert the certificate policy that matches the checks you actually perform for that kind of certificate.

You do not have to plan the hierarchy in advance. When the first certificate of a purpose is issued and no eligible intermediate exists, Signotaur mints one automatically. You can also create intermediates explicitly, and disable one to pause issuance from it.

Issuance picks the intermediate for you. Signotaur selects an enabled intermediate that is eligible for the requested purpose. When more than one is eligible, the Issue dialog asks you to choose. Renewal is different: a renewed certificate is signed by the intermediate that signed the original, so a renewal never silently moves a certificate onto a different chain.

Intermediates are managed on the Intermediate CAs sub-tab; see the Internal CA settings tab.

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.

The tab is divided into sub-tabs, documented in full on the Internal CA settings tab:

• Root CA: the current Root, its actions, and Offline Root mode.
• Intermediate CAs: the list of purpose-scoped intermediates, and the automatic renewal threshold.
• Certificate defaults: the validity, key size and identity defaults applied to new web, code-signing and document-signing certificates.
• Validation Authority, Certificate Policy and Public Distribution: the revocation service and the statements certificates carry.

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 an intermediate, which remains on the server.
• Operations that need the Root key (adding or reissuing an 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 add or reissue an intermediate while Offline Root mode is in use, temporarily restore the Root .pfx file, perform the action, then remove it again.

Renewing an Intermediate CA

An Intermediate CA is reissued automatically when it comes within its renewal threshold (180 days before expiry by default), provided the Root CA is reachable. You can also reissue one on demand from the Intermediate CAs sub-tab.

When an intermediate is reissued:

• A new Intermediate certificate is generated and signed by the Root, keeping the same purposes.
• New certificates of those purposes 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.

Reissuing creates a new key. Existing certificates keep working, but any certificate you want on the new chain must be reissued. The served web certificate is reissued for you.

Regenerating the Root CA

Regenerating the Root creates a brand-new Root and a new set of intermediates, replacing the entire hierarchy.

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

Revocation and the Validation Authority

A certificate can outlive its trustworthiness: a key may leak, a signer may leave, or a certificate may simply be replaced. Revocation is how a CA tells the world to stop trusting a certificate before it expires.

For that to work, something must publish the list of revoked certificates and answer questions about them. That service is the Validation Authority. Signotaur's Validation Authority provides:

• an OCSP responder, which answers "is this one certificate revoked?" over the network;
• CRL publication, a signed Certificate Revocation List a validator can download and cache;
• a CA-Issuers endpoint, which serves the issuing CA certificate so a validator can complete the chain.

A validator only knows to ask if the certificate tells it where to look. That is what the AIA/CDP pointers are: two standard extensions stamped into a certificate at issuance, carrying the addresses of its revocation service. AIA (Authority Information Access) carries the OCSP and CA-Issuers addresses; CDP (CRL Distribution Points) carries the CRL address.

Three consequences follow, and all matter in practice:

• The pointers are baked in at issuance. A certificate issued before Signotaur was set to include those addresses carries no pointers, and nothing will ever check its revocation status. Only certificates issued afterwards can be revoked meaningfully.
• The addresses cannot be changed for a certificate that already exists. Choose stable addresses before you start issuing.
• The addresses are conventionally plain http://, not HTTPS. Checking a validation address over HTTPS means checking the certificate securing that connection, which needs a status check of its own, so many validators reject an https:// address outright. Signotaur can serve the endpoints on a plain-HTTP port of its own for that reason.

Because those addresses are permanent, Signotaur keeps answering at them even after you stop adding them to new certificates. Switching the addresses off governs issuance from that point on; it does not withdraw a service that existing certificates still depend on.

Revocation is also what makes long-term signatures worth having. A long-term signature embeds the certificates and revocation evidence needed to prove, years later, that the certificate was valid when the signature was made. Without a reachable Validation Authority there is no such evidence to embed.

The Validation Authority applies to the Internal CA only. ADCS and other external issuers run their own revocation services. Web (TLS) certificates are never stamped with pointers.

See the Validation Authority settings and Revoking a Certificate.

Publishing Revocation Beyond the LAN

By default the Validation Authority answers on your own network only. If signatures made with Internal CA certificates have to be validated outside it, Signotaur can copy the CRL and the issuer certificate to an external destination such as an SFTP server or an S3 bucket.

Only those two public files are copied. No private key ever leaves the server, and the OCSP responder stays on the local network. See Public Distribution.

Certificate Policies

A certificate policy is a short, standardised marker inside a certificate that says how thoroughly the subject's identity was checked before the certificate was issued. Someone who receives a signed file can read that marker, and follow an optional link to your own policy document, to judge how much the signature is worth.

Signotaur offers three non-qualified profiles from ETSI EN 319 411-1: LCP (a basic identity check), NCP (stronger proofing against authoritative records) and NCP+ (NCP proofing plus the key held on a secure device).

Two points are load-bearing:

• The marker is advisory. Signotaur does not set Policy Constraints, so no validator is required to enforce anything because of it. Adding a policy will not cause path validation to fail.
• You are the policy authority. Signotaur supplies the mechanism and explains what each option asserts. It never checks whether your process lives up to the claim, and it never blocks an issuance over one. Choose the profile your organisation honestly meets.

These are self-asserted certificates. They are not qualified (eIDAS QES) certificates, they carry no external audit, and no public trust list includes them.

See Certificate Policy.

Rich Certificate Identity

A certificate's subject can be more than a common name. When you issue a signing certificate from the Internal CA you can add a structured identity following ETSI EN 319 412: either a natural person (given name, surname or pseudonym, title) or a legal person (organisation and organisation identifier), plus country, locality and state, and email addresses as subject alternative names.

This matters when signed documents leave your organisation: a structured subject tells the recipient exactly who signed, in a form other tools can read. Everything beyond the common name is optional, and an untouched form still issues a simple common-name-only certificate exactly as before.

The organizationIdentifier field follows an ETSI scheme (for example VATGB-123456789). Signotaur checks the shape and shows an advisory note when it looks wrong, but never blocks issuance: whether the reference is genuine is a question for the official register, and that check belongs to your own registration process.

See Issuing a Certificate.

Distributing the Root Certificate

For clients to trust the web certificate and the 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.
• Validation Authority: the revocation service.
• Certificate Policy: policy profiles and identity attestation.
• Public Distribution: publishing revocation off the LAN.
• Managed Certificates: issuing, renewing and revoking certificates.
• Renewal and Retention: the full certificate lifecycle.