Qertum is a self-hosted certificate authority built for the post-quantum era. Issue, track, renew and revoke X.509 certificates from a web console, a REST API, the qca CLI or any standard ACME client — signed with RSA, ECDSA, ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and ML-KEM (FIPS 203). One container, one SQLite file, no cloud dependency.
docker compose -f deploy/single-container/docker-compose.yml up -d# Sign in with the device authorization grant
$ qca auth login
✓ Open https://ca.example.internal/device and enter FJKD-QMTP
✓ Signed in as alice (admin)
# Request a post-quantum web server certificate with hybrid mode
$ qca requests create -n api.example.internal -T WebServer -k HYBRID-ECDSA-P256
ID 6f1c0b3e
STATUS Pending
$ qca requests approve 6f1c0b3e
✓ Approved — queued for signing
$ qca cert download-cert 6f1c0b3e -F pem
✓ Wrote api.example.internal.pem
$ qca cert download-cert 6f1c0b3e -F pem --pqc
✓ Wrote api.example.internal.pqc.pemA quantum computer that can forge an RSA signature does not exist yet. The deadline is still real, because replacing a PKI takes years — every root, every intermediate, every leaf, and every client that has to verify the new algorithm before you can stop issuing the old one.
So the useful thing an authority can do today is refuse to make you choose. Qertum signs with RSA, ECDSA and ML-DSA from the same root, and hybrid mode issues a classical and a post-quantum certificate together — you can start moving before every client is ready.
See what it doesNIST's draft timeline deprecates RSA and ECDSA for digital signatures after this year
And disallows them entirely after this one — for every certificate still in the chain
Certificates from a single request in hybrid mode, so the cutover needs no flag day
Everything a production certificate authority needs to do, on hardware you control — plus full post-quantum cryptography support (FIPS 203, 204, 205), ready when you are.
Support for <strong>ML-DSA (FIPS 204)</strong>, <strong>SLH-DSA (FIPS 205)</strong>, and <strong>ML-KEM (FIPS 203)</strong> alongside classical RSA and ECDSA. Choose the right algorithm per certificate — signatures, encryption, or hybrid paired issuance.
Pending, approved, processing, issued — with rejection, renewal and asynchronous revocation. Five certificate templates ship built in (web server, code signing, S/MIME, client auth, subordinate CA), permissions are per role, and every transition lands in an immutable audit log.
RFC 8555 at /acme — http-01 and dns-01 proofs, wildcards and external account binding — so certbot, cert-manager and lego renew against it unchanged. RFC 7030 enrollment lives at /.well-known/est, with Basic auth for simpleenroll and client-certificate mTLS for simplereenroll.
A CRL at /crl and an OCSP responder at /ocsp, both public and both unauthenticated by design. Delta CRLs are optional, so a large revocation list does not have to be refetched in full to stay current.
Keys are encrypted at rest with ASP.NET Data Protection, never appear in list responses, and every download is audited. Certificates enrolled through ACME or EST are signed straight from the client's CSR, so for those the authority never holds a private key at all.
HMAC-SHA256 signed lifecycle webhooks are delivered through a retrying transactional outbox. Versioned issuance policies with draft/publish workflows let you preview whether a request would be allowed before filing it. Sign-in is OIDC: use the bundled OpenIddict provider, or point Qertum at Keycloak, Entra or anything else that speaks the spec.
All runtime services wired together by Qertum.AppHost — sharing SQLite database, Data Protection keys and CA material.
Blazor UI (server-interactive), OIDC login
OpenIddict identity provider, JWT validation
REST API, CRL/OCSP responder
ACME server (RFC 8555)
EST server (RFC 7030)
Signs certs, revocations, webhooks, auto-renewal
Production deployment: The AppHost is set up for local development. For production, deploy each service independently or use the single-container stack in deploy/single-container/.
Qertum issues certificates in a hierarchical chain. The root stays offline (or sealed), intermediates handle daily issuance, and leaves protect your services.
Self-signed, in trust store
Signed by root, signs leaf
Issued to your domain/server
Why a chain? The root CA key never leaves secure storage — it only signs the intermediate. If an intermediate is compromised, you can revoke it and issue a new one without touching the root.
Qertum's approach: Your Qertum instance can be configured as either a standalone CA (root + leaf) or with separate root/intermediate hierarchy for larger deployments.
Qertum supports all finalized NIST post-quantum standards (FIPS 203, 204, 205) alongside classical RSA and ECDSA.
Purpose: Post-quantum encryption only
Purpose: Post-quantum signatures
Purpose: Post-quantum signatures with different trade-offs
Purpose: Classical signature
Purpose: Classical signature
Note: ML-KEM (FIPS 203) is encryption-only and cannot be used for signing or as a CA. All other algorithms support digital signatures.
Your Data Protection keys are sealed to the TPM chip — they never leave that hardware, making theft of your disk image useless for decryption.
Qertum generates Data Protection keys to encrypt CA private key, stored certificates, ACME EAB secrets, and webhook HMAC keys.
Keys are wrapped (encrypted) by a TPM-sealed key. The sealed key never leaves the TPM chip — it's hardware-bound.
Even if an attacker steals your disk image, they cannot decrypt the keys without the physical TPM chip that sealed them.
theft-proof: Key sealed to TPM hardware
portable: Restore disk = cannot decrypt CA keys
migrate: Export sealed key + TPM chip only
| File Key (Default) | TPM-Sealed Key | |
|---|---|---|
| Protection | OS-level encryption | Hardware-bound (TPM 2.0) |
| Theft-resistant | No — disk copy works | Yes — TPM required |
| Portability | Full backup/restore | Need TPM chip to restore |
| Use Case | Development, single-host | Production, compliance |
Settings > Secret Storage lets you choose between file key and TPM-sealed key. To migrate: seal to TPM first, then backup the sealed key + TPM chip together.
No experimental ciphers. The finalized FIPS 203, 204 and 205 post-quantum standards alongside classical RSA and ECDSA — chosen per certificate, not per deployment.
Pick an algorithm for each link in the chain and see what actually goes over the wire. Sizes are the FIPS 203/204/205 values for ML-KEM, ML-DSA and SLH-DSA.
Only the leaf and intermediate travel in the handshake — the root is already in the client's trust store. Classical certificates fit in a few hundred bytes; post-quantum signatures need several kilobytes, which is what pushes a chain past the congestion window.
Hybrid mode does not appear here on purpose. Qertum's hybrid is paired issuance — one request produces two separate certificates, and a client is served one chain or the other, never both. The handshake cost is whichever half it receives.
ML-KEM (Kyber) cannot sign, so it can only be used for encryption (S/MIME, CMS). It does not appear in TLS chains — use ML-DSA or SLH-DSA for signature algorithms.
The transmitted chain is 12.7 KB, inside the ~14.6 KB TCP initial congestion window, so the server sends it without waiting for an acknowledgement. A fully post-quantum chain still fits — ML-DSA is large compared to ECDSA, but not large enough to cost a round trip at these security levels.
Assumptions: 600 bytes of certificate metadata per certificate (subject, validity, SANs, extensions), a 1460-byte TCP MSS, and a 10-segment initial congestion window (~14.6 KB). Real certificates vary with the number of SANs and whether CT signed certificate timestamps are embedded.
FIPS 203, 204 and 205 compliant algorithms — signatures, encryption, or hybrid paired issuance. Choose the right tool for your use case.
Use ML-DSA (Dilithium) or SLH-DSA (SpookyHash) for traditional certificate usage — web servers, code signing, S/MIME, client authentication. These are FIPS 204 and 205 standardized digital signature algorithms.
Use ML-KEM (Kyber) for encryption-only use cases. Perfect for S/MIME email encryption, CMS envelope encryption, or any scenario where others need to encrypt data to your certificate holder. Cannot be used as a CA or for TLS authentication.
One request produces two independent certificates — one classical (ECDSA) and one post-quantum (ML-DSA). Serve the classical cert to legacy clients and the PQC cert to modern ones. Both share the same validity window but are separate files.
Mix and match algorithms per certificate without redeploying your CA. Start with hybrid for gradual client migration, then transition to pure PQC as browsers and operating systems add support.
Qertum supports all finalized FIPS standards alongside classical RSA and ECDSA. Mix, match and migrate at your own pace — no vendor lock-in.
Explore algorithmsBuilt for the homelab and the small network: no external database, no message broker, no cloud account. Back up /data and you have backed up the authority. Optionally seal your Data Protection keys to a TPM 2.0 chip for tamper-proof protection.
One image supervises all five services — web console, identity provider, REST API, ACME and EST endpoints, and the signing worker — sharing a single /data volume.
First launch redirects an admin to onboarding. Generate a root as RSA-4096, ECDSA, ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-128S/F or ML-KEM — or import an existing one from PEM, PKCS#7 or PKCS#12. Optionally seal your Data Protection keys to a TPM 2.0 chip for tamper-proof protection.
Approve requests from the console or the qca CLI, or let ACME and EST clients enroll themselves with auto-approval enabled. Renewal, revocation and the CRL take care of themselves. Use policy preview to see if a request would be allowed before filing it.
# The compose file lives in the repo — set QERTUM_HOST to the address
# browsers and ACME clients will use, then bring it up.
$ docker compose -f deploy/single-container/docker-compose.yml pull
$ docker compose -f deploy/single-container/docker-compose.yml up -d
✓ web console :8090
✓ identity (OIDC) :8081
✓ REST API :8082
✓ ACME directory :8083/acme/directory
# State — database, CA keypair, keyring, audit log — lives in /data.# Device authorization grant — approve in a browser, token cached locally
$ qca auth login
# Hybrid: one request, a classical and a post-quantum certificate
$ qca requests create -n api.example.internal \
-T WebServer -k HYBRID-ECDSA-P256
$ qca requests approve 6f1c0b3e
$ qca cert download-cert 6f1c0b3e -F pem
$ qca cert download-cert 6f1c0b3e -F pem --pqc
✓ Both halves of the pair written# Any RFC 8555 client works unchanged — certbot, cert-manager, lego
$ certbot register \
--server https://ca.example.internal:8083/acme/directory
$ certbot certonly --standalone \
--server https://ca.example.internal:8083/acme/directory \
-d api.example.internal
✓ http-01 challenge validated
dns-01, wildcards and external account binding are supported tooPrefer independent containers? The stack is a .NET Aspire solution — generate a multi-container manifest instead. Deployment docs.
Nothing proprietary on the wire. Your existing ACME and EST clients enroll against it unchanged, and the certificates, chains and revocation lists are the ordinary ones.
No subscription, no per-certificate pricing, no account with anyone. Run it on the box you already have, keep the root key on a volume you back up yourself, and read the code that signs with it.