Repository navigation
Web UI Post Quantum
Documentation for the image tag 1.0.0-rc1.1. See Versions for the documentation of a release.
Part of Using the Web UI. Qertum is post-quantum-first: it can issue certificates with ML-DSA and SLH-DSA keys, with paired classical plus post-quantum certificates, and with composite ML-DSA plus classical keys, and it can steer an organisation off classical RSA and ECDSA in stages. This page covers the screens for that. The settings behind them are in Settings and Templates and Policies.
The PQC enforcement stage decides what happens to a request, renewal or approval that uses a classical key (RSA or ECDSA). There is a CA-wide default, and a template can override it.
| Stage | Classical keys |
|---|---|
| Off | Accepted without comment, and nothing is recorded |
| Observe | Accepted, and each one is recorded as a diagnostic event so you can see who would be affected; requesters are not told |
| Warn | Accepted and recorded; requesters are warned in the web UI, CLI and REST API (ACME and EST clients see nothing) |
| Pilot | New requests are refused; renewals of existing classical certificates are still allowed, with a warning |
| Enforce | Every request, renewal, approval and CA import with a classical key is refused. No grace period and no per-request override; only an administrator-granted, time-limited exception admits one |
The default is Enforce. Always allowed at every stage: a post-quantum algorithm (ML-DSA-44, -65, -87, SLH-DSA-SHA2 at 128, 192 and 256 bits, S and F), a paired classical plus ML-DSA certificate, or a composite ML-DSA one (valid only if its ML-DSA half verifies, so it cannot be downgraded to its classical half).
The stage governs the keys in certificates this CA issues and nothing else. It does not change how ACME clients sign requests, how the identity service signs tokens, or the TLS key exchange any of these run over. It is the key exchange, not the certificate, that protects traffic from harvest-now-decrypt-later attacks.
PQC migration (needs certificates.view) answers "what would happen to what I have today if I raised the stage?" without changing anything.
Pick a Judge under stage from the selector. For each template the table counts:
- Live: certificates and requests in scope;
- Compliant: already post-quantum, paired or composite;
- Allowed and Warned: classical, but admitted under that stage, silently or with a warning;
- Refused: classical, and would be refused if renewed or approved today;
- Exception: classical, but covered by an active exception;
- Assumed key: no key algorithm is stored for the certificate, so a renewal would treat it as RSA;
- In flight: requests still moving through approval, rather than issued certificates;
- Not affected: those the chosen stage would leave alone.
When classical certificates or requests exist, a list under the table names each one with its verdict, expiry date, subject key, issuer signature and path facts, so you can go straight to the ones that need work. With none, the page says No classical certificates or requests in scope.
Below it, Observed traffic counts classical requests seen over the diagnostic retention window (30 days), per template and source, with the number of distinct identities. That is the list of teams you would surprise by tightening the stage.
Every figure describes what would happen if the certificate were renewed, or the request approved, today. It says nothing about whether the software that uses a certificate can handle its key.
A CA that signs a certificate vouches for its key. The issuer-strength setting (Settings, Issuance; qca ca strength) compares the NIST security level of the post-quantum key in a certificate with the level of the CA key that signs it:
| Key | Level |
|---|---|
| SLH-DSA-SHA2-128, ML-KEM-512 | 1 |
| ML-DSA-44 | 2 |
| ML-DSA-65, SLH-DSA-SHA2-192, ML-KEM-768 | 3 |
| ML-DSA-87, SLH-DSA-SHA2-256, ML-KEM-1024 | 5 |
A composite or hybrid certificate counts by its ML-DSA part, and a signing plus encryption pair by its ML-DSA part. In Warn (the default) a certificate whose key claims more than its issuer's key is issued with a warning naming both levels; in Enforce it is refused as a policy violation; Off skips the comparison. The same mode governs creating an intermediate CA: its key may not claim a higher level than its parent's.
Only the CA that signs the certificate is compared, and a classical (RSA or ECDSA) issuer is exempt, so a P-384 root can still sign an ML-DSA-87 intermediate during a migration. A classical subject key has no post-quantum level and is not judged here. The check runs on create, renew, update, approval and again just before signing, and the preview shows the same verdict. It compares the level a key claims; it does not say the CA's own certificate chain is sound.
PQC exceptions (the admin role) grants time-limited permission for one identity to keep a classical key on a template that is in Pilot or Enforce.
To grant one, choose the template and the classical family (RSA or ECDSA), enter a DNS name or suffix (a suffix also covers every name below it; every DNS name on the request must be covered; wildcards and IP addresses are not accepted), how many days it lasts (1 to 3650, though the server may allow fewer) and a reason. An exception covers only the names it lists, never a certificate authority key, and lapses on its own. Active ones can be revoked early; Show expired and revoked lists the rest.
Where a key algorithm is shown, a badge names its family, such as Full PQC · ML-DSA, so a classical and a post-quantum certificate are distinguishable at a glance in lists and on certificate pages. The certificate page also states whether the path from the CA to the certificate is post-quantum end to end.
- Requesting Certificates for how the stage shapes the key choices.
- Managing Certificates for the algorithm facts on a certificate.