What we protect, and what we don't
Qertum signs certificates other systems trust, so the useful thing to publish is not a list of reassurances. It is where the keys live, what is exposed on purpose, and what the software does not do yet.
Reporting a vulnerability
Email security@qertum.com. Include the version or commit, the deployment shape, and the smallest reproduction you have. Please do not open a public issue for anything that lets someone obtain a certificate, a private key, or an unintended role.
Expect an acknowledgement within a few days. If a fix is needed, we would rather coordinate the disclosure date with you than race you to it. Everything else — bugs, papercuts, feature requests — belongs in the issue tracker.
The security model
- Private keys
- Issued private keys are encrypted at rest with ASP.NET Data Protection, never appear in list responses, and can only be downloaded by their owner or an admin — with every download written to the audit log. Certificates enrolled through ACME or EST are signed directly from the client's CSR, so for those the authority never holds a private key at all.
- The CA's own key
- The root keypair lives on the deployment's data volume, encrypted at rest. Signing goes through a single interface, and the local keypair is the only implementation today. Back up that volume: losing it loses the authority.
- Authentication
- The API takes OIDC bearer tokens, validated locally against the issuer's JWKS. Any compliant provider works. Because validation is local, a revoked token stays valid until it expires — keep access-token lifetimes short.
- Deliberately public endpoints
- The CRL at /crl, the OCSP responder at /ocsp, the ACME directory and nonce endpoints, and EST's /cacerts and /csrattrs are unauthenticated on purpose. Relying parties have to reach them without credentials for revocation checking to work at all.
- Rate limiting
- Certificate-request endpoints sit behind a sliding-window limiter. ACME uses two separate policies — a loose one for the status polling clients do by design, and a tight one for account creation, orders, finalize, key change and revocation — because a single shared window cannot serve both.
- Audit trail
- Every lifecycle transition, permission change, template edit and settings update writes an immutable audit entry with the acting identity. Entries go to rolling structured log files and are readable through an admin-only endpoint.
Known limitations
These are current, deliberate gaps. Read them before deciding Qertum fits your environment.
- No HSM or cloud key custody yet
- The signing interface exists as a seam, but the local keypair is its only implementation. PKCS#11 HSMs, Azure Key Vault and AWS KMS are designed for and not built. If your threat model requires the CA key never to exist in process memory, Qertum does not meet it today.
- Identity provider certificates sit unencrypted on the volume
- The bundled OIDC provider's signing and encryption certificates are PFX files on the data volume, protected by filesystem permissions alone. Rotation is additive and happens at start-up only, so a process that runs longer than the renewal window will not notice.
- The delta CRL base only advances on demand
- The full CRL is what refreshes the delta base. A deployment whose clients only ever fetch the delta will let the base's own NextUpdate lapse until an admin forces a reset. There is no automatic periodic refresh.
- Not FIPS validated
- Qertum implements the algorithms specified in FIPS 204. That is not the same as a CMVP-validated cryptographic module, and nothing on this site should be read as claiming one.
If you run it
- Back up the data volume. It holds the CA private key, the encryption keyring and the audit log, and nothing else can reconstruct them.
- Change the seeded admin password on first login. The account is flagged until you do, and issues no token before then.
- Terminate TLS in front of it and forward the original scheme and host, or the identity provider will advertise the wrong URLs.
- Keep access-token lifetimes short, because revocation is not immediate.
- Treat the ACME and EST ports as internet-facing if any client reaches them from outside your network.
This website
qertum.com is a static site. It sets no cookies, runs no analytics, and makes no third-party requests — fonts and every other asset are served from this origin, so visiting it does not disclose you to anyone else. It is served with a content security policy, HSTS, and a nosniff and framing deny policy.