MYOWNCA / DOCUMENTATION

Hardware & key protection

Choose where your issuing key lives, understand what your randomness source does, and see the status of each hardware integration.

An HSM protects a signing key and performs cryptographic operations. A TrueRNG supplies random bytes for software key generation. They serve different purposes and are both optional.

Deployment matters. Use standalone myOwnCA for host-attached PKCS#11 hardware. The supplied Compose stack defaults to software keys and does not include local PKCS#11 passthrough or external entropy-device mapping.

Signing hardware

Available

SmartCard-HSM

The hardware signing path used by myOwnCA: keep the issuing private key on the token and perform certificate, CSR, and CRL signing through PKCS#11.

Connection: python-pkcs11 → OpenSC PKCS#11 module → SmartCard-HSM
Requirements: Standalone deployment, compatible device/reader, OpenSC, and service-account access to the token. Configure the library path and token label; unlock the User PIN for your session.
Scope & limits: Device capabilities constrain algorithms. Initialization and DKEK recovery use OpenSC sc-hsm-tool. Native DKEK recovery needs all N-of-N shares.

Manufacturer information

Available · documented device family

Nitrokey HSM

The Nitrokey HSM family is covered by the application’s SmartCard-HSM/OpenSC integration and recovery documentation.

Connection: python-pkcs11 → OpenSC PKCS#11 module
Requirements: The same standalone PKCS#11 deployment and token access requirements as SmartCard-HSM.
Scope & limits: This entry refers to Nitrokey HSM devices, not Nitrokey FIDO or general authentication keys. Confirm the model and firmware for your deployment.

Manufacturer information

Hardware randomness

Available

TrueRNG

Use TrueRNG as an external randomness source for software-generated keys. Device bytes supplement the operating system’s cryptographic random generator.

Connection: Readable device path → additive entropy mixing → software key generation
Requirements: Configure the device on the host using its vendor instructions, grant the service account access, and select its actual device path in Admin → Random number source.
Scope & limits: A configured but unavailable, timed-out, or constant-output source blocks generation. The validation action is a wiring check, not a randomness certification. Token-generated HSM keys use the HSM’s own RNG.

Manufacturer information

Upcoming integrations

Awaiting myOwnCA validation

YubiHSM 2

A candidate for additional PKCS#11 signing-device support. Compatibility with myOwnCA has not yet been established.

Connection: Yubico yubihsm_pkcs11 module and connector
Requirements: Device-specific validation of authentication, key generation, signing, supported algorithms, and lifecycle operations.
Scope & limits: Sharing PKCS#11 does not make this an OpenSC SmartCard-HSM replacement. The SmartCard-HSM initialization and DKEK workflows do not establish YubiHSM support.

Manufacturer information

In development · Q1 2027

Thales Luna

Thales Luna support is in development and will be available for enterprise customers in Q1 2027.

Connection: Enterprise HSM integration
Requirements: Contact EnigmaIS to discuss your Luna model, firmware, and deployment requirements.
Scope & limits: Upcoming functionality. A model/firmware compatibility matrix will accompany the release; this is not a claim of current Luna support.

Manufacturer information

Configure the implemented hardware paths

SmartCard-HSM / Nitrokey HSM

Install the OpenSC and reader support appropriate to your operating system. Select PKCS#11 in the first-run wizard, then prepare or adopt the intended token. The library path is installation-specific; these are example values for a Linux host:

Example PKCS#11 settings — use your installed library and token label

MYOWNCA_HSM_BACKEND=pkcs11
MYOWNCA_PKCS11_LIB=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
MYOWNCA_PKCS11_TOKEN_LABEL=SmartCard-HSM

Do not initialize a token that already holds keys you need. Provision a new issuing key or attach an existing prepared key through setup, then complete the offline-root ceremony. SmartCard-HSM backup uses native wrapped-key material and all required DKEK shares; an application backup alone cannot restore the token.

TrueRNG / external entropy

Configure the TrueRNG on the host using the manufacturer’s instructions. Identify its actual readable device path and arrange stable naming and service-account permissions.
Open Admin → Random number source, enter the path, and use Validate source.
Save the setting. An empty saved setting selects OS randomness only.
Confirm software key generation works and monitor device availability. An unusable configured device blocks new software-key generation.

Environment fallback — only if this is your configured device path

MYOWNCA_ENTROPY_SOURCE=/dev/trng

The saved admin setting takes precedence over the environment fallback. /dev/trng and /dev/hwrng are examples, not automatic TrueRNG discovery. Container deployments need explicit device mapping and permissions. Mixing applies to software-generated keys, including server-generated leaf keys and software issuer/service keys.

Software and cloud alternatives

The encrypted software keystore is the default. AWS KMS and Azure Key Vault are implemented alternatives for the issuing key. Cloud signing requires the provider’s credentials, permissions, supported key type, and network access. It does not move holder private keys into the cloud.

Select one issuer backend during setup. A provider change is a migration procedure; there is no automatic fallback to software signing when a cloud or hardware backend fails. See the key-storage architecture.

Planning a deployment?

Talk to EnigmaIS