Qertum Post-Quantum Security
Source
ML-DSA-65 / 87, SLH-DSA, ML-KEM — Post-Quantum Ready

Your own
chain of trust

Qertum is a certificate authority built for the post-quantum era — self-host an open-source instance on infrastructure you control. 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). Self-hosting is one container and one SQLite file, with no cloud dependency.

Self-host Qertum View source
Self-host it docker compose -f deploy/single-container/docker-compose.yml up -d
MIT licensed Open source · Self-hosted SQLite — no external database FIPS 203, 204, 205 algorithms
qca — bash 
# 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.pem
Why now

The migration is
the hard part.

A 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 does
2030

NIST's draft timeline deprecates RSA and ECDSA for digital signatures after this year

2035

And disallows them entirely after this one — for every certificate still in the chain

2

Certificates from a single request in hybrid mode, so the cutover needs no flag day

Capabilities

A complete CA, ready for what's next

Everything a production certificate authority needs to do, on infrastructure you control — plus full post-quantum cryptography support (FIPS 203, 204, 205), ready when you are.

Full post-quantum readiness

Support for ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and ML-KEM (FIPS 203) alongside classical RSA and ECDSA. Choose the right algorithm per certificate — signatures, encryption, or hybrid paired issuance.

The full request lifecycle

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.

ACME and EST, built in

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.

Revocation that publishes

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.

Private keys stay private

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.

Webhooks, policies and your own identity provider

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.

Architecture

Six services, one Aspire stack

All runtime services wired together by Qertum.AppHost — sharing SQLite database, Data Protection keys and CA material.

Web

Blazor UI (server-interactive), OIDC login

IdentityService

OpenIddict identity provider, JWT validation

ApiService

REST API, CRL/OCSP responder

AcmeService

ACME server (RFC 8555)

EstService

EST server (RFC 7030)

QueueConsumer

Signs certs, revocations, webhooks, auto-renewal

Shared Resources
SQLite DB
Data Protection
CA Keys

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/.

How It Works

From root to leaf: the certificate chain

Qertum issues certificates in a hierarchical chain. The root stays offline (or sealed), intermediates handle daily issuance, and leaves protect your services.

1

Root CA

Self-signed, in trust store

2

Intermediate CA

Signed by root, signs leaf

3

Leaf Certificate

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.

Example: Deploying to production

  1. Generate root CA (ML-DSA-65 for balance of size/security)
  2. Create intermediate signed by root
  3. Issue leaf certificate for your server domain
Standards

FIPS standards, modern cryptography

Qertum supports all finalized NIST post-quantum standards (FIPS 203, 204, 205) alongside classical RSA and ECDSA.

FIPS 203

Key Encapsulation Mechanism

Purpose: Post-quantum encryption only

Algorithms

  • ML-KEM-512
  • ML-KEM-768
  • ML-KEM-1024

Use Cases

  • S/MIME email encryption
  • CMS envelope encryption
  • Encrypt to certificate holder

FIPS 204

Digital Signature Algorithm

Purpose: Post-quantum signatures

Algorithms

  • ML-DSA-44
  • ML-DSA-65
  • ML-DSA-87

Use Cases

  • Web server TLS certificates
  • Code signing
  • Client authentication
  • CA/intermediate keys

FIPS 205

Stateless Hash-Based Signature

Purpose: Post-quantum signatures with different trade-offs

Algorithms

  • SLH-DSA-SHA2-128S
  • SLH-DSA-SHA2-128F

Use Cases

  • Fast signing workflows
  • Resource-constrained environments
  • Alternative to ML-DSA

Classical Algorithms (Still Supported)

RSA

RFC 8017

Purpose: Classical signature

  • RSA-2048
  • RSA-4096

ECDSA

RFC 5480

Purpose: Classical signature

  • ECDSA-P256
  • ECDSA-P384

Note: ML-KEM (FIPS 203) is encryption-only and cannot be used for signing or as a CA. All other algorithms support digital signatures.

Self-hosted security

Optional TPM 2.0 sealing

On a self-hosted machine with a TPM 2.0 chip, the key ring that encrypts the CA private key can be wrapped by a key sealed to that chip, so a copy of the disk alone cannot decrypt it.

1

Generate Keys

Qertum generates Data Protection keys to encrypt CA private key, stored certificates, ACME EAB secrets, and webhook HMAC keys.

2

Seal to TPM 2.0

Keys are wrapped (encrypted) by a TPM-sealed key. The wrapping key is sealed with tpm2-tools; the sealed blob on disk is useless without the same physical TPM.

3

Hardware-Bound Protection

A stolen disk image cannot be decrypted without the TPM that sealed it. This does not protect against someone with access to the running host.

Disk Image TPM 2.0

disk copy: cannot decrypt on its own

restore elsewhere: cannot decrypt CA keys

moving hosts: switch back to the file key first

File Key vs. TPM-Sealed Key

Property File Key (Default) TPM-Sealed Key
Protection OS-level encryption Hardware-bound (TPM 2.0)
Does a disk copy decrypt the keys? Yes — the key file sits beside the data No — the same TPM is required
Portability Full backup/restore Restore needs the same TPM; losing it loses the key
Use Case Any single host Hosts with a TPM 2.0 chip and tpm2-tools

Settings > Secret Storage lets you choose between the file key and a TPM-sealed key. A TPM-sealed key never leaves that TPM: migrate back to the file key before moving to other hardware.

Standards-based cryptography

Ten algorithms, one authority

No experimental ciphers. The finalized FIPS 203, 204 and 205 post-quantum standards alongside classical RSA and ECDSA — chosen per certificate, not per deployment.

ML-DSA-65

Dilithium3 · FIPS 204 security level 3
Post-quantum signature

The default post-quantum choice for leaf certificates. Lattice-based, fast to verify, ~1.9 KB public key.

Standard FIPS 204

ML-DSA-87

Dilithium5 · FIPS 204 security level 5
Post-quantum signature

Higher security margin, for roots and long-lived intermediates. ~2.6 KB public key, ~4.6 KB signature.

Standard FIPS 204

SLH-DSA-SHA2-128S

SPHINCS+ · FIPS 205 security level 1
Post-quantum signature

SHA-2 based, ~32 KB public key, ~12 KB signatures. Faster signing than ML-DSA.

Standard FIPS 205

SLH-DSA-SHA2-128F

SPHINCS+ · FIPS 205 security level 1
Post-quantum signature

SHA-2 based, ~32 KB public key, ~17 KB signatures. ~20× faster signing than SLH-DSA-SHA2-128S.

Standard FIPS 205

ML-KEM-512

Kyber-512 · FIPS 203 encryption
Post-quantum encryption (KEM)

Encrypt to the certificate holder, not for signing. Perfect for S/MIME and CMS encryption.

Standard FIPS 203

ML-KEM-768

Kyber-768 · FIPS 203 encryption
Post-quantum encryption (KEM)

Higher security margin for long-lived keys. ~1.5× larger than ML-KEM-512.

Standard FIPS 203

ML-KEM-1024

Kyber-1024 · FIPS 203 encryption
Post-quantum encryption (KEM)

Maximum security for critical infrastructure. ~2× larger than ML-KEM-512.

Standard FIPS 203

Hybrid

Paired issuance
Classical + post-quantum

ECDSA P-256 + ML-DSA-65, or P-384 + ML-DSA-87. One request yields two certificates sharing a validity window — serve the classical one to clients that need it and the PQC one to those that do not.

Standard Two certificates

ECDSA

NIST P-256 / P-384
Classical signature

Compact keys and signatures, understood by everything. The sensible default until a client can verify ML-DSA.

Standard RFC 5480

RSA

2048-bit leaf · 4096-bit CA
Classical signature

The broadest compatibility floor, for the appliance or embedded client that will never learn a newer algorithm.

Standard RFC 8017
  • ML-DSA and SLH-DSA are signature-only: certificates carry digital signature, non-repudiation and CA key usages, never key encipherment or key agreement.
  • ML-KEM is encryption-only (KEM): it cannot sign, so it can never be a root/CA, cannot sign mail or code, and no TLS stack uses ML-KEM certificates. Use it for S/MIME and CMS encryption instead.
  • Hybrid is a leaf-and-intermediate mode. A root CA is generated as RSA, ECDSA, ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-128S/F or ML-KEM — not as a hybrid pair.
Interactive

What post-quantum costs your handshake

Pick an algorithm for each link in the chain and see what actually goes over the wire. The calculator compares RSA, ECDSA and the finalized FIPS 204 sizes for ML-DSA.

Reading this:

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.

Transmitted Chain Size 13,040 bytes
Fits the initial window
TLS handshake transmission (leaf + intermediate)
Intermediate CA certificate 7,179 bytes
Metadata (600 bytes)
Pub key (1,952 bytes)
Sig (4,627 bytes)
Leaf certificate (api.example.internal) 5,861 bytes
Metadata (600 bytes)
Pub key (1,952 bytes)
Sig (3,309 bytes)

Network diagnostics

TCP packet count 9 packets
Estimated RTT overhead +0 RTT (no extra round trip)
QUIC/UDP drop risk Minimal

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.

Handshake overhead comparison

All-classical baseline (ECDSA P-256) 1,474 bytes
1.0x (ref)
Current configuration 13,040 bytes
8.8x size
Heaviest supported (ML-DSA-87 throughout) 15,638 bytes
10.6x size

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.

Use Cases

Post-Quantum cryptography for every scenario

FIPS 203, 204 and 205 compliant algorithms — signatures, encryption, or hybrid paired issuance. Choose the right tool for your use case.

Signature-only Post-Quantum

ML-DSA-65ML-DSA-87SLH-DSA-SHA2-128SSLH-DSA-SHA2-128F

Use ML-DSA (Dilithium) or SLH-DSA (SPHINCS+) for traditional certificate usage — web servers, code signing, S/MIME, client authentication. These are FIPS 204 and 205 standardized digital signature algorithms.

Post-Quantum Encryption

ML-KEM-512ML-KEM-768ML-KEM-1024

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.

Hybrid Paired Issuance

HYBRID-ECDSA-P256HYBRID-ECDSA-P384

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.

Future-Proof Infrastructure

Any combination

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.

Ready to deploy post-quantum?

Qertum supports all finalized FIPS standards alongside classical RSA and ECDSA. Mix, match and migrate at your own pace — no vendor lock-in.

Explore algorithms
Self-host

One container, one volume, one afternoon

Built 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.

Run the container

Build the image from deploy/single-container, push it to your registry, set QERTUM_REGISTRY and QERTUM_HOST, and bring it up. One image supervises five services — web console, identity provider, REST API, ACME endpoint and the signing worker — sharing a single /data volume. It has no EST endpoint; the multi-container layout adds it.

Create your root

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.

Issue and automate

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 too

Prefer independent containers? The stack is a .NET Aspire solution — generate a multi-container manifest instead. Deployment docs.

Interoperable

Speaks the standards your stack already trusts

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.

< b-uz24uiqbe3>FIPS 204 ML-DSA< b-uz24uiqbe3>RFC 5280 X.509 & CRL< b-uz24uiqbe3>RFC 8555 ACME< b-uz24uiqbe3>RFC 7030 EST< b-uz24uiqbe3>RFC 6960 OCSP< b-uz24uiqbe3>RFC 8628 Device grant< b-uz24uiqbe3>PKCS#7 p7b chains< b-uz24uiqbe3>PKCS#12 pfx bundles
Open source · Self-hosted

Own your chain
of trust.

Run Qertum on infrastructure you control: the code is MIT licensed, with no subscription and no per-certificate pricing, and you can read the code that signs with your root.

Self-host Qertum Read the docs View source