PKI Core is the component of TigerTrust that runs your private Certificate Authorities. Every cryptographic operation on an internal CA — signing, revocation, CRL generation, OCSP — flows through PKI Core. It is designed to run isolated from the rest of your infrastructure with a minimal attack surface, and it integrates with hardware security modules (HSMs) via PKCS#11 when your security requirements demand hardware key protection.
Pki Core

​
What it is

PKI Core manages the full lifecycle of your internal CA hierarchy: you create root and intermediate CAs, define certificate templates and enrollment policies, issue and revoke certificates, and publish CRLs and OCSP. All CA private keys are held by PKI Core — never by the application layer — and can optionally be stored in a PKCS#11-compliant HSM so keys never exist in software.

​
When to use it

  • Build a private CA hierarchy: a long-lived offline root, issuing intermediates per purpose (servers, code signing, internal services).
  • Issue TLS certificates for internal services without depending on a public CA.
  • Integrate with a hardware security module to ensure CA private keys are generated and used inside certified hardware.
  • Gate certificate issuance on TPM attestation so only devices with a verified firmware state can receive a certificate.
  • Serve OCSP and CRL from TigerTrust’s own distribution points for relying parties on your internal network.

​
CA hierarchy

PKI Core supports arbitrarily-deep CA chains. A common layout: 
Root CA          (self-signed, 20-year, RSA 4096 or ECDSA P-384)
├── Intermediate -- Server Certs      (10-year, issues TLS server certificates)
├── Intermediate -- Code Signing      (10-year, issues code-signing certificates, approval required)
└── Intermediate -- Internal Services (10-year, issues short-lived mesh certificates)
Path-length constraints and validity capping are enforced at signing time. An intermediate CA cannot issue a certificate that expires after the intermediate itself does.

​
Set it up

1

Create a root CA

Go to PKI Management and click New root CA. Choose the key algorithm (RSA 4096 or ECDSA P-384 recommended), enter the subject fields (common name, organisation, country), and set the validity period. Click Create.
2

Create an intermediate CA

Click New intermediate CA, select the parent CA, and configure the subject and validity. TigerTrust signs the intermediate’s CSR with the parent CA and stores the resulting certificate chain.
3

Assign templates

On each intermediate, click Assign template and choose the certificate templates it is allowed to issue. The intermediate will enforce template constraints at signing time.
4

Configure distribution points

On each CA, set CRL distribution point URLs and OCSP responder URLs. These values are embedded in every certificate the CA issues. See CRL and OCSP for configuration details.
5

Enable HSM (optional)

If you are using a hardware security module, go to PKI Management > HSM and configure the PKCS#11 library path, slot, and PIN before creating CAs. Keys generated after HSM is enabled are created inside the HSM and never exported.

​
HSM support

PKI Core supports PKCS#11-compliant hardware security modules. Tested devices include SoftHSM (development), Thales Luna, YubiHSM 2, AWS CloudHSM, and Azure Managed HSM. When HSM is enabled, CA key generation and all signing operations happen inside the HSM. The CA record stores an HSM key label reference rather than a private key value. No private key material is written to storage. Go to PKI Management > HSM to enumerate available slots, generate keys in-HSM, and view key status.

​
What you’ll see

PKI Management lists all CAs with type (root / intermediate), key algorithm, validity period, and health status. Click a CA to view its full certificate chain, download the chain in PEM or DER format, view issued certificates, generate an on-demand CRL, and check OCSP status for a serial number. CA health monitors whether the CA can sign certificates (key accessible, not expired, not revoked). A CA in a degraded or error state raises an alert and blocks new issuance.
When HSM is enabled, CA private keys are stored inside the HSM and are never written to any database or file. An HSM connectivity failure will prevent any new certificate issuance until the HSM is reachable again.
Root CA private keys should be kept offline wherever possible. Create the root CA, sign your intermediates, then use the intermediates for day-to-day issuance. Revoking a root CA invalidates your entire chain.

CRL and OCSP

Distribution point setup and OCSP stapling recipes.

Certificate templates

Templates that PKI Core enforces at signing time.

TPM attestation

Attestation-gated issuance for IoT and edge devices.

Certificate authorities

Connecting external CAs alongside your internal PKI Core CAs.