Security architecture

Monitor certificates without handling private keys

Nocert monitors certificates on public endpoints and in the networks, filesystems, and Kubernetes clusters you let Sentinel scan. It does not issue, renew, deploy, or revoke those certificates, terminate TLS traffic, or request or retain their private keys.

Sentinel data boundary

What Sentinel sends to Nocert

Sentinel is an Apache-2.0 agent that runs on your infrastructure, and its complete source is published so you can read it before you run it. It sends Nocert certificate data and enough metadata to locate each certificate. Depending on the scans you enable, that can include file paths, internal addresses, and Kubernetes object names.

Remains under your control

Private keys for monitored certificates, the Sentinel signing private key, and Kubernetes credentials

Report content

What Nocert receives from enabled scans

Certificate data
Certificate DER, SHA-256 fingerprints, and presented-chain fingerprints.
Endpoint and TLS details
IP, port, optional SNI, TLS version, cipher, negotiated group, and OCSP stapling. Supported protocols and cipher enumeration are included when those checks run.
Filesystem and Kubernetes metadata
Filesystem reports can include certificate paths and warnings about private-key file permissions. Kubernetes reports can include the cluster, namespace, object, and data field containing the certificate. Scan status is included so Nocert can reconcile inventory changes.
Excluded fields

Sentinel does not report

  • Certificate private-key bytes and the Sentinel signing private key
  • Kubernetes credentials, kubeconfig contents, and private-key data such as tls.key
  • Non-certificate file contents, scanned-service credentials, and application payloads
How Sentinel authenticates to Nocert After enrolling with a token, Sentinel signs task-poll requests, reports, and key rotations with Ed25519

To enroll, Sentinel sends an organization-issued token and its public key. It can also send its hostname, OS, architecture, version, locally detected primary IP, and non-virtual interface subnets.

After enrollment, Sentinel uses Ed25519 and RFC 9421 to sign task-poll requests, reports, and key rotations. Nocert identifies the organization and Sentinel from the authenticated key, rejects replayed nonces, and adds server-side timestamps to accepted observations.

Certificate operations

Nocert is not in your certificate or TLS path

Nocert does not issue, renew, deploy, or revoke your certificates, and it does not terminate your TLS traffic. If Nocert is unavailable, your services continue serving TLS.

If the Nocert service were compromised, an attacker could access workspace data and trigger any scan type enabled in Sentinel's local configuration. Sentinel does not provide shell access or listen for inbound connections. You can disable each scan type locally.

System design

Authentication, parsing, and tenant isolation

Nocert is available as an EU-hosted service. With a self-hosted Custom deployment, you run the application and certificate parser in your environment.

Every Sentinel request to Nocert is authenticated Sentinel accepts no inbound connections. After enrollment, it signs every request to Nocert.

Sentinel accepts no inbound connections. It enrolls with an organization-scoped token, which is reusable so a fleet can self-enroll from one image. Each Sentinel then generates its own Ed25519 key pair locally and never sends the private half. After enrollment, it uses Ed25519 and RFC 9421 to sign task-poll requests, reports, and key rotations, and the enrollment token stops being an authenticator for it. You can renew the organization token at any time, which invalidates the previous one immediately without disturbing Sentinels that have already enrolled.

Domain verification unlocks wider public discovery A domain stays unverified until you publish a DNS TXT record in your own zone. Verification unlocks repeat subdomain dataset queries, DNS connector imports, and endpoints you add by hand.

When you create an organization, Nocert runs a one-off public scan of the domain after @ in the professional email address you confirm with the one-time code. A domain entered on the marketing site carries the signup handoff and prefills that work-email field; it is not independently selected as a scan target. One pass over public hostname datasets seeds it, and the scan itself reaches only hosts under the confirmed email domain, from the public internet, on TLS ports, which is the same thing any observer can do. What that scan observed keeps being rescanned, and SAN hostnames inside the same domain are followed. Reaching further requires proof of control: querying subdomain datasets again, scanning hostnames imported from a DNS connector, and adding an endpoint by hand all wait until you publish a verification token as a nocert-verify TXT record in a zone you control, which only someone with control of that zone can do. Account sign-in and password reset use one-time codes sent by email that expire after 20 minutes, with optional TOTP multi-factor authentication.

Certificate parsing is sandboxed Certificate DER is parsed in short-lived, resource-limited nsjail processes.

Nocert parses certificate DER in short-lived nsjail subprocesses. Each process has separate network, user, mount, and PID namespaces. Socket creation is blocked, /proc is not mounted, and CPU, memory, process, and file-output limits are enforced. In a self-hosted Custom deployment, the application and certificate parser run on infrastructure you control.

Nocert keeps each organization's data separate Nocert reads the organization from the session and uses separate search indices for it.

Nocert reads the organization from the authenticated session. It uses separate Elasticsearch indices for each organization and scopes PostgreSQL queries to the same organization.

You control what Sentinel can scan Network, filesystem, local-listener, and Kubernetes scans can be disabled independently.

You can disable network, filesystem, local-listener, and Kubernetes scans independently. The packaged Linux service runs as a dedicated unprivileged user with no Linux capabilities and a hardened systemd unit. Filesystem scans are limited by the permissions of the Sentinel service account. You provide the credentials and read-only RBAC used for Kubernetes scanning.

Hosted deployment

Controls for the hosted service

Identity and access Argon2id, TOTP, secure session cookies, roles, and OpenID Connect.
Passwords and MFA
Passwords use Argon2id. Time-based one-time passwords are available for multi-factor authentication.
Sessions
HTTPS deployments use host-only __Host- session cookies with Secure, HttpOnly, and SameSite=Strict attributes. The short-lived OIDC state cookie uses SameSite=Lax for identity-provider callbacks.
Roles and SSO
Application routes enforce owner, operator, and viewer permissions. OpenID Connect SSO and group-to-role mappings require an active Business or Custom entitlement.
Data protection Stored secrets are encrypted. Nocert stores customer data in France and Germany.
Encrypted secrets
Connector credentials, secret configuration values, stored enrollment tokens, and OIDC ID tokens are encrypted with AES-256-GCM. The encryption key is kept separately from the database.
Where data is hosted
Nocert stores hosted application data on OVHcloud infrastructure in France and Germany. Core scanning and alerting operations run in the EU; limited processing and transfers by payment and email providers are documented in the DPA. See Where your data lives below, and the Sub-processors page for current roles and locations.
Network and activity logs The hosted service requires TLS 1.2 or later, uses Cloudflare at the edge, and records security events.
Transport
Traffic to the customer-facing website and API requires TLS 1.2 or later. The certificate parser exposes no public port, and its parsing subprocess cannot create sockets.
Edge
Cloudflare provides WAF and DDoS mitigation in front of the hosted service.
Activity history
The workspace activity log records security-related events, including configuration changes, Sentinel lifecycle events, and alert deliveries.

Nocert is not ISO 27001 certified and does not have a SOC 2 report.

Data residency

Where your data lives

Hosted application data is stored on OVHcloud infrastructure in France and Germany. Core scanning and alerting operations run in the EU; limited processing and transfers by named providers are documented below and in the Sub-processors page.

  • Customer data Stored

    Certificates, inventory, findings, activity history, and account records.

    OVHcloud France and Germany
  • Outbound relays In transit only

    Public TLS scanning and alert delivery to Slack, Teams, and Discord use transient relays that process data in transit without persisting Customer Personal Data.

    Scaleway EU
  • Edge delivery In transit only

    WAF and DDoS mitigation in front of the hosted service, handling requests and limited technical metadata.

    Cloudflare EEA edge

Payment processing and outbound email involve providers outside the EEA under the transfer mechanisms named in the DPA. Payment providers never receive certificate or scan data. Alert emails carry the certificate and hostname details the alert is about.

Responsible disclosure

Found a vulnerability?

Send the details through the contact page. RFC 9116 contact metadata is published in security.txt.

Report a vulnerability