Configuration

The Sentinel reads /etc/nocert-sentinel/config.yaml. The package ships it filled in, so a normal install needs no edit.

Restart the service after any change:

sudo systemctl restart nocert-sentinel

Options

Option	Default	What it does
server_url	https://sentinel.nocert.io (shipped value)	Where the Sentinel reports. Must be HTTPS, and is required: delete the line and the service refuses to start. Change it only for a self-hosted NoCert.
key_file	/etc/nocert-sentinel/sentinel-key.json	The Ed25519 identity. Created at enrollment, mode 0600. It has to sit directly in the config file’s own directory; anywhere else and the service exits at startup.
enroll_token	empty	First-boot token for a template clone. See Enrollment and key rotation.
allow_network_scan	true	Probe the IP ranges NoCert configures for this Sentinel.
allow_filesystem_scan	true	Sweep the host’s disk for certificate files.
allow_local_scan	true	Probe the host’s own listening TLS ports.
allow_kubernetes_scan	true	Read the clusters listed below.
kubernetes_clusters	empty	Cluster connection details, 16 at most. Empty means the Kubernetes scan does nothing. See Kubernetes.
log_level	info	One of debug, info, warn, error.
log_format	json	json or text.
polling_interval	30s	How often the Sentinel asks NoCert for work.
key_rotation_check_interval	6h	How often it checks whether its key needs rotating.
key_rotation_margin	120h (5 days)	Rotate once the key has less than this left.

A key the Sentinel doesn’t recognize is a startup error, not a warning. That way a typo like allow_network_scam: false fails loudly instead of leaving scanning on.

The four kill switches

The allow_* settings are local and final. NoCert can request a scan, and a Sentinel with that switch off will not run it. Nothing you do in the web app overrides the file on the host.

Use them when the host’s owner and the NoCert operator are different people. In NoCert you can switch a scan back on. Here, only the host’s owner can.

Behind a forward proxy

The Sentinel reads HTTPS_PROXY. Add it to the unit with a drop-in:

sudo systemctl edit nocert-sentinel

[Service]
Environment=HTTPS_PROXY=http://proxy.example.com:3128
Environment=NO_PROXY=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

NO_PROXY matters for your Kubernetes API servers, which the Sentinel reaches with an HTTP client that honours the proxy variables. Scan probes do not: network and local scans dial TCP directly and ignore HTTPS_PROXY entirely, so a proxy is never a way to reach a scan target.

systemctl edit reloads the unit but doesn’t restart it, so finish with:

sudo systemctl restart nocert-sentinel

That covers the agent. APT reads its own proxy from Acquire::https::Proxy, so package installs and updates need it set separately.

What the service is allowed to do

The unit runs as the unprivileged nocert-sentinel user with every capability dropped. ProtectSystem=strict makes the filesystem read-only apart from /etc/nocert-sentinel, and NoNewPrivileges blocks privilege escalation. The Sentinel needs no root at runtime.

Read the unit yourself if you want the full list:

systemctl cat nocert-sentinel