Internal PKI

Enterprise Internal PKI can create root and intermediate authorities, issue server/client/code-signing/email certificates, apply templates, publish CRLs, and export supported formats under explicit scopes.

Use Internal PKI when the organization deliberately wants Opfield to operate a private trust domain for people, services, code signing, or email protection. The security owner defines policy and accepts the trust risk; PKI administrators operate authorities and templates; application owners consume certificates. Success is not merely issuing a certificate—it is proving the chain, intended use, renewal, revocation, backup, and recovery process before that certificate becomes a production dependency.

PKI means public key infrastructure: the authorities, certificates, private keys, revocation records, and policy that let systems decide which identities to trust. A root certificate authority is the top-level trust anchor. An intermediate authority issues day-to-day certificates so the root can be used less often and protected more strongly.

Private keys are encrypted with PKI_MASTER_KEY. Preserve this key independently from the database backup. Limit export permissions and audit every authority, certificate, revocation, and private-key operation.

User-facing Internal PKI is separate from Opfield’s hidden system PKI used for managed transport. After a license grace period ends, existing authorities, certificates, templates, and audit history are kept; you can still view them, download revocation lists, revoke and export certificates, and delete templates, while creating authorities, issuing certificates, and changing templates require the plan again. System transport continues to function.

Trust model

Create a root authority only when Opfield is intended to own that trust anchor. Prefer keeping the root offline or rarely used and issue operational certificates from an intermediate authority. Templates constrain subject, lifetime, key usage, extended key usage, and export behavior so operators do not reproduce policy manually for every request.

Opfield’s user-facing authorities must never be repurposed to replace the hidden system PKI, Database CA, daemon identities, or Relay service identities. Those internal trust domains have separate rotation and recovery contracts.

Governance decisions

Before creating a root, approve its scope, owner, lifetime, permitted certificate purposes, incident contact, and decommissioning plan. Decide whether the root should be generated in Opfield or imported, whether private-key export is allowed, and which relying systems will consume certificate revocation lists (CRLs). If those decisions are not documented, creating the authority is premature.

Use separate intermediate authorities for materially different environments or assurance levels. A compromised development issuer should not automatically threaten production, and a code-signing issuer should not be interchangeable with a general server-certificate issuer. Templates should encode these boundaries rather than relying on operator memory.

Provision an authority hierarchy

1. Confirm the Enterprise entitlement and required PKI scopes.
2. Generate or import the root authority.
3. Back up PKI_MASTER_KEY and the Opfield database through separate protected procedures.
4. Create an intermediate authority for the intended environment or organizational boundary.
5. Create templates for server, client, code-signing, or email certificates.
6. Issue a test certificate and verify its chain, key usage, lifetime, and export format.
7. Publish and test the CRL location before production issuance.

Issue and operate certificates

Record the owner, purpose, template, subject, validity, renewal expectation, and revocation contact for every certificate. Grant private-key export only to identities that need the key material. A user who can inspect certificate metadata does not automatically need authority or key-export permissions.

When a Route uses a certificate from an internal CA, the Ingress Node serves it together with its intermediate CAs, so clients that trust only the root can validate it.

Before renewal, verify that the subject and intended use are still valid. Revoke compromised or retired certificates, publish the updated CRL, and confirm relying systems consume it. Deleting a UI record is not a substitute for revocation when a certificate may still be trusted externally.

Validity, expiry alerts, and automatic reissue

A certificate cannot outlive the CA that issues it. By default, a request whose validity would end after the CA is refused with VALIDITY_EXCEEDS_CA. Set clampToCaValidity in the REST API, MCP, or assistant to end the certificate with its CA instead; the issue dialog shows a notice and applies it automatically. Certificates signed from a CSR follow the same rule. Leaf certificates from Opfield’s system CAs always end with their CA.

Opfield raises expiry alerts for user CAs 180, 60, 30, and 7 days before they expire (the last two follow the PKI expiry warning and critical settings) and for system CAs 730, 365, 180, 60, 30, and 7 days ahead. System CAs have no automatic rollover in 2.11, and every Node, Relay, managed storage, and managed database certificate they issued stops working when they expire, so plan their replacement when the first alert appears. Alerts name the owning resource, such as a managed storage cluster, a managed database, a Relay, an Opfield listener, or a Node. Each threshold alerts once: dismissing an alert holds until the next threshold, and a renewed certificate alerts again in its new lifetime.

An Internal PKI certificate linked as an SSL certificate or referenced directly by a Route is reissued automatically when Opfield holds its private key; certificates signed from a CSR are never reissued. Reissuing requires pki:cert:issue on the CA, like a manual issue.

Grant pki:ca:edit to change a CA’s CRL and issuer URLs, maximum validity, and OCSP responder, and pki:ca:export to export a CA with its private key; both can be restricted to one CA. pki:ca:view covers root and intermediate CAs and can also be restricted to one CA.

Certificate authorities, certificates, and certificate templates can be organised in folders, like Routes and SSL certificates: create, rename, and reorder folders, drag items between them, and pick a folder when creating an item. A CA folder holds whole hierarchies: only root CAs move, and their intermediates follow. Permissions granted on a CA folder cover each root CA in it and its intermediates, and permissions on a certificate folder cover the certificates in it; certificate template folders only organize the list. See Folder support by resource type.

Measure operational success through expiry coverage, revocation publication, audit completeness, and restore testing. Review certificates without owners, overly broad templates, unexpected private-key exports, unused intermediates, and CRLs that relying systems cannot reach. Private-key reveal or export should be rare, separately authorized, and followed by secure custody outside Opfield.

Backup and recovery

A database backup without PKI_MASTER_KEY cannot recover encrypted private keys. A key backup without the database cannot reconstruct authorities, templates, certificates, revocations, and audit relationships. Store and test both parts while keeping them operationally separate.

After restore, verify authority chains, decryption, certificate export permissions, CRL publication, and audit continuity before issuing new material.

Operator details: incident and retirement

If an issuing key is suspected to be compromised, stop new issuance, identify all descendant certificates, prepare a replacement hierarchy, publish revocation information, and coordinate trust-store changes with relying systems. Restoring the same compromised key is not recovery. Preserve audit evidence and the old public chain for investigation without continuing to trust it.

Retiring an authority requires more than deleting it from navigation. Stop issuance, replace or expire descendants, retain revocation evidence for the required period, remove trust from clients, and only then remove the authority when Opfield confirms that dependent objects are resolved.

Entitlement and deletion behavior

After a license grace period ends, Opfield preserves authorities and certificates and keeps viewing, revocation lists, certificate revocation and export, and deletion available, while creating authorities, issuing certificates, and changing templates require the plan again. System transport is never disabled. Before deleting an authority, resolve all child intermediates and certificates and preserve required revocation evidence.