Encrypted local keys
Software key generation uses the OS CSPRNG. An optional TrueRNG or other configured entropy device supplements its randomness before generation.
MYOWNCA / DOCUMENTATION
Architecture
An offline trust anchor, an online issuing service, and a signing backend chosen for your installation.
A root that stays offline
- 01Offline root CA
The root private key stays on the offline system. Transfer the issuing CA CSR to this system and return the signed certificate through a manual ceremony.
- 02Online issuing CA
The issuing key stays with its selected backend. Setup verifies the root signature, certificate validity, and matching live private key before activation.
- 03Services, people & devices
The issuer signs leaf certificates. Install the root certificate on relying clients; send the leaf and intermediate chain from your service.
The arrows describe the chain of trust, not a live connection to the root. One active issuing Sub CA is provisioned during setup. Test/Lab mode can instead create a local root and issuer for evaluation.
Two certificate workflows
- 01Request
A holder and administrator-managed template define the request. Supply a CSR, or use the template-approved server-generated-key workflow.
- 02Policy & distinct approvals
Certificate Operators review subject, SANs, profile, and purpose. The configured approval quorum must be met before issuance.
- 03Sign & record
The selected issuer backend signs the certificate. The application records the certificate, identity lineage, and audit events.
- 04Deliver & maintain
Export or securely claim the certificate. Renew before expiry, revoke when necessary, and publish revocation status for relying services.
External certificates follow a separate lane. The outbound ACME client obtains certificates from an external CA; imports track certificates issued elsewhere. Neither workflow means that myOwnCA exposes an inbound private ACME service.
Where the keys and randomness live
SmartCard-HSM / Nitrokey HSM
The token generates and protects the issuing key and performs signing. Token-generated keys use the token’s own random generator.
AWS KMS / Azure Key Vault
The issuing private key remains with the provider. Provider access and supported algorithms are checked during provisioning.
Leaf private keys
A CSR keeps the private key on the requesting host. Approved server-generated leaf keys use software storage; selecting an HSM issuer does not move every leaf key onto the HSM.
- 01Read configured device
The application reads a bounded sample from the configured device path and checks readability, timeout, and non-constant output.
- 02Mix alongside OS randomness
Device bytes are mixed additively into the kernel random pool and, where available, OpenSSL. No entropy credit is claimed for the sample.
- 03Generate the software key
Key generation proceeds after successful mixing. An unusable configured source blocks generation instead of silently falling back.
The selected signing backend is fixed for the running service. Provider migration is a separate operational procedure, not hot-swapping or automatic failover. See hardware requirements and status.
Deployment boundaries
- The web application serves role-specific portals from one service. Your proxy and network policy enforce administrative access boundaries.
- SQLite is the default database; MariaDB/MySQL is available. The supplied Compose reference is a single-host topology, not an automatic high-availability deployment.
- Keep setup access private and configure stable CRL, AIA, and OCSP URLs before production issuance.
- Back up application state and secrets. Preserve the offline root, HSM recovery material, and cloud-key access through their separate recovery procedures.
- Client trust distribution, service certificate installation, and relying-party revocation enforcement remain explicit deployment steps.
Planning a deployment?
Talk to EnigmaIS