How to read Suricata TLS logs

Suricata TLS events show handshake metadata for encrypted sessions without decrypting the application data. Reading those records helps an analyst confirm server names, protocol versions, certificate details, fingerprints, and ALPN values when reviewing sensor output.

Current Suricata deployments usually write TLS metadata into /var/log/suricata/eve.json as EVE records where event_type is tls. Suricata 8 documentation marks the older tls-log output as deprecated and scheduled for removal in Suricata 9, so EVE JSON is the safer source for new parsing, searches, and SIEM ingestion.

The fields in each TLS record depend on what the handshake exposes and what the EVE TLS logger is configured to include. TLS 1.2 can expose certificate subject, issuer, validity, and fingerprint values, while TLS 1.3 often leaves client-visible fields such as SNI, version, JA4, and ALPN. Treat missing certificate fields as a reason to inspect the protocol version and available keys before assuming the sensor missed the session.

1. Confirm that EVE contains TLS records.

   $ sudo jq -c 'select(.event_type=="tls") | {timestamp,src_ip,src_port,dest_ip,dest_port,proto,tls}' /var/log/suricata/eve.json
   {"timestamp":"2026-06-25T07:16:11.833006+0000","src_ip":"192.0.2.10","src_port":54506,"dest_ip":"198.51.100.20","dest_port":443,"proto":"TCP","tls":{"subject":"CN=www.example.net","issuerdn":"CN=www.example.net","subjectaltname":["www.example.net"],"fingerprint":"41:96:bf:25:b2:3e:24:d0:b8:63:f2:fc:5b:f7:30:7c:c4:50:8d:cf","sni":"www.example.net","version":"TLS 1.2","ja4":"t12d2708h2_a2460661a67a_eed5f1524d5c","client_alpns":["h2","http/1.1"]}}

   Use the active EVE file for the sensor, service instance, or offline capture run. If this filter returns no records, confirm that EVE TLS output is enabled and that the capture includes a complete TLS handshake.
   Related: How to enable Suricata EVE JSON output

2. Print the TLS fields analysts usually triage first.

   $ sudo jq -c 'select(.event_type=="tls") | {sni:.tls.sni,version:.tls.version,subject:.tls.subject,ja4:.tls.ja4}' /var/log/suricata/eve.json
   {"sni":"www.example.net","version":"TLS 1.2","subject":"CN=www.example.net","ja4":"t12d2708h2_a2460661a67a_eed5f1524d5c"}

   Use a "-" default in local scripts when a downstream parser requires every row to have the same columns.

3. List the TLS keys present in the event before building a saved parser around them.

   $ sudo jq -r 'select(.event_type=="tls") | .tls | keys_unsorted[]' /var/log/suricata/eve.json
   subject
   issuerdn
   subjectaltname
   serial
   fingerprint
   sni
   version
   notbefore
   notafter
   ja4
   client_alpns

   The key list shows whether ja3, ja4, certificate, ALPN, or SNI fields are present in the current output.

4. Filter the TLS records for the hostname under investigation.

   $ sudo jq -c 'select(.event_type=="tls" and .tls.sni=="www.example.net") | {time:.timestamp,client:.src_ip,server:.dest_ip,version:.tls.version,subject:(.tls.subject // "-"),fingerprint:(.tls.fingerprint // "-")}' /var/log/suricata/eve.json
   {"time":"2026-06-25T07:16:11.833006+0000","client":"192.0.2.10","server":"198.51.100.20","version":"TLS 1.2","subject":"CN=www.example.net","fingerprint":"41:96:bf:25:b2:3e:24:d0:b8:63:f2:fc:5b:f7:30:7c:c4:50:8d:cf"}

   Replace www.example.net with the incident hostname, or change the selector to a field shown by the key listing, such as subject, issuerdn, ja4, or client_alpns.

5. Check events that lack certificate fields before treating the log as incomplete.

   $ sudo jq -c 'select(.event_type=="tls" and (.tls.subject == null)) | {sni:(.tls.sni // "-"),version:(.tls.version // "-"),fields:(.tls | keys_unsorted)}' /var/log/suricata/eve.json
   {"sni":"www.example.net","version":"TLS 1.3","fields":["sni","version","ja4","client_alpns"]}

   A TLS event can be valid even when subject, issuerdn, or fingerprint is absent. Use the version and field list to separate missing logger fields from a sensor that did not parse the session.