A certificate only proves something if someone checks it, and most organisations check the certificates of their own servers far less often than attackers forge, copy or misuse them. MITRE D3FEND names the active form of that check Active Certificate Analysis (D3-ACA) and defines it as "Actively collecting PKI certificates by connecting to the server and downloading its server certificates for analysis." It sits under the Detect tactic as a child of Certificate Analysis (D3-CA), alongside Passive Certificate Analysis (D3-PCA), which inspects certificates seen in traffic or logs rather than by connecting. This card covers the four checks D3FEND describes, the ATT&CK techniques it relates to D3-ACA, how active scanning is implemented, how to verify it and where it falls short. It is written for detection engineers, PKI owners and threat hunters. Certificate lifecycle basics are in the Machine Identity, PKI and Certificate Lifecycle Guide.
Key takeaways
- Active means you connect. D3-ACA opens a TLS connection to a server and retrieves its certificate chain, so it sees what a client would see today, including servers that no log or traffic sensor has recorded.
- Four checks, per D3FEND. Validity (the signature verifies), path (the chain reaches a trusted anchor), configuration (key usage fits the role) and revocation status (CRL or OCSP).
- D3FEND ties it to encrypted channels and forged certificates. Through the Certificate File artefact, D3FEND relates D3-ACA to Web Protocols (T1071.001), Asymmetric Cryptography (T1573.002), Exfiltration Over Asymmetric Encrypted Non-C2 Protocol (T1048.002) and Steal or Forge Authentication Certificates (T1649); all relations are inferred.
- Two jobs, one technique. Scanning your own estate finds misconfigured, expired and unexpected certificates; probing suspicious external hosts finds attacker infrastructure that reuses default or self-signed certificates.
- A compromised CA defeats it. D3FEND's own considerations note that if the issuing CA is compromised, every certificate it issued is suspect, and a revoked certificate looks valid until revocation is published.
D3-ACA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ACA (d3f:ActiveCertificateAnalysis) |
| Tactic | Detect |
| Parent technique | Certificate Analysis (D3-CA), itself under Network Traffic Analysis |
| Digital artefact | Certificate File (inherited from D3-CA: analyzes Certificate File) |
| Sibling | Passive Certificate Analysis (D3-PCA) |
| D3FEND reference | NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management |
| Typical tools | Network scanners with certificate retrieval, TLS configuration testers, certificate lifecycle management discovery scans, active TLS fingerprinting |
| Main limitation | Sees only endpoints you know to scan and can reach; trusts the CA hierarchy it validates against |
How it works
D3FEND describes the purpose as detecting whether certificates "have been misconfigured or spoofed" using elements of the certificate, the certificate authorities and signatures. It breaks the analysis into four checks.
| Check (D3FEND name) | What is tested | Standard behind it | Typical finding |
|---|---|---|---|
| Certificate validity analysis | The digital signature on the certificate verifies against the issuer's key; the validity period is current | RFC 5280 | Expired certificates, self-signed certificates where a CA-issued one is expected |
| Certificate path analysis | The chain from the server certificate reaches a valid trust anchor | RFC 5280 section 6, certification path validation | Missing intermediates, chains to an unexpected or private root |
| Certificate configuration analysis | Key usage and extended key usage fit the role, so the certificate cannot be misused | RFC 5280 key usage and extended key usage extensions | Certificates with broader usage than needed, weak keys or signature algorithms |
| Certificate revocation status analysis | Revocation status from a CRL or OCSP; D3FEND notes OCSP stapling binds the status to the handshake | RFC 5280 (CRLs), RFC 6960 (OCSP) | Revoked certificates still served; responders that cannot be reached |
RFC 6960 defines three OCSP responses: good, revoked and unknown. "Good" means no certificate with that serial number in its validity interval has been revoked; it does not on its own prove that the certificate was issued. A scanner that treats "unknown" or an unreachable responder as acceptable will pass certificates it cannot vouch for, which is the soft-fail problem D3FEND's considerations describe.
For the second job, hunting, the same connection yields more than the certificate. Salesforce's open source JARM project, for example, describes itself as "an active Transport Layer Security (TLS) server fingerprinting tool" that sends 10 TLS Client Hello packets and hashes the responses; its documentation lists identifying malware command and control infrastructure as a use. Combining the certificate's subject, issuer and serial with a server fingerprint is how defenders group suspicious hosts that share default or reused attacker certificates.
ATT&CK techniques D3FEND relates to D3-ACA
Relationship type: inferred only. D3FEND derives every row through the shared Certificate File artefact (D3-ACA analyzes Certificate File) and states the mappings are "inferred, experimental" (D3FEND 1.6.0, checked November 2026). IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | What active certificate analysis can show |
|---|---|---|
| T1071.001 | Application Layer Protocol: Web Protocols | An HTTPS server contacted by internal hosts presents a self-signed, newly issued or tool-default certificate |
| T1573.002 | Encrypted Channel: Asymmetric Cryptography | The certificate and TLS fingerprint of a suspected command and control server match known attacker infrastructure |
| T1048.002 | Exfiltration Over Asymmetric Encrypted Non-C2 Protocol | A destination receiving large outbound TLS transfers presents a certificate that does not match its claimed owner |
| T1649 | Steal or Forge Authentication Certificates | An internal server presents a certificate from an unexpected issuer or template, a sign of forged or misissued certificates |
D3FEND groups these under their parent techniques Exfiltration Over C2 Channel (T1041), Exfiltration Over Alternative Protocol (T1048), Application Layer Protocol (T1071) and Encrypted Channel (T1573). Attacker-side detail is in the MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide, the MITRE ATT&CK T1573 Encrypted Channel page and the MITRE ATT&CK T1071 Application Layer Protocol page.
Where it is implemented
| Implementation class | What it does | Fits when |
|---|---|---|
| Network scanners with certificate scripts | Retrieve the certificate during a port scan. Nmap's ssl-cert script, for example, reports subject, validity period and subject alternative names by default, and issuer, key type and size, signature algorithm and fingerprints at higher verbosity | Inventory of internal address ranges on a schedule |
| TLS configuration testers | Connect to a service and test protocols, ciphers and the certificate. The GPL-2.0 testssl.sh project, for example, tests any TLS service and STARTTLS services, not only port 443 | Deep checks on a known list of services |
| Certificate lifecycle management discovery | Scans networks and cloud load balancers, compares found certificates with the managed inventory, alerts on expiry and unknown issuers | Large estates that need inventory, ownership and renewal in one place, as NIST SP 1800-16 describes |
| Active TLS fingerprinting | Fingerprints how a server answers varied handshakes (JARM is one open example) to cluster servers by configuration | Threat hunting and threat intelligence enrichment of suspicious destinations |
| Client-side validation | Browsers and TLS libraries perform path and revocation checks on every connection, which is D3-ACA at the point of use | Always on; tune revocation behaviour (hard or soft fail) and trust stores |
Probing external hosts you do not own raises legal and operational questions: keep it to standard handshakes, follow your organisation's rules for contacting third-party infrastructure, and prefer threat intelligence services that already hold scan data where in doubt.
Implementation steps
- Define the target lists. Internal ranges and ports that carry TLS (443, 636 LDAPS, 3389, 8443, mail ports with STARTTLS), public hostnames, cloud load balancers and API gateways. Keep a separate, approved list for external hunting.
- Set the expected state. Record approved issuers (public and private CAs), approved key types and minimum sizes, and the expected certificate per service. The Certificate Inventory Register Template is a starting point.
- Scan in pilot. Run against one network segment, compare results to the register and fix the false positives in the register, not the rules.
- Turn findings into alerts. Alert on: unknown issuer, self-signed certificate on a production service, chain not reaching an approved anchor, revoked or unknown OCSP status, expiry inside your renewal window, and a certificate change on a service with no change ticket.
- Feed hunting. Enrich outbound TLS destinations from proxy and firewall logs with active certificate and fingerprint data, and route matches with known attacker infrastructure to the SOC.
- Schedule and roll back. Run internal scans at a frequency matched to certificate lifetimes (weekly is a common choice, not a standard) and throttle scanners on fragile networks such as OT; disable a scan profile if it causes service impact and re-run with fewer connections.
How to verify it works
- Planted test certificates: deploy a self-signed certificate and an expired certificate on approved test services and confirm each scan reports both.
- Revocation test: issue and revoke a test certificate from your private CA and confirm the scan flags it once revocation is published.
- Coverage check: compare the hosts scanned with the asset inventory and with TLS destinations seen in traffic; gaps are hosts D3-ACA cannot see.
- Hunting replay: re-run enrichment against a past incident's destinations and confirm the infrastructure would have been flagged.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| TLS endpoints scanned versus known | Above 95% | Shows the target list matches the estate |
| Certificates from unapproved issuers | Zero open beyond 7 days | Catches misissued and rogue certificates |
| Expiries found inside the renewal window | Every one has an owner and ticket | Prevents outages and stale certificates |
| Planted test certificates detected | 100% per scan cycle | Proves the scanner and alerting work |
| Outbound destinations enriched with certificate data | Rising over time | Measures the hunting use |
Limits, bypasses and failure patterns
- Valid certificates on attacker servers: attackers can obtain publicly trusted certificates for their own domains, which pass every validity and path check. The signal then comes from issuer age, domain age and fingerprint, not validity.
- Compromised or misused CA: D3FEND notes that a compromised issuing CA makes all its certificates suspect. Forged certificates from a misconfigured internal CA chain correctly; see the AD CS Security Guide.
- Revocation soft fail: D3FEND notes the revocation service may be down during a connection; clients that soft fail accept revoked certificates. Revocation design is covered in the Certificate Revocation Guide.
- Scanning only port 443: LDAPS, RDP, mail, databases and internal APIs carry certificates too, and are often the ones nobody renews.
- Server Name Indication blind spots: a scan by IP address may receive a default certificate and miss the ones served for each hostname; scan by name as well.
- Results with no owner: findings without a service owner sit in a report. Tie every endpoint to an owner in the inventory.
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-8 Transmission Confidentiality and Integrity, SI-4 System Monitoring | Protected channels and the monitoring that checks them |
| NIST CSF 2.0 | DE.CM-01 | Networks and network services are monitored to find potentially adverse events |
| MITRE ATT&CK mitigations | M1020 SSL/TLS Inspection | Related network-side control on encrypted traffic |
| MITRE D3FEND | D3-CA, D3-ACA, D3-PCA | Parent, technique and passive sibling |
Related countermeasures
- Passive Certificate Analysis (D3-PCA): inspects certificates seen in traffic and logs without connecting; together the two cover known and observed endpoints.
- Certificate Transparency monitoring: watches public logs for certificates issued for your domains; see the Certificate Transparency Monitoring Guide for Web Teams.
- Certificate pinning: a client-side control that rejects unexpected certificates; see Certificate Pinning.
- SSL/TLS inspection: see M1020 SSL/TLS Inspection. The wider D3FEND model is in the MITRE D3FEND Guide.
Practitioner checklist
- Keep a register of approved issuers, key types and expected certificates per service.
- Scan every TLS port and STARTTLS service, by hostname as well as IP address.
- Apply all four D3FEND checks: validity, path, configuration and revocation.
- Treat OCSP "unknown" and unreachable responders as findings, not passes.
- Alert on unknown issuers, self-signed production certificates and unplanned certificate changes.
- Enrich outbound TLS destinations with certificate and fingerprint data for hunting.
- Follow organisational rules before actively probing third-party hosts.
- Plant test certificates and confirm detection every scan cycle.
Standards and references
- MITRE D3FEND: Active Certificate Analysis (D3-ACA)
- NIST: SP 1800-16 Securing Web Transactions: TLS Server Certificate Management
- IETF: RFC 5280 Internet X.509 PKI Certificate and CRL Profile
- IETF: RFC 6960 Online Certificate Status Protocol (OCSP)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-17)
- Nmap: ssl-cert NSE script documentation
- testssl.sh project documentation
- Salesforce: JARM active TLS server fingerprinting
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Revocation Guide · Certificate Transparency Monitoring Guide for Web Teams · MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide · MITRE D3FEND Guide