MYOWNCA / DOCUMENTATION
Full features
A technical reference to what myOwnCA does, how each capability behaves, and what your deployment needs to provide.
This reference describes implemented functionality. Device-specific status and the Thales Q1 2027 roadmap are listed separately under hardware & key protection.
Certificates & policy
| Capability | Behavior | Requirements & limits |
|---|---|---|
| Certificate profiles | Issue TLS, S/MIME, and user-authentication certificates using administrator-managed templates. | Relying applications must support the intended profile and trust your CA. |
| Key algorithms | RSA 2048, 3072, and 4096; ECDSA P-256, P-384, and P-521. | The selected signing device or provider must support the chosen algorithm. |
| CSR & generated-key requests | Upload a CSR with the private key kept at the requester, or use the approved server-generated-key workflow. | Template policy controls subjects, SANs, usages, validity, and approval requirements. |
| Distinct approvals | Issue automatically when the configured quorum of Certificate Operator approvals is reached. | Defaults are two approvals for first issuance and one for renewal; administrators configure each template. |
Lifecycle & revocation
| Capability | Behavior | Requirements & limits |
|---|---|---|
| Renewal | Renew an eligible active certificate within its existing identity lineage, including key rotation. | Use Renew; changing holder, template, subject, or SANs may create a different identity. |
| Expiry notifications | Scheduled expiry checks send reminders and renewal notices through configured channels. | Enable the application-managed sweep and configure delivery settings. |
| Revocation status | Revoke internal certificates and publish CRLs; provide OCSP status when configured. | Publish stable endpoints and configure relying services to check revocation. Revoking in the portal alone does not refresh every client. |
| Chain publication | Provide issuing-chain material through AIA and certificate exports. | Set service and publication URLs before issuing production certificates. |
Trust hierarchy & key protection
| Capability | Behavior | Requirements & limits |
|---|---|---|
| Offline root | Production uses an offline root to sign the online issuing CA through a manual CSR and certificate handoff. | The root private key stays off the issuing host. Root trust distribution is operator-managed. |
| Test/Lab mode | Create a local root and issuing CA automatically with software keys. | Evaluation only. Use the production offline-root ceremony for lasting production trust. |
| Software signing | Keep signing keys in the encrypted software keystore. | Protect application secrets and include them in the documented recovery process. |
| SmartCard-HSM / Nitrokey HSM | Sign using token-held keys through PKCS#11 and OpenSC, with session-scoped PIN unlock. | Use standalone deployment for host-attached tokens. Token capabilities constrain algorithms. |
| HSM recovery | Wrap and restore eligible SmartCard-HSM keys using native OpenSC bundles and DKEK shares. | Native DKEK is N-of-N: all distinct shares are required. An application backup does not contain token private keys. |
| Cloud signing | Use AWS KMS or Azure Key Vault for the issuing CA signing key. | Requires provider credentials, permissions, and connectivity. One selected backend; no automatic local fallback. |
| TrueRNG / external entropy | Mix external-device bytes into software-key randomness before generation, alongside the OS CSPRNG. | Configure a readable device path. A configured but unusable source blocks generation. HSM-generated keys use the token RNG. |
External certificates & delivery
| Capability | Behavior | Requirements & limits |
|---|---|---|
| Outbound ACME | Obtain and automatically renew certificates from external ACME CAs using HTTP-01 or DNS-01. | This is an ACME client, not an advertised private ACME server. HTTP-01 needs reachable challenge routing; DNS-01 needs provider configuration. |
| Import & external CSRs | Track certificates issued elsewhere and import PEM or PKCS#12 material. | Imported and external certificates remain distinct from internal issuance policy. |
| Export formats | Export certificates as PEM, DER, PKCS#7, or PKCS#12 and use verified chain bundles. | Private-key export is possible only when the workflow holds exportable key material. Non-exportable HSM/cloud keys remain with their provider. |
| Secure delivery | Claim links, email OTP, QR codes, receipts, and optional mTLS proof support certificate delivery. | Configure delivery channels; mTLS proof requires a trusted proxy and explicit setup. |
| People & devices | Associate holders with certificates and optionally enable a public request workflow. | Public requests are administrator-gated and can use an email-domain allow-list. |
Governance & operations
| Capability | Behavior | Requirements & limits |
|---|---|---|
| Role separation | Separate Administrator, Certificate Operator, User, and Auditor portals. | Administrators own policy; operators handle certificate workflows. Network isolation is enforced by your proxy/firewall. |
| MFA & account recovery | Role-based TOTP, email-OTP recovery, and recovery codes. | TOTP is enabled by default for Administrators and Certificate Operators; configure the role policy during setup. |
| Dual control | Choose single-administrator or dual-control governance for privileged grants and credential resets. | Dual control requires two distinct administrators and is separate from issuance approval quorum. |
| Audit | Maintain tamper-evident audit records with optional remote syslog forwarding. | Protect integrity secrets, preserve records, and monitor integrity verification results. |
| Notifications | Configure email, Slack, and webhook channels for supported notices. | Delivery requires working channel credentials and network access. |
| Deployment & storage | Run standalone or build the supplied Docker Compose stack; use SQLite or MariaDB/MySQL. | The supplied Compose reference uses software keys. The public Docker image is still being prepared. |
| Backup & recovery | Documented application backup, restore, upgrade, rollback, and incident-response workflows. | Recover HSM/cloud keys and the offline root separately; rehearse the complete recovery procedure. |
| Licensing | Free genuine non-commercial use includes 10 active certificate identities; every commercial use requires a paid license. Source inspection is permitted; source modifications and derivative versions are prohibited under free and paid terms. Normal settings, supported APIs, and deployment configuration remain permitted. | Genuine renewals keep their identity slot. Renewals, revocation, export, monitoring, audit, and recovery are not paid-capacity gates. |
Continue with the architecture or follow the homelab walkthrough.
Planning a deployment?
Talk to EnigmaIS