Certificate visibility without key custody
Nocert observes certificates across public endpoints and private scopes configured for Sentinel. It stays outside customer certificate issuance, renewal, deployment, and TLS termination. Nocert does not request or retain private keys for monitored certificates.
What crosses from your environment to Nocert
Sentinel is an open-source Apache-2.0 agent deployed on infrastructure you control. It sends certificate observations and the metadata needed to locate them. File paths, internal addresses, and Kubernetes object names may be included when those scan modes are enabled.
Private keys for monitored certificates, the Sentinel signing private key, and Kubernetes credentials
Depending on the enabled scan, Nocert receives
- Certificate data
- Certificate DER, SHA-256 fingerprints, and presented-chain fingerprints.
- Endpoint and TLS context
- 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.
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
Enrollment and report authentication Token-based enrollment, Ed25519-signed reports, and server-verified identity
Enrollment sends the organization-issued token and Sentinel public key. It can also include hostname, OS, architecture, version, a locally detected primary IP, and non-virtual interface subnets.
After enrollment, task polls, reports, and key rotations use RFC 9421 HTTP Message Signatures with Ed25519. The backend derives the organization and Sentinel identity from the authenticated key and assigns server-side timestamps to accepted observations.
Authentication, parsing, and tenant isolation
The Nocert service stack, including certificate parsing, can run in Nocert's EU environment or as a self-hosted Custom deployment on infrastructure you control.
Every Sentinel request to Nocert is authenticated No inbound port. After enrollment, Sentinel signs task requests, reports, and key rotations.
Sentinel does not accept inbound connections. Enrollment uses an organization-issued token. After enrollment, task polls, reports, and key rotations use RFC 9421 HTTP Message Signatures with Ed25519. The backend derives organization scope from the authenticated Sentinel key and rejects replayed nonces.
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.
Workspace data is isolated by organization Organization scope comes from the server; each organization has separate search indices.
For authenticated workspace requests, the server gets the organization from the session. Elasticsearch uses a separate set of indices for each organization, and PostgreSQL queries are scoped to that organization.
You control what Sentinel can scan Network, filesystem, local-listener, and Kubernetes scans can be disabled independently.
Local configuration can disable network, filesystem, local-listener, or 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. Kubernetes scanning requires credentials and read-only RBAC that you configure.
Controls for the hosted service
These controls apply when Nocert runs the service for you.
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, and the hosted service is designed to keep primary application data in the EU.
- 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
- The hosted service is designed to keep primary application data on OVHcloud infrastructure in France and Germany. Supporting compute may run on AWS in eu-west-1 and eu-central-1, and Cloudflare processes edge requests. Current roles and locations are listed on the Sub-processors page.
Service operation TLS 1.2 or later, private service networks, edge protection, and activity history.
- Transport
- Customer-facing website and API traffic 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.
Documents for security and procurement review
See who operates Nocert, how data is processed, which sub-processors we use, and how to report a vulnerability—without creating an account.
Found a vulnerability?
Send the details through the contact page. RFC 9116 contact metadata is published in security.txt.