Changelog

Dates are when the change reached production. Additive changes do not bump the API version - see versioning.

2026-09-04

• A confirmed network is scanned by a running sensor (sensor 0.9.1). Since 0.9.0 a network the sensor had not been in before waited for a decision in the console. The decision itself never reached a sensor that kept running: the sensor took the list of confirmed networks only together with a changed configuration, and a confirmation changes no configuration field. It took a restart, or an unrelated change such as pausing and resuming, before the sensor scanned the network you had just confirmed. Confirmations and withdrawals now travel with every configuration check, so they take effect within about a minute, like a pause does. The same route arms the gate on a sensor whose configuration was never saved in the console; such a sensor previously scanned whatever segment it stood in without asking.

• The daily digest now carries notices that are not about a certificate. A sensor that has stopped reporting, and a network waiting for your decision, appear in the email alongside expiring certificates. Until today they did not: the digest joined every notice to a certificate, and these two kinds have none, so they were dropped on the way out. They were visible in the console the whole time, but the one channel that reaches you when you are not looking at the console stayed silent about exactly the two things that mean your inventory is going stale. The email now names the network or the sensor in question and links to the sensors page, and its subject line counts all open notices rather than only the certificates.

• A certificate issued outside NextPKI now reaches you by email. When a certificate appears for one of your verified domains and no ordering record in NextPKI explains it, that is the most security-relevant thing this product can tell you. It was shown in the console and on no send list at all, so nobody who was not looking found out. It is now part of the daily digest, together with the one-off summary counting the certificates that predate your monitoring.

• Chat notices name what they are about. A notice delivered to Slack or Teams identified itself by its certificate, so anything without one - a silent sensor, a network waiting for a decision - arrived as “(no certificate)”. They now carry the sensor name or the network address, and the headline no longer promises certificates when it is about neither.

2026-08-22

• A sensor that changes network waits to be let in (sensor 0.9.0). Automatic discovery scans the network a host’s own interface sits in. That network is not a fixed property of the host: a notebook leaves the office, joins a hotel network, and the segment is suddenly full of strangers’ devices. From now on a network your tenant has never confirmed is reported and not scanned. It appears under Sensors with what you need to decide - which machine, on which interface, from which public address, and whether anything else of yours sees the same place - and nothing is probed there until somebody says yes.

  This also covers a target you typed yourself, when one of the host’s own interfaces sits inside it: 192.168.1.0/24 in a target list matches an employee’s living room as readily as your office. A target reached through a router is unaffected.

  Networks are recognised by a fingerprint, not by their address, because 192.168.178.0/24 is the factory setting of practically every consumer router. The sensor derives it from the gateway’s hardware address together with the network, keyed per tenant; the MAC itself never leaves your network and the value cannot be turned back into one. Where no gateway can be read, the network is marked weakly identified and only a person can confirm it.

  Three cases need no click: the first cycle of a freshly registered stationary sensor, a network another stationary sensor of yours already sees, and a report arriving from the same public address as a network you already confirmed. Sensors registered before today count as stationary; new ones default to mobile, and the class is editable per sensor.

• Declined networks are counted, not listed. The sensor detail page used to name the networks automatic discovery left alone. A declined network is by definition one outside our own limits, so its address belongs to somebody else

  • a hotel’s range, another customer’s VPN. The reason and the count carry the same attestation without keeping the address. What was scanned is still named in full.

2026-08-21

• A sensor can no longer report as a different machine. The machine ID in a report is now checked against the sensor’s own client certificate instead of being taken at its word. Previously a sensor could submit a report naming another sensor of the same tenant. Nothing crossed a tenant boundary at any point.

• Only owners and admins may configure a sensor. The console accepted sensor configuration changes from any signed-in member, including a viewer. Scan targets decide what an agent inside your network contacts, so they now need the same role as the other administrative settings.

2026-08-20

• The console shows what a sensor discovered on its own. Every scan now reports the networks auto-discovery selected and the ones it left alone with a reason, visible on the sensor detail page under What this sensor scanned on its own. The bound on automatic discovery was previously only observable in the sensor’s local log on your own host; now it is on record where you can check it, and anything found in a given segment can be identified and removed.

• Console changes reach a sensor in about a minute (sensor 0.7.0). The sensor used to fetch its configuration only on the acknowledgement of a scan report, so a change took effect two sweeps later - at the default interval, up to two hours. It now checks on its own clock, every 60 seconds by default (--config-heartbeat-secs, minimum 15). Pausing a sensor now also ends a sweep that is already running: probes in flight finish, no new one starts. A newly added exclude is honoured on the very next probe. The check carries no scan results and does not move “last scanned” in the console, only “last seen”.

• Automatic IPv4 discovery is now on by default (sensor 0.6.0), and bounded in exchange. A fresh sensor scans the networks its own interfaces sit in without being configured first, because a discovery agent that finds nothing until you configure it is not much of a discovery agent. What it picks up on its own is limited to private address space (10/8, 172.16/12, 192.168/16) in /24 or narrower: a public segment belongs to other people, carrier-grade NAT space belongs to your provider, and a /22 or wider is a routing domain rather than a segment. Anything outside those bounds is still scanned if you list it as a target, and every skipped network is logged with its reason. Turn the whole thing off with --enable-ipv4-discovery=false or the switch on the sensor’s detail page. IPv6 discovery is unchanged and stays off.

  A sensor you have already configured keeps what you set. The database default applies to sensors registering from now on; existing ones are not changed by the update.

• The sensor reports its running version on every report. Until now the version was recorded once, at registration, so a sensor that had self-updated for months still showed the version it was enrolled with. The console now shows what is actually running.

2026-08-16

• A sensor can relay for segments with no route outbound. Start one with --relay-listen and the sensors behind it point --proxy at it. The relay forwards CONNECT only, only to the endpoints it is itself configured with, and it never terminates TLS - the mTLS session runs through end to end, so the relay host cannot read or forge a report. The sensor detail page now shows Reports via for every sensor, and proxy_endpoint in the API carries the same value, with credentials stripped by the sensor. See segments with no route outbound.

• Optional automatic discovery, off by default. (The IPv4 default changed on 2026-08-20, see above.) Two new fields, enable_ipv4_discovery and enable_ipv6_discovery. With them off - which is what every existing sensor keeps doing - nothing but the configured targets is ever contacted. IPv4 adds the networks the sensor’s own interfaces sit in, and nothing beyond them: no sweeping for neighbours, no adjacent ranges. IPv6 asks the kernel for the neighbours it already knows, because a /64 is too large to walk; that one is Linux only and starts near empty. Excludes still win over anything discovered. See automatic discovery.

• Separate timeouts for connect and handshake, and a throttle. New fields dial_timeout_ms, handshake_timeout_ms and scan_throttle_delay_ms. The phases want different numbers: a dead address should be given up on in milliseconds, a loaded mail server needs seconds to greet. Both are empty by default and then follow probe_timeout_ms, so nothing changes until you set them. Worth knowing either way: probe_timeout_ms was never a per-probe budget, it applies to each phase separately. See pace.

• Certificates can be excluded by issuer or subject. A new field exclude_certs on the sensor configuration holds wildcard rules such as *O=Ubiquiti*. The sensor matches them before it reports, so an excluded certificate never leaves your network rather than being collected and hidden. Appliance noise was previously impossible to filter: those devices sit on the same segments as the hosts you want to watch, so no address filter reached them. See certificate filter.

• Scan targets carry their own ports. A sensor’s configuration used to hold one global port list, and the scanner formed the cross product of every address with every port. A mail segment and a web segment could not live in one sensor without probing each other’s ports. Targets are now rows, each with its own ports and, where the port convention is not enough, its own protocol (https, smtps, imaps, pop3s, smtp, imap, pop3). See sensor configuration.

• Ports are expressions, not lists. 443,8000-8443 is valid wherever a port is typed, up to 4096 ports per target. A range that would produce more is rejected when you save it, not when the sweep is already running.

• Hostname targets send SNI, and the name is reported with the finding. Before this, a hostname was resolved and then probed like a bare address, which returns the server’s default certificate rather than the one the virtual host serves.

• New field scan_targets on the sensor configuration, in the API and on the wire. It is additive: the flat targets/ports view is still served, derived at read time, so sensors that predate this change lose nothing.

2026-08-11

• docs.nextpki.com is live. Really this time: A record, Let’s Encrypt certificate, served from the same infrastructure as the other Datargo sites. A missing page returns a real 404, not the front page.

• OAuth 2.1 for assistants. A person can now let an assistant read their inventory without handing over an API token, and take that permission back from Connected applications in the console. Grants are read-only (certs:read), enforced as a database constraint and not as a default. New page: OAuth for assistants.

  What clients must bring: PKCE with S256, a resource parameter (RFC 8707), and a client_id that is an HTTPS URL to a Client ID Metadata Document. Dynamic Client Registration is not offered; it is deprecated in the MCP authorization specification, and earlier wording here that named it as the expected path was wrong.

• Reuse of a code or a rotated refresh token revokes the whole grant, following RFC 9700. Treat invalid_grant on refresh as “authorize again” rather than “retry”.

• An OAuth token for the MCP server is rejected by the API. The audience binding is real: the MCP server exchanges it (RFC 8693) for a short-lived API token instead of passing yours through, and every exchange is in the audit log.

• MCP server documentation corrected. It is implemented, not planned: seven tools, two transports, and certificate-derived strings marked as untrusted data in every tool response. Still not hosted, see what is not available yet.

2026-08-10

• Sensor licensing stated. The discovery sensor is source available under the PolyForm Internal Use License 1.0.0 with additional grants for review, self-build and operation on a client’s behalf. It is not open source, and earlier wording that implied otherwise has been corrected.

• This documentation set was created. The API reference is generated from the OpenAPI specification rather than maintained by hand, so it cannot drift from the service. It went live at docs.nextpki.com on 2026-08-11, not on this date: the entry that claimed so was wrong and has been corrected.

• Documented the discovery sensor: what it sends, what it never sends, the full configuration surface and troubleshooting.

• Documented the renewal state machine including every transition and failure mode, CA connectors and their spending guardrails, the supported authorities and the private PKI.

• Documented discovery sources and Certificate Transparency monitoring.

• Added task guides: monitor expiry, automate renewals, onboard a domain and pagination and caching.

• Added a tutorial that walks one renewal end to end, deployment recipes for nginx, Apache, Traefik and Kubernetes, and client library examples.

• Documented every returned field in certificate fields, including which are nullable.

• The OpenAPI specification is now downloadable at /openapi/nextpki-v1.yaml.

• Stated plainly that v1 returns no certificate bytes, so a renewal cannot be completed end to end through the API. Previously implied otherwise.

• Added reference material: enumerations, roles, security model, regions, certificate lifetimes, glossary and an explicit list of what is not available yet.

Earlier

v1 of the public API - token authentication with scopes, certificate and renewal-request reads, and renewal creation - has been available since Phase 2.5. It predates this changelog; entries start above.

Planned

Listed so you can plan, not as commitments with dates.

• MCP server, to connect NextPKI to Claude, ChatGPT, Slack and similar clients over the same API and the same scopes.
• Certificate-authority account sync, importing what you already manage in your CA accounts as an inventory source.
• Relay support for the sensor, so hosts without outbound access can report through an internal proxy.

If one of these is blocking you, saying so genuinely affects the order.