PKI Operating Modes: CA vs RA¶

Trustpoint can operate as a local Certificate Authority (CA) or as a Registration Authority (RA) forwarding requests to an external PKI. The operating mode is determined by the CA type configured for the issuing CA associated with each trust domain.

Operating Mode Decision¶

        flowchart TB
    DEVICE[Device enrollment request]
    VALIDATE["Trustpoint / authentication, policy, approval"]

    DEVICE --> VALIDATE

    VALIDATE --> MODE{Issuing CA type}

    MODE -->|"CA mode / LOCAL_PKCS11 / AUTOGEN"| LOCAL_SIGN[Generate certificate locally]
    LOCAL_SIGN --> CRYPTO[Crypto provider API]
    CRYPTO --> PKCS11[PKCS#11 provider]
    PKCS11 --> HSM_TOKEN[HSM or SoftHSM token]
    LOCAL_SIGN --> CERT_LOCAL[Issued certificate]

    MODE -->|"RA mode / REMOTE_EST_RA / REMOTE_CMP_RA"| FORWARD[Forward CSR to external CA]
    FORWARD --> EXT_EST[External EST endpoint]
    FORWARD --> EXT_CMP[External CMP endpoint]
    EXT_EST --> CERT_REMOTE[Issued certificate]
    EXT_CMP --> CERT_REMOTE

    CERT_LOCAL --> STORE["Store in PostgreSQL / update device state / trigger workflows"]
    CERT_REMOTE --> STORE
    STORE --> RESPOND[Return certificate to device]

CA Mode (Trustpoint acts as Certificate Authority)¶

CA types: AUTOGEN_ROOT, AUTOGEN, LOCAL_PKCS11

In CA mode, Trustpoint owns the issuing CA and signs certificates using a private key managed by the configured cryptographic provider.

Use Cases¶

Self-contained OT installations without enterprise PKI
Test and development environments
Isolated production cells with local trust anchors
Air-gapped networks requiring on-premises issuance
Temporary or emergency certificate issuance when external CA is unavailable

Implementation Details¶

Certificate signing flow:

Device sends CSR (Certificate Signing Request) via EST/CMP/AOKI
Trustpoint validates device identity and applies policies
Approval workflow executes (if required)
Trustpoint loads issuing CA private key from PKCS#11 token
Trustpoint generates certificate using CA key and profile
Certificate signed via crypto provider API
Certificate stored in PostgreSQL with device linkage
Certificate returned to device

Key operations:

Issuing CA private key stored in PKCS#11 token (production) or SoftHSM (dev)
Certificate signing performed in trustpoint/pki/ domain services
Key operations delegated to crypto module provider abstraction
Trustpoint generates and manages CRLs for issued certificates

CA Type Details¶

AUTOGEN_ROOT¶

Purpose: Auto-generated self-signed root CA

Use case: Testing and development only

Characteristics:

Self-signed root certificate
Generated automatically during setup
Key stored in configured crypto provider
Not suitable for production

Generation: Triggered by setup wizard or management UI

AUTOGEN¶

Purpose: Auto-generated intermediate CA

Use case: Testing and development

Characteristics:

Signed by auto-generated root CA
Automatically created issuing CA
Key stored in configured crypto provider
Suitable for test environments

Generation: Created when auto-gen PKI is enabled

LOCAL_PKCS11¶

Purpose: Locally managed CA with key in PKCS#11 provider

Use case: Production deployments

Characteristics:

CA certificate imported or generated
Private key in hardware HSM or secure PKCS#11 token
Full control over CA hierarchy
Production-grade key protection

Setup:

Generate CA key in HSM
Import CA certificate to Trustpoint
Configure crypto provider profile
Associate CA with trust domain

Advantages of CA Mode¶

Full autonomy: No dependency on external CA availability
Immediate issuance: No network latency or external approval delays
Offline operation: Works in air-gapped networks
Simplified architecture: Fewer external dependencies
Complete control: Full visibility and control over issued certificates

Disadvantages of CA Mode¶

HSM requirement: Requires hardware HSM for production security
Operational responsibility: Organization owns CA security and compliance

RA Mode (Trustpoint acts as Registration Authority)¶

CA types: REMOTE_EST_RA, REMOTE_CMP_RA

In RA mode, Trustpoint authenticates devices, enforces policies, and orchestrates approvals, but forwards the validated certificate request to an external CA for issuance.

Use Cases¶

Integration with existing enterprise PKI
Regulatory or compliance requirements for centralized CA control
Separation of OT device management from IT certificate issuance
Hybrid deployments where some domains use local CAs and others use external CAs
Risk mitigation by not hosting CA private keys

Implementation Details¶

Certificate request flow:

Device sends CSR via EST/CMP/AOKI
Trustpoint validates device identity and applies policies
Approval workflow executes (if required)
Trustpoint forwards CSR to external CA via EST or CMP
External CA issues certificate
Trustpoint receives issued certificate
Certificate stored in PostgreSQL with device linkage
Certificate returned to device

Key characteristics:

No issuing CA private key in Trustpoint
Certificate signing delegated to external CA
Trustpoint acts as policy enforcement point
Lifecycle management (renewal, revocation) remains in Trustpoint

RA Type Details¶

REMOTE_EST_RA¶

Purpose: Forward requests to external EST server

Protocol: RFC 7030 (Enrollment over Secure Transport)

Configuration requirements:

External EST server URL
Authentication credentials (mTLS or HTTP Basic Auth)
CA certificate chain

Example use case: Integration with enterprise EST-enabled CA

REMOTE_CMP_RA¶

Purpose: Forward requests to external CMP server

Protocol: RFC 9483 (Certificate Management Protocol)

Configuration requirements:

External CMP server URL
Authentication method (shared secret or certificate)
CA certificate chain

Example use case: Integration with legacy PKI infrastructure

Advantages of RA Mode¶

Centralized PKI management: Leverage existing enterprise CA
Compliance: Meet requirements for centralized CA control
No HSM required: Trustpoint doesn’t need signing key
Trust simplification: Devices already trust enterprise CA
Risk distribution: CA key management responsibility with IT PKI team

Disadvantages of RA Mode¶

External dependency: Requires CA availability and network connectivity
Latency: Enrollment includes network round-trip to CA
Limited offline operation: Cannot issue certificates without CA access
External approval: May require additional CA-side approval steps
Integration complexity: Must integrate with specific CA API/protocol

Future Enhancements¶

SCEP RA mode: Integration with SCEP-enabled CAs
ACME RA mode: Integration with ACME-enabled CAs (e.g., Let’s Encrypt)
REST API RA mode: Generic REST-based CA integration
Automatic fallback: CA mode as fallback when RA mode CA unreachable
Certificate caching: Cache external CA responses for faster renewal
Multi-CA support: Issue from different CAs based on device type or policy