OverviewInstallationGetting startedAgents & automationNginx on LinuxHTTPS verificationAdministrationAPI credentials

HTTPS verification

Confirm that a service presents the intended leaf certificate. Version 1.0.29 tracks each verification job and reports the result for every requested endpoint.

Die Dokumentation ist derzeit auf Englisch verfügbar. Produktoberfläche und integrierte Hilfe sind auf Deutsch verfügbar.

1. Configure endpoints

In Agent stores → Service verification, select the agent and store, then add at least one HTTPS endpoint. Both generic and certificate-specific verification reject an empty endpoint list instead of creating an empty job.

  • ▸Connect host: the IP address or DNS name the agent connects to, for example 192.0.2.10.
  • ▸Port: the service's real HTTPS port, such as 443 or 8443. Inline custom ports are preserved even when the hostname is selected automatically.
  • ▸TLS server name (SNI): the virtual host requested in the TLS handshake, for example app.example.com when connecting to an IP. Upgrade older workers before using an explicit SNI override.

From 1.0.29, distinct SNI names on the same store, host and port remain separate checks. Adding an exact duplicate retains its evidence. To replace a check, add the new endpoint and explicitly remove the old one. Refresh and Add service preserve the selected store and agent while they still exist.

If a store is saved but adding its optional HTTPS check fails, keep the saved store. The persistent warning offers Retry or Edit in form; both reuse that store. Resolve the check configuration instead of creating duplicate stores.

2. Follow the exact job

Choose Verify now. The page shows waiting/running progress and a link to the exact job, blocks concurrent verification requests for that store, then refreshes the service table with the completed results. After five minutes, Resume status checks continues tracking the same job without queuing another. Leaving the page stops UI polling, but does not cancel work already queued on the agent.

Manual verification pins the expected fingerprint from the latest confirmed deployment when queued. Pending or failed replacements do not change that expectation; legacy managed metadata is a fallback. Deployment jobs also pin their intended certificate before changing the target, and post-issuance deployment uses the just-issued certificate.

3. Interpret the endpoint result

  • ▸Match / new cert: the presented leaf fingerprint matches the expected certificate for that job.
  • ▸Mismatch / old cert: a different certificate is being served. Check the selected binding, SNI, reload and target before repeating deployment. Brief mismatches across graceful reloads are retried; persistent mismatches remain visible.
  • ▸Error / unreachable: the probe could not complete. Check network reachability, the port and TLS endpoint from the agent's network.
  • ▸Unknown: there is no usable expected certificate for comparison. Review confirmed deployment evidence rather than treating the status as success.
Job completion means the probe ran; a completed job can still contain mismatches, errors or unknown results. Fingerprint verification checks the served leaf identity. It does not establish CA trust, browser trust or hostname coverage. Validate those client requirements separately.

4. Clean up a failed location

In Locations or certificate details, an operator can select Remove failed location for a failed deployment that has never succeeded. Confirm the specific location. The action removes that location record only: the certificate, store, jobs and files on the host are retained.

Confirmed installation history, discovery observations and active pending/running retries are protected. A later successful IIS binding replaces the earlier active location for the same agent/site/port while retaining its history; a failed retry preserves the earlier success. This cleanup action does not uninstall a certificate from a host.