HTTPS and TLS Endpoint Discovery Sensor
Discover_HTTPS inventories TLS endpoints over the network. It completes a TLS handshake against each target, captures the certificate the server presents and records which cipher suites and protocol versions the server will actually negotiate. Nothing is installed on the target.
Overview and what gets scanned
For each endpoint the sensor opens a TLS connection and records two things.
The server's certificate. The leaf certificate is captured in full — subject, issuer, serial number, validity window, signature algorithm, public key algorithm and size, key usage and the SHA-256 fingerprints of both the certificate and its public key. It becomes a certificate document in the inventory, with a companion public key document, so the certificate appears in expiry reporting and the key participates in key-reuse detection across every other sensor.
What the server will negotiate. The sensor offers cipher suites and records which ones the server accepts, together with the protocol version and the negotiated strength in bits. The result is a protocol document describing the endpoint's real TLS posture rather than its configured one — what a client would get, not what the configuration file says.
This is the difference that matters on an endpoint behind a load balancer or a terminating proxy: the sensor reports the TLS the client sees, which is the TLS that is actually in use.
What it does not produce. Intermediate and root certificates in the presented chain are not catalogued as separate materials — the leaf is the endpoint's identity and the one with an expiry that will page someone. Private keys are never accessible over TLS. Client certificate requirements are not probed; an endpoint demanding mutual TLS will refuse the handshake and is reported as unreachable.
Prerequisites
Network access. Outbound from the platform or the agent to each endpoint on its TLS port. Nothing connects back.
Credentials. None. TLS endpoint discovery is entirely unauthenticated.
Target-side prerequisites. None. The sensor is an ordinary TLS client.
Execution models. Platform execution, remote execution on an agent, and cloud execution. Off-grid bundles work provided the bundle runs where it can reach the endpoints.
Scanning an endpoint is a connection, not an attack — but cipher suite probing is repetitive. Probing every suite opens one connection per suite. On an endpoint fronted by a WAF or rate limiter this can look like a scan and be throttled or blocked. Narrow CipherSuite on a protected endpoint, or allow-list the scanning source.
Configuration fields
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
ExtName | string | Yes | Discover_HTTPS | The sensor name. Set for you by the form. |
Hosts | list | Yes | — | Endpoints to probe, as host:port. Port defaults to 443. IPv6 addresses need bracket notation — [2001:db8::1]:443. |
CipherSuite | string | No | ALL | Which suites to offer. ALL probes everything available and records what was negotiated. Also accepts HIGH, DEFAULT, TLSv1.2, TLSv1.3, or an explicit OpenSSL cipher string. |
timeout_seconds | integer | No | 10 | Per-host connection timeout. |
A minimal configuration:
ExtName: Discover_HTTPS
Hosts:
- intranet.corp.example.com
- api.corp.example.com:8443
- "[2001:db8::1]:443"A configuration that asks a specific question — does this legacy endpoint still accept weak ciphers?
ExtName: Discover_HTTPS
Hosts:
- legacy-app.corp.example.com:443
CipherSuite: "AES128-SHA:DES-CBC3-SHA:RC4-SHA"
timeout_seconds: 10A suite offered here and negotiated by the server is a finding. A suite offered and refused is the server behaving correctly.
Scoping. As with SSH, the host list is explicit and there is no range expansion. Build it from the inventory you already have — a DNS zone export, a load balancer configuration, a certificate manager's endpoint list. A few hundred endpoints per task keeps run time and failure diagnosis manageable.
Execution modes
From the portal. Add the sensor to a discovery template, set the endpoint list, assign the template to a task and run it. Certificates land in the crypto inventory and appear in the certificate expiry widgets immediately.
On an agent. The usual choice for endpoints that are not reachable from the platform segment — an internal application tier, a DMZ, a branch network. Configuration is identical.
Through the API. Deploy the task carrying the sensor and read the ingestion counts back. See the Scan and Discovery API reference.
Off-grid. Supported. The bundle must run somewhere with network reach to the endpoints.
Known limitations
| Limitation | Effect |
|---|---|
| Mutual TLS endpoints | An endpoint requiring a client certificate refuses the handshake. It is reported as a connection failure, not as an endpoint with no certificate. |
| Chain certificates | Only the leaf becomes a material. Intermediates and roots presented in the chain are not separately inventoried. |
| SNI | The name in the host list is sent as the server name. An endpoint serving several certificates by name must be listed once per name, not once per address. |
| Protocol versions below TLS 1.0 | SSL 2.0 and 3.0 are not offered. Where the platform's TLS library has disabled a version outright, the sensor cannot report whether the server would have accepted it. |
| Non-TLS services on a TLS port | A plaintext service answers the connection and fails the handshake, which is reported as a handshake failure rather than as "not TLS". |
| STARTTLS protocols | SMTP, IMAP and LDAP endpoints that upgrade an existing plaintext connection are not probed. Only endpoints that are TLS from the first byte are supported. |
Troubleshooting
Handshake failed. Three common causes, in order of likelihood: the endpoint requires a client certificate; the endpoint is not TLS on that port; or the server and the sensor share no acceptable cipher suite. The third is itself a finding worth recording — an endpoint that will not negotiate with a modern client is a availability risk as well as a crypto one.
Connection timed out. The port is filtered or the host is down. Test from the machine that runs the sensor: openssl s_client -connect <host>:<port> -servername <host>. If that fails too, it is a network problem and not a sensor problem.
The wrong certificate was captured. The endpoint serves several names from one address and the sensor was given the address rather than the name. List the name.
Certificate captured, no protocol document. The handshake succeeded but the cipher suite probe did not complete, usually because the endpoint rate-limited the repeated connections. Narrow CipherSuite and re-run.
Fewer cipher suites reported than the server supports. The sensor can only report suites it is able to offer. A suite disabled in the platform's own TLS library cannot be probed, so absence from the results is not proof of absence on the server.
Certificate expiry looks wrong in the inventory. Check the certificate's validity window on the document itself. Where an endpoint is behind a proxy that terminates TLS, the certificate discovered is the proxy's, which is the correct answer to "what does a client see" and may not be the one you were thinking of.
Getting support
Collect the platform version, the sensor configuration, the task and template names, the relevant discovery log extract, and the output of openssl s_client -connect <host>:<port> from the machine that ran the sensor. That last one resolves most cases on its own. No credentials are involved in this sensor, so nothing needs redacting beyond whatever your organisation requires for hostnames.