Skip to content

Server detection

Agent 1.5.0 and later can read the web and service configuration of the machine they run on and pre-fill a new certificate workflow from it: which server, which names, which certificate and key files, and (on Linux) which test and reload commands. It is a convenience for setting up workflows, not a scan:

  • Read-only. Detection changes nothing. Nothing is saved until you save the workflow the normal way, after reviewing every pre-filled value.
  • Local only. It reads this machine's configuration files, registry and bindings. It does not scan the network, and its results are not sent to CertIntel.
  • Not the service. The Agent service never runs it on Linux; on Windows the deployment worker reads the bindings for the desktop app.

Linux: the terminal interface

Detection runs inside sudo certintel tui, as root, because the configuration and key files it reads are usually readable only by root:

  • D on the Workflows screen, or in the post-renewal script manager (S), detects servers and pre-fills a new certificate;
  • ctrl+g on the deployment page of the certificate wizard fills in the deployment of the certificate you are editing.

The Detected servers screen says Read from this host's configuration; nothing is changed. Choose one to pre-fill the deployment. Each entry shows where it was found, its names, certificate, key and chain files, format, expiry, SHA-256 and the test and reload commands. enter uses an entry, esc closes the screen (Server detection closed; nothing was changed.). After you pick one, the terminal interface says Pre-filled from …; check every value before saving. The save page notes that the server reads … today; point it at the files the agent saves instead - the Agent saves to its own folder, and the server configuration must name that location (see Linux service targets).

Without root the terminal interface answers Read-only session: Detect servers changes the agent. Re-run as root: sudo certintel tui.

Server What is read
NGINX /etc/nginx/nginx.conf, /usr/local/nginx/conf/nginx.conf, /usr/local/etc/nginx/nginx.conf, /opt/nginx/conf/nginx.conf and their include files (globs too): server_name, ssl_certificate, ssl_certificate_key
Apache httpd /etc/apache2/apache2.conf, /etc/httpd/conf/httpd.conf, /etc/apache2/httpd.conf, /usr/local/apache2/conf/httpd.conf and their Include/IncludeOptional files: ServerName, ServerAlias, SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile
HAProxy /etc/haproxy/haproxy.cfg, /usr/local/etc/haproxy/haproxy.cfg and conf.d/*.cfg next to them: bind … crt files or folders and crt-list
LiteSpeed /usr/local/lsws/conf/httpd_config.conf and the virtual hosts' configFile: certFile, keyFile
Docker Containers whose mounts hold .pem, .crt or .key files, read from the Docker socket /var/run/docker.sock with read-only API requests (at most 64 containers), only when the socket is reachable

A file that is broken, missing or cannot be read appears as a note on the entry (for example The key file … could not be read: permission denied), never as an error that stops detection. A path that uses server variables is noted as chosen at run time. One run reports at most 256 servers (More servers were found than one detection run reports (256); the rest are left out.). When a certificate file is readable, its fingerprint and expiry are shown.

The Docker socket

Access to the Docker socket is equivalent to root on the host. Detection uses it only in the root terminal session you started, only to list containers and their mounts, and never starts, stops or changes a container. A mounted file is read from the host path; the container reads it with its own user ID.

The desktop-app path for server detection is refused on Linux: server detection through the desktop app is available only on Windows; on Linux run it from the terminal interface as root.

Windows: the desktop app

Where Button What it pre-fills
Workflows → + New certificate workflow, template dialog Detect servers on this computer… The matching template and its fields, for IIS, Remote Desktop, RD Gateway, Remote Access and WinRM bindings
The IIS step of the certificate wizard Use a detected IIS binding… The IIS site, hostname and port

Both open Servers on this computer; choose one and Pre-fill from this server, then review every value before continuing. Detection is read-only, so it needs no administrator approval (no UAC prompt).

It reads:

  • IIS HTTPS bindings (read without saving anything);
  • HTTP.sys SSL bindings, recognised as Routing and Remote Access SSTP, DirectAccess IP-HTTPS or WinRM, and as RD Gateway when the TSGateway service exists and a binding on port 443 is present;
  • the WinRM HTTPS listeners and the Remote Desktop listener settings in the registry;
  • the LocalMachine Personal, Web Hosting and Remote Desktop stores, read-only, to describe the bound certificates.

Notes explain what the Agent found, for example Remote Desktop uses its self-signed certificate., Routing and Remote Access is disabled on this computer. or Microsoft has deprecated DirectAccess; plan a move to Always On VPN. The matching templates are described in Microsoft services.

Test status

Windows detection was tested with recorded (canned) system data, not on a live server with these roles.