Certificate Intelligence — User guide¶

This guide describes the day-to-day work with the web register of Certificate Intelligence. The setup of the register, exporters and scanner is described in the installation guide.

Certificate Intelligence is accessible via the browser (you will receive the exact address from your administrator). Login is performed with username and password.

There are two roles:

Role	Rights
admin	Full access — read and write (maintain governance, manage agents/scan targets/CT domains, archive, settings)
viewer	Read-only access to the inventory and all evaluations

All pages require a login; all write actions are reserved for the admin role. Changes to governance fields are recorded in the audit trail together with the logged-in user.

The certificate table¶

The central view is the certificate table. Each row is a certificate, uniquely identified by its SHA-256 fingerprint. The columns fall into three classes:

Technical fields (parsed from the certificate, not editable): fingerprint, serial number, subject/CN, SAN (DNS/IP/email), issuer, validity (not_before/not_after), key algorithm and length, signature algorithm, usage purpose (from KeyUsage/ExtendedKeyUsage: serverAuth, clientAuth, codeSigning, emailProtection …), type (leaf/intermediate/root).
Governance fields (freely editable, see below).
Derived/compliance columns: days until expiry, expiry status, weak cryptography (RSA < 2048, SHA-1 signature), self-signed on critical function, wildcard, key reuse (shared public key), orphan status, source/origin.

Operating the table:

Sort by clicking a column heading.
Filter per column via the filter row.
Show/hide columns via the column selector.
Export the current view as CSV or XLSX.

Maintaining governance fields¶

The governance layer is the core of the product: you enrich each certificate with the organisational significance that is not contained in the certificate itself. Editing is done directly in the table (inline editing), provided you have the admin role:

Field	Meaning
supports critical function	Yes/No — does the certificate carry a critical function (DORA)
supports important function	Yes/No
active / not active in use	is the certificate in productive use
owner	contact/free text
function/application/process	free text — deliberately no CMDB obligation
orphaned	manually settable/overridable (see orphan status)
custom columns	freely definable, deletable additional columns

Technical fields are immutable

Only governance and custom fields are editable. Technical fields originate from the certificate and are write-protected — any attempt to write to them is rejected. This keeps the inventory a reliable reflection of reality.

Governance survives re-import

When a certificate is imported again (e.g. during the next exporter run), the register performs an upsert on the fingerprint: technical and observation data are updated, while your manually maintained governance fields are preserved.

Audit trail: Every change to a governance field is recorded append-only with user, timestamp as well as old and new value.

Orphan status and scan linkage¶

A certificate is considered an orphan if it is assigned to nobody or was issued but observed active nowhere. The status is suggested but never set hard automatically:

You can link a certificate to one or more scan targets (n:m).
If a certificate is linked but has no current scan hit, the register suggests an orphan suspicion.
The manual orphaned field overrides the suggestion at any time — because a missing scan hit does not necessarily mean that the certificate is unused.

DORA evaluations¶

The DORA evaluations page offers predefined quick filters for the most common compliance questions — e.g. certificates on critical functions, certificates expiring soon, weak cryptography, self-signed on critical functions, revoked-but-active. Each evaluation can be exported as CSV/XLSX and is suitable as evidence (DORA Art. 8/9/28–30).

Formulated soberly

Certificate Intelligence provides evidence on the certificate landscape. It does not guarantee conformity — the assessment remains with you or your auditor.

Managing agents¶

"Agents" are the exporters and scanners that deliver data to the register. They are managed in the web front end (page Agents):

Create agent → the register generates a API token once. Note it down immediately — it is only shown at creation time.
You enter the token into the configuration of the respective exporter/scanner (see installation guide).
In the list you see per agent: assigned source, enabled status and last seen.
You can rotate the key or disable/block the agent.

The file/air-gap path requires no token (transport is handled by a human); there, the source identity is contained in the export metadata.

Air-gap import (file path)¶

For isolated segments with no network path, exporters/scanners deliver their results as an exchange-v1 file. This is copied and read into the register — in two ways:

Manual upload: page Import → select one or more exchange-v1 files (multiple selection possible) → the aggregate result is displayed.
Monitored auto-import folders: you create one or more storage locations, each with its own schedule (interval or fixed time in UTC). The register reads due folders automatically, moves processed files to verarbeitet/ and faulty ones to fehler/. Status and errors are visible per folder; folders can be paused/activated, read immediately ("Import now") or removed.

Certificate Transparency findings (CT)¶

The CT findings page discovers publicly trusted certificates of your monitored domains via Certificate Transparency logs — useful for finding "shadow certificates" that were issued outside your internal CAs.

Add domain: the new domain is validated (typos such as a space instead of a dot are rejected) and checked once immediately; thereafter on a regular schedule.
CT findings are clearly marked as external and separated from internal (CA-export) certificates via the source column or quick filters (managed/external/mixed).
Errors per domain are shown as status/tooltip and cleared again on success.

Revocation status (CRL / OCSP)¶

Certificate Intelligence checks the revocation status of each certificate in a purely read-only manner and marks it as good, revoked or unknown:

CRL via the CDP URL stored in the certificate (serial number matching, optionally signature verification against the issuer certificate from the inventory).
OCSP via the AIA URL.
Precedence: revoked beats good beats unknown.

Air-gap: Without internet access, the status remains "unknown". Alternatively, you upload a CRL file manually (DER/PEM) — whereupon all non-archived certificates of the matching issuer are re-evaluated.

Relevant for DORA: the derived revoked-but-active column (revoked_but_active) with its own page, quick filter and optional Teams alert.

Chains and trust¶

For each certificate, the issuer chain (via AKI/SKI) can be resolved. Intermediate and root certificates are kept as their own objects, so that the trust dimension can be traced.

Archiving certificates¶

Instead of hard-deleting certificates, the register works with a soft archive (compliance-compliant, reversible, audited):

Archived certificates disappear from all active lists, DORA evaluations, the XLSX export and the expiry alerts, but remain recoverable.
On the CT page you can select multiple rows and archive the marked ones or show archived ones and restore or delete permanently.
Permanent deletion is only possible for already archived certificates.

Notifications (Microsoft Teams)¶

On the Notifications page (admin role) you configure a Microsoft Teams webhook (Workflows) and receive a daily digest:

Thresholds for warning/critical (days until expiry), escalated by critical/ important function.
Toggles for further alerts: weak cryptography, orphans, self-signed on critical function, revoked-but-active.
Digest time configurable; a test send verifies the configuration immediately.

Sending runs as a built-in scheduler in the register — no external cron and no further infrastructure is required. For security reasons, the webhook URL is not shown again.