A certificate that chains to a trusted root can still be forged, mis-issued, stolen or about to expire, and only analysis of the certificate itself shows which. MITRE D3FEND names this countermeasure Certificate Analysis (D3-CA) and defines it as "Analyzing Public Key Infrastructure certificates to detect if they have been misconfigured or spoofed using both network traffic, certificate fields and third-party logs." It sits under the Detect tactic as a child of Network Traffic Analysis, and has two children: Active Certificate Analysis (D3-ACA), which connects to servers to collect certificates, and Passive Certificate Analysis (D3-PCA), which collects them from traffic or certificate transparency logs. This card covers what D3-CA looks for, the ATT&CK techniques D3FEND relates to it, where it is implemented, how to verify it and where it is blind. It is written for detection engineers, PKI owners and network security teams; PKI fundamentals are in the Machine Identity, PKI and Certificate Lifecycle Guide.
Key takeaways
- Trust is checked, not assumed. D3FEND describes confirming that certificate data is current and anchored in a known trust model, using certificate authorities, revocation lists and third-party secure logs.
- Three detection goals. D3FEND names server impersonation, phishing domains and forged certificates as what the analysis detects, and expiring intermediate certificates as an availability risk.
- Six ATT&CK techniques share the artefact. D3FEND links D3-CA through the Certificate File artefact to encrypted command and control and exfiltration techniques and to Steal or Forge Authentication Certificates (T1649).
- TLS 1.3 moves the work. Passive sensors cannot read server certificates in TLS 1.3 sessions, so analysis shifts to active collection, certificate transparency logs, endpoints and inspection points.
- Your own PKI is in scope. Unknown certificates for your domains in transparency logs, and unexpected issuance from your internal CA, are the highest value D3-CA alerts.
D3-CA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CA (d3f:CertificateAnalysis) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Child techniques | Active Certificate Analysis (D3-ACA), Passive Certificate Analysis (D3-PCA) |
| Digital artefact | Certificate File (D3FEND relation: analyzes Certificate File) |
| Inputs named by D3FEND | Network traffic, certificate fields, certificate authorities, revocation lists, third-party secure logs |
| D3FEND reference | NIST SP 1800-16B, Securing Web Transactions: TLS Server Certificate Management |
| Main limitation | Legitimately issued certificates used by attackers look valid; encrypted handshakes hide certificates from passive sensors |
What certificate analysis checks
| Check | What it finds | Data needed |
|---|---|---|
| Chain to an approved trust anchor | Self-signed or privately rooted certificates on services that should use your approved CAs; interception devices you did not deploy | Full chain as presented, list of approved roots and intermediates |
| Validity dates | Expired or soon to expire leaf and intermediate certificates; certificates with unusually long or very recent validity periods | notBefore and notAfter |
| Revocation status | Certificates revoked after key compromise but still presented | CRL or OCSP responses for the issuer |
| Subject and subject alternative names | Look-alike domains, names outside your naming pattern, wildcard certificates where policy forbids them | Subject, SAN DNS names, SNI |
| Issuer against policy | Certificates for your domains from CAs you do not use; DNS CAA records state which CAs may issue | Issuer, certificate transparency monitoring, CAA records |
| Key and signature algorithms | Weak keys or deprecated signature hashes such as SHA-1 | Key type and length, signature algorithm |
| Fingerprint and serial against inventory | Certificates not in the inventory; known malicious certificates | SHA-1 or SHA-256 fingerprint, serial, certificate inventory, threat intelligence |
NIST SP 1800-16B frames the same risks from the PKI owner's side: outages from expired server or intermediate certificates, server impersonation with fraudulent certificates or stolen private keys, rogue certificates issued without proper vetting, and encrypted threats where command and control or exfiltration hides inside TLS with legitimate certificates. It recommends a central inventory, issuance only from approved CAs, expiry notices at about 90, 60 and 30 days, and the ability to replace all certificates on a system within about two days. Certificate expiry and renewal specifics are in the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
ATT&CK techniques D3FEND relates to D3-CA
Relationship type: inferred only. D3FEND does not hand-map D3-CA to ATT&CK. The rows below are derived through the shared Certificate File artefact: D3-CA analyzes Certificate File, and the D3FEND ontology records each technique as accessing or possibly transferring one (D3FEND 1.6.0, checked November 2026). D3FEND marks these relations inferred and experimental. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND artefact relation | What certificate analysis can show |
|---|---|---|---|
| T1071 | Application Layer Protocol | may-transfer Certificate File | Command and control servers presenting self-signed, newly issued or look-alike certificates |
| T1071.001 | Web Protocols | may-transfer Certificate File | HTTPS beacons to hosts whose certificate subject, issuer or fingerprint does not fit the destination |
| T1573.002 | Asymmetric Cryptography | may-transfer Certificate File | Encrypted channels using certificates outside approved trust anchors |
| T1041 | Exfiltration Over C2 Channel | may-transfer Certificate File | Large outbound transfers to destinations with suspicious certificates |
| T1048.002 | Exfiltration Over Asymmetric Encrypted Non-C2 Protocol | may-transfer Certificate File | Encrypted uploads to services whose certificates are unknown or untrusted |
| T1649 | Steal or Forge Authentication Certificates | accesses Certificate File | Certificates issued or presented for identities that should not hold them; forged certificates that fail chain or inventory checks |
For the network techniques, a certificate is one feature among many and attackers can use free, validly issued certificates; treat D3-CA as one input to C2 detection. Detail is in the MITRE ATT&CK T1071 Application Layer Protocol, MITRE ATT&CK T1573 Encrypted Channel and MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide pages.
Where it is implemented
| Implementation class | What it provides | Notes |
|---|---|---|
| Network security monitoring sensors | Certificate fields extracted from handshakes. Zeek, for example, writes x509.log with serial, subject, issuer, not_valid_before and not_valid_after, key and signature algorithms, key length, SAN DNS names and basic constraints, linked to sessions through cert_chain_fuids in ssl.log | Zeek's documentation states there is no x509.log for TLS 1.3 sessions, and that the server name is missing when ECH or ESNI is used |
| IDS rule engines | Rules on certificate fields. Suricata, for example, offers tls.cert_subject, tls.cert_issuer, tls.cert_serial, tls.cert_fingerprint (SHA-1), tls.sni, tls_cert_notbefore, tls_cert_notafter and tls_cert_expired | Suricata documents that tls_cert_valid checks dates only, not the chain |
| TLS inspection points | Full certificate validation at a proxy or firewall that terminates sessions, including TLS 1.3 | Privacy, legal and pinning constraints apply; see the TLS Inspection Guide |
| Certificate transparency monitors | Alerts when a certificate for your domains appears in public CT logs | CT is specified in RFC 9162 (Experimental, December 2021, obsoletes RFC 6962); see the Certificate Transparency Monitoring Guide for Web Teams |
| Certificate lifecycle management and active scanners | Inventory by scanning endpoints and pulling certificates (the D3-ACA child technique), expiry and policy checks | Covers TLS 1.3 services because the scanner is the client |
| Internal CA logging | Audit of certificate requests and issuance on enterprise CAs | The main signal for T1649 abuse of templates; see the AD CS Security Guide |
Where identity fits
Certificates are machine identities. Client certificates for mTLS, device certificates, code signing certificates and certificates used by SaaS integrations all authenticate a non-human identity, and a stolen one works like a stolen password that nobody rotates. In the Mimecast Certificate Compromise 2021, a certificate customers used to connect a service to Microsoft 365 Exchange Web Services was stolen, and the response was to block the old certificate and move customers to a replacement. Certificate analysis that knows which certificates authenticate which integrations shortens exactly that response.
Implementation steps
- Build the certificate inventory. Combine CA issuance records, active scans of your address ranges and CT log results for your domains. Record owner, issuer, expiry, fingerprint and location, as SP 1800-16B recommends.
- Define the trust policy. Approved public and internal CAs, allowed key types and lengths, approved signature algorithms, wildcard rules, and a CAA record per domain (RFC 8659 issue, issuewild and iodef properties) naming the CAs allowed to issue.
- Collect certificates from traffic. Enable certificate logging on network sensors at egress and between key zones, and record which flows are TLS 1.3 so the blind spot is measured, not guessed.
- Write rules in alert-only mode. Start with: certificates for your domains from unapproved issuers; self-signed certificates on outbound sessions; expired or revoked certificates presented by internal services; intermediates within 30 days of expiry.
- Add threat intelligence. Match certificate fingerprints and serials against known malicious certificate lists from trusted feeds.
- Tune and promote. Expect noise from internal test services, appliances with default certificates and software update endpoints. Fix the source (replace default certificates, record exceptions with an owner and expiry) rather than suppressing the rule.
- Roll back safely. Keep detection rules versioned. If a blocking action is added at an inspection point, run it in monitor mode first and keep a tested bypass list so a misfire on a business-critical service can be reverted quickly.
How to verify it works
- Test certificates: stand up a test server with a self-signed certificate, an expired certificate and a certificate from an unapproved private CA, connect from a monitored segment, and confirm each rule fires.
- CT monitor test: request a certificate for a test subdomain from an approved CA and confirm the CT monitor reports it, then confirm the inventory reconciles it.
- Coverage check: report the share of TLS sessions by version at each sensor; sessions in TLS 1.3 without inspection are outside passive D3-CA.
- Expiry drill: confirm that a certificate at 90, 60 and 30 days from expiry produces the notices the policy expects.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Certificates seen in traffic or CT logs but not in the inventory | Falling towards zero | Unknown certificates are the main finding of D3-CA |
| Outages caused by expired leaf or intermediate certificates | Zero per quarter | The availability goal D3FEND and SP 1800-16B both name |
| Time from CT log entry to triage for your domains | Tracked monthly | Mis-issued certificates are usable immediately |
| Share of egress TLS sessions with certificate visibility | Tracked per sensor | Measures the TLS 1.3 blind spot |
| Rules passing the test certificate exercise | 100% | Proves the detections work end to end |
Limits, bypasses and failure patterns
- Valid certificates on malicious servers: attackers can obtain free, domain-validated certificates for domains they control. Chain and expiry checks pass; only names, issuance age, fingerprint reputation and context remain.
- TLS 1.3 blindness: passive sensors do not see server certificates in TLS 1.3, and ECH hides the server name. Teams that rely on legacy passive rules lose coverage silently as traffic upgrades.
- Date-only validation: a rule that checks expiry but not the chain accepts any self-signed certificate with valid dates.
- Forgotten intermediates: D3FEND notes that an intermediate certificate can expire and break the trust chain even when the server certificate was renewed correctly.
- Internal CA blind spot: certificates issued by your own enterprise CA through a misconfigured template chain to a trusted root and pass every network check. Issuance logging on the CA is the control; see How to audit AD CS certificate templates.
- Revocation not checked: a stolen certificate keeps working wherever clients and sensors skip CRL or OCSP checks. See the Certificate Revocation Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-17 Public Key Infrastructure Certificates | Issuing and managing certificates under an approved policy |
| NIST SP 800-53 Rev 5 | SC-23 Session Authenticity; IA-5 Authenticator Management | Certificates as session and authenticator material |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring traffic and certificate events |
| NIST SP 1800-16B | TLS Server Certificate Management practices | Inventory, approved CAs, expiry monitoring, revocation |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Monitoring networks; analysing adverse events |
| MITRE D3FEND | Network Traffic Analysis, D3-CA, D3-ACA, D3-PCA | Parent, technique and children |
Related countermeasures
- Active Certificate Analysis (D3-ACA): pulling certificates from servers directly. See D3-ACA Active Certificate Analysis.
- Passive Certificate Analysis (D3-PCA): collecting certificates from traffic and CT logs. See D3-PCA Passive Certificate Analysis.
- SSL/TLS Inspection (ATT&CK mitigation M1020): the inspection point that restores visibility. See M1020 SSL/TLS Inspection.
- Certificate pinning: the client-side control that rejects unexpected certificates. See Certificate Pinning.
Practitioner checklist
- Keep a certificate inventory reconciled from CA records, active scans and CT logs.
- Publish CAA records naming the CAs allowed to issue for each domain.
- Monitor CT logs for every domain you own, including look-alike names where feasible.
- Log certificate fields at network sensors and measure the share of TLS 1.3 traffic each one cannot see.
- Alert on self-signed outbound certificates, unapproved issuers and expired or revoked internal certificates.
- Check chains, not just dates, and track intermediate expiry separately.
- Turn on issuance auditing on internal CAs and review it for unexpected subjects.
- Test every rule with deliberately bad test certificates and record the result.
- Map which certificates authenticate which integrations so a stolen one can be replaced fast.
Standards and references
- MITRE D3FEND: Certificate Analysis (D3-CA)
- NIST: SP 1800-16B Securing Web Transactions, TLS Server Certificate Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-17)
- IETF: RFC 9162 Certificate Transparency Version 2.0
- IETF: RFC 8659 DNS Certification Authority Authorization (CAA) Resource Record
- Zeek: x509.log documentation
- Suricata: SSL/TLS keywords
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Transparency Monitoring Guide for Web Teams · TLS Inspection Guide · MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide · MITRE D3FEND Guide