Repository navigation
Compliance
Documentation for the image tag 1.0.0-rc6. See Versions for the documentation of a release.
This page is for the organisation that runs Qertum. It lists the personal data Qertum keeps, how long it keeps it, and where EU rules put duties on you as the operator. It is not legal advice: have your data protection officer or lawyer confirm how it applies to you.
- You, the operator, are the controller of the personal data in your Qertum installation (GDPR Art. 4(7)). Qertum is self-hosted: nothing in it sends data to CALM Oy, and CALM Oy has no access to your installation, so CALM Oy is not your processor and there is no data processing agreement to sign.
- CALM Oy maintains Qertum as free, open-source software, provided as is under the MIT licence, with no paid support. Vulnerability reports are handled on a best-effort basis as described in SECURITY.md.
- Third parties you connect are your processors or separate controllers: an external identity provider, a webhook receiver, a log or OpenTelemetry collector, your backup storage.
| Data | Where | Whose | Kept |
|---|---|---|---|
| User name, display name, email, password hash, roles | Built-in identity service, /data/identity/users.json
|
Users of the built-in identity service | Until an administrator deletes the user (identity service page /Admin/Users). With an external identity provider Qertum keeps no user list, only the requester name and subject below |
Requester name (RequestedBy) and identity subject (RequestedBySubject) |
Certificate request records in the database | Whoever requested the certificate | As long as the certificate record exists (see below) |
Contact email (ContactEmail), owner team, ticket reference |
Certificate metadata, notices | The certificate's contact person | With the certificate record; notices for Notices__RetentionDays (90) |
| Subject name and subject alternative names | Issued certificates, CSRs | Anyone named in a certificate (client and S/MIME certificates often carry a person's name or email) | With the certificate record |
Acting identity (PerformedBy), resource name, detail |
Audit log files, {data}/audit-logs/audit-*.clef
|
Administrators and users who changed something | One file per day, AuditLog__File__RetainedFileCountLimit (365) files |
| Lifecycle events | Database | Same as the audit log |
Audit events follow the audit window; Diagnostic events LifecycleEvents__DiagnosticRetentionDays (30) days |
| Approval requests and decisions (requester, decider) | Database | Administrators |
Approvals__RetentionDays (365) days |
| Bulk operation records (who started them) | Database | Administrators |
BulkOperations__RetentionDays (365) days |
ACME account contacts (mailto: URIs) |
Database | Whoever registered the ACME account | With the ACME account |
| EST user names | Database | Usually devices, sometimes people | Until the credential is removed |
| Client IP address | Memory and the shared cache only, for rate limiting and sign-in attempt limits | Anyone who calls the API, ACME, EST or the sign-in page | For the limiter window (API: RateLimiting__WindowSeconds, 60 s). Not written to the database or the audit log |
Data that leaves the installation only where you send it:
-
Webhook bodies carry
requestedBy,decidedByandcontactEmailto the receivers an administrator configures. Treat each receiver as a recipient in your records. -
Logs go to the container's standard output, and to an OpenTelemetry collector only when
OTEL_EXPORTER_OTLP_ENDPOINTis set. Your log collection decides how long they are kept. -
Backups hold everything on
/data, so they hold all of the above. Apply your retention to the backups too, and keep them encrypted: they also hold the CA keys.
Qertum sets only the cookies it needs for signing in. It has no analytics, no tracking and loads nothing from another site, so no cookie consent banner is needed for it.
A certificate authority has to be able to say what it issued, to whom and when, and to revoke it. Qertum therefore keeps the record of every issued certificate, revoked and expired ones included, for the life of the installation: those records are the evidence behind the CRL and OCSP answers. A request that was never issued (pending or rejected) can be deleted. If you document a retention period for these records, base it on your own obligations (for example a trust service policy or an internal security policy) and on the longest-lived certificate you issue.
The audit log is hash-chained so that an edit, a deleted line or an inserted line is detectable. Qertum therefore cannot erase or rewrite one person's entries without breaking the chain, by design. The way personal data leaves the audit log is the retention window: daily files older than AuditLog__File__RetainedFileCountLimit days are removed.
For a request to erase or rectify personal data (GDPR Art. 16 and 17):
-
Identity data: delete or correct the user in the identity service (identity service page
/Admin/Users), or in your external identity provider. - Certificate records: correct the contact email and owner fields in the certificate's metadata. Revoke a certificate whose subject names the person when it should no longer be valid. The issued certificate itself cannot be changed.
-
Audit log and certificate history: in most cases you can refuse erasure here because the records are needed to meet a legal obligation or to establish, exercise or defend legal claims (Art. 17(3)(b) and (e)), or are kept for the legitimate interest of keeping the CA accountable (Art. 6(1)(f)). Record that decision. Shortening
AuditLog__File__RetainedFileCountLimitshortens how long they are kept. - Backups: data in a backup goes when the backup expires under your retention plan.
For a request to access personal data (Art. 15), an administrator exports the records with qca cert list --output json and qca audit list --output json and selects the ones that carry the person's name, subject or email. Qertum has no one-step data-subject export yet.
To keep personal data out of the records in the first place, put a role or team mailbox, not a person's address, in the contact email field, and prefer device or service names in certificate subjects.
Copy this into your own record (GDPR Art. 30) and fill in the parts in angle brackets.
| Field | Entry |
|---|---|
| Processing | Operation of an internal certificate authority (Qertum) |
| Controller and contact | <organisation, address, DPO contact> |
| Purposes | Issuing, renewing and revoking certificates; access control for the CA; accountability of CA operations (audit trail); security (rate limiting, sign-in protection) |
| Legal basis | Art. 6(1)(f) legitimate interests (securing the organisation's systems and keeping the CA accountable); Art. 6(1)(c) where a legal obligation applies (for example NIS2) |
| Data subjects | Staff and contractors who use or administer the CA; contact persons of certificates; people named in certificates |
| Categories of data | Names, user names, email addresses, identity provider subjects, roles, actions performed and their times, client IP addresses (short-lived) |
| Recipients | Administrators; webhook receivers <list>; identity provider <name>; log and backup storage <names>
|
| Transfers outside the EEA | <none, or the safeguard used> |
| Retention | As in the table above; audit log <n> days; backups <period>
|
| Security measures | See Architecture, TLS (TLS and Reverse Proxy), role-based access, two-person approval and step-up for sensitive operations, hash-chained audit log, encrypted backups |
An internal CA rarely needs a DPIA by itself: it processes ordinary identification and contact data of staff, not special categories, and does not monitor people systematically. Consider one when Qertum issues certificates that identify people on a large scale (for example client or S/MIME certificates for all staff, or for customers), or when your supervisory authority's list requires one. A DPIA would cover the data in the table above, the purposes and legal basis from the record, the risks (exposure of the audit log or backups, misuse of administrator access, issuing a certificate in someone's name) and the measures Qertum offers against them (owner-or-admin access to private keys, two-person approval, step-up, the audit chain and its off-host checkpoints).
NIS2 applies to organisations, not to software. Whether it applies to you depends on your sector and size. Providers of trust services are listed as in scope whatever their size; running a CA only for your own organisation's systems is usually not a trust service in that sense, but your organisation may be in scope for another reason. If NIS2 applies to you:
- A compromise of the CA, an issuer key or the audit trail can be a significant incident. National reporting deadlines are an early warning within 24 hours, a notification within 72 hours and a final report within one month, to your national CSIRT or competent authority.
- Issuer Compromise Recovery is the response plan for a compromised issuer; Backup and Restore and the audit checkpoints are the evidence you will need.
Qertum is not a qualified trust service and does not issue qualified certificates (for example qualified certificates for electronic signatures or qualified website authentication certificates). Nothing in it is certified under eIDAS. An operator who wants qualified status needs its own conformity assessment, supervision and a certified key store; Qertum makes no such claim.
Qertum is not monetised: CALM Oy sells no licence, support plan or hosted service for it. It is therefore not made available in the course of a commercial activity, and the CRA's manufacturer obligations do not apply to it at present (SECURITY.md says what we do instead). Every release ships a CycloneDX SBOM for each image, and from 1.0.0-rc6 the images and release files are signed (Verify a Release).
If you build Qertum into a product or service that you sell, you may become the manufacturer of that product under the CRA, with Qertum as a component you have to keep track of.
Qertum is a tool for administrators, not a consumer service, so the European Accessibility Act probably does not apply to it. Its interface has not been tested against WCAG 2.2, and no conformance statement is made.