Zeek x509.log is Zeek’s log file for certificate metadata seen in network traffic. It records X.509 fields such as subject, issuer, validity period, serial number and extensions, helping analysts inspect certificate use, trust relationships and suspicious or unexpected certificates on the wire.
What the log represents in Zeek
Zeek x509.log is not a certificate store or a full packet transcript. It is the parsed metadata view of certificates observed on the wire, which makes it useful for quickly answering what certificate was presented, who issued it, and whether the visible fields look ordinary or suspicious.
That distinction matters because analysts often need certificate intelligence without decrypting every session. The log captures the structure and trust context of X.509 material at the network edge, so it can be used even when the payload remains encrypted.
Which certificate fields it captures
The log typically includes the subject, issuer, validity window, serial number, extensions and related certificate attributes. Those fields are enough to compare one certificate against another, spot repeated issuance patterns, and identify unusual metadata such as unexpected issuers, odd lifetimes or certificate reuse across hosts.
Because the log is metadata-driven, it is strongest when used as part of broader network visibility rather than as a standalone verdict. A certificate can look legitimate in isolation and still be suspicious when its issuer chain, naming pattern or timing does not fit the surrounding environment.
Why x509.log is useful for trust and traffic analysis
x509.log helps analysts evaluate trust relationships that emerge during live connections. It can reveal which certificates are being negotiated by servers, whether internal services use expected chains, and whether a remote endpoint is presenting certificates that do not align with the organisation’s normal baseline.
It is also valuable for noticing infrastructure that relies on self-signed, short-lived, misissued or otherwise unexpected certificates. Those cases do not automatically indicate compromise, but they often justify follow-up review because certificate anomalies can signal staging, interception, impersonation or poorly controlled service deployment.
For teams building a wider monitoring practice, Zeek is often paired with network detection workflows such as the NDR Guide and the Network Forensics Guide, because certificate metadata is most useful when correlated with flow, host and session evidence.
How analysts use it in practice
In practice, x509.log supports baseline building, alert triage and hunting. Analysts compare observed certificates against known-good issuers, expected subject naming, normal validity periods and known service fingerprints. When the log shows a certificate that is rare, out of place or inconsistent with the asset or destination, it becomes a candidate for deeper inspection.
That workflow is especially important in encrypted environments, where certificate metadata may be one of the few remaining signals available before decryption or endpoint inspection. It can also help narrow investigations to specific hosts, services or time windows when reviewing suspicious TLS activity.
For readers who want the broader Zeek context, the Zeek Network Monitoring Guide explains how x509.log fits alongside other logs such as conn.log and ssl.log, while the SPIFFE workload identity specification shows how certificate-based identity and trust bundles are handled in modern workload environments.
Risk and Threat Considerations
Certificate metadata can expose weak trust assumptions, impersonation opportunities and unmanaged cryptographic relationships. If defenders do not review x509.log, attackers may hide behind certificates that are self-signed, unexpectedly issued or simply unusual enough to blend into routine encrypted traffic.
Failure mechanism: Certificate anomalies go unnoticed because the organisation treats TLS as opaque after encryption starts, or because no one baselines normal issuer, subject and validity patterns for the environment.
Impact: Malicious infrastructure, intercept attempts, rogue services or suspicious internal deployments can persist longer, and investigators lose one of the most practical ways to detect unexpected trust relationships on the network.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1573 — Encrypted Channel | x509.log helps inspect certificate metadata inside encrypted network sessions |
| T1071 — Application Layer Protocol | TLS certificate observation supports detection of C2 and other traffic hidden in common application protocols | |
| Recommendation — Correlate certificate anomalies with encrypted-session telemetry and investigate unexpected trust relationships. Use application-protocol telemetry to hunt for suspicious certificates associated with covert network activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | x509.log is audit-style evidence that analysts review for suspicious certificate activity |
| SI-4 — System Monitoring | Zeek x509.log is a monitoring source for observing certificates on live traffic | |
| Recommendation — Review certificate metadata logs for anomalies and escalate findings into incident workflows. Monitor certificate metadata continuously and alert on unusual issuer, subject, or validity patterns. | ||
Practitioner Guidance
What to watch for: Treat x509.log as a correlation source, not a verdict source. Unusual issuers, empty or generic subjects, odd validity windows, repeated reuse of the same certificate across unrelated services, and certificates that appear only in isolated pockets of the network are all worth investigating.
Governance implication: Teams should define who owns certificate review in monitoring pipelines, what baseline constitutes expected certificate behaviour, and when certificate anomalies escalate to a security investigation. That keeps x509.log from becoming an underused sensor artifact.
Related resources from NHI Mgmt Group
- How should security teams handle AI agents that need to log into SaaS applications?
- What breaks when hospitals do not log access to electronic patient data?
- How should security teams log privileged SSH access from bastion hosts?
- How should security teams log PostgreSQL activity without hurting performance?