Add LDAP and RDP TLS peer cert tracing via CertificateTrace (Phase 2)

[Pushpenderrathore]

Summary

Extends CertificateTrace peer cert tracing (introduced in #21599) to LDAP over TLS and RDP. No new operator-facing option -- operators use the existing CertificateTrace enum (off/metadata/full).

LDAP (Exploit::Remote::LDAP):

• Includes CertificateTrace
• ldap_open wraps both connection paths (keep_open: false via Rex::Proto::LDAP::Client.open; keep_open: true via Client._open) to read the server cert from the socket after the TLS handshake
• Private _ldap_trace_peer_cert helper guards against non-TLS (plain LDAP) connections silently

RDP (Exploit::Remote::RDP):

• Includes CertificateTrace
• swap_sock_plain_to_ssl calls certificate_peer_cert_trace immediately after ssl.connect while the raw OpenSSL::SSL::SSLSocket is still in scope

Dedup, color, and DB recording are delegated to #certificate_peer_cert_trace in CertificateTrace (the same logic as HTTP).

Test plan

• bundle exec rspec spec/lib/msf/core/exploit/remote/ldap_spec.rb -- 21 examples, 0 failures (7 new peer cert examples)
• bundle exec rspec spec/lib/msf/core/exploit/remote/rdp_spec.rb -- 3 examples, 0 failures
• Run an LDAP module against an LDAPS (port 636) target with set CertificateTrace metadata and confirm cert prints once
• Run an RDP scanner against a Windows target and confirm cert prints once

Notes

• Depends on Add HTTP TLS peer cert tracing via CertificateTrace (Phase 1) #21599 (Phase 1, HTTP support)
• WinRM over HTTPS is already covered by Phase 1 (WinRM includes HttpClient)
• Postgres and SMB over TLS are pending TLS support in those mixins (Phase 3)

[github-actions]

Thanks for your pull request! As part of our landing process, we manually verify that all modules work as expected.

We've added the additional-testing-required label to indicate that additional testing is required before this pull request can be merged.
For maintainers, this means visiting here.

[Pushpenderrathore]

Live lab validation against Windows Server 2022 AD CS DC (192.168.64.3)

LDAPS port 636 -- metadata mode

[*] Running module against 192.168.64.3
[CertificateTrace] --------------------------------------
  Subject    : /CN=DC1.kerberos.issue
  Issuer     : /DC=issue/DC=kerberos/CN=kerberos-DC1-CA
  Not Before : 2026-06-04 08:35:58 UTC
  Not After  : 2027-06-04 08:35:58 UTC
  SHA-256    : 5ba07d93b9243d781045c37db3fd3d0573e9dbc2f7be11d8fa5511f603dfba61

LDAPS port 636 -- full mode (shows AD CS template, SAN, EKU, extensions)

[CertificateTrace] --------------------------------------
  Subject    : /CN=DC1.kerberos.issue
  Issuer     : /DC=issue/DC=kerberos/CN=kerberos-DC1-CA
  Not Before : 2026-06-04 08:35:58 UTC
  Not After  : 2027-06-04 08:35:58 UTC
  SHA-256    : 5ba07d93b9243d781045c37db3fd3d0573e9dbc2f7be11d8fa5511f603dfba61
  Serial     : 624420865570961312750736130701723500422365186
  Version    : v3
  Public Key : RSA-2048
  Identity   : DC1.kerberos.issue (Subject CN)
  SAN        : othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:DC1.kerberos.issue
  EKU        : TLS Web Client Authentication, TLS Web Server Authentication
  Key Usage  : Digital Signature, Key Encipherment
  Extensions :
    Certificate Template Name : DomainController
    subjectKeyIdentifier : 4C:79:01:21:89:99:80:CE:0F:4A:57:08:36:9D:28:C9:A5:41:98:F8
    authorityKeyIdentifier : 66:B8:C4:19:DF:75:62:23:F4:A4:08:92:C3:8F:61:EB:BF:BC:5E:06
    crlDistributionPoints : Full Name: URI:ldap:///CN=kerberos-DC1-CA,...
    authorityInfoAccess : CA Issuers - URI:ldap:///CN=kerberos-DC1-CA,...

RDP port 3389

[CertificateTrace] --------------------------------------
  Subject    : /CN=DC1.kerberos.issue
  Issuer     : /CN=DC1.kerberos.issue
  Not Before : 2026-06-25 06:20:44 UTC
  Not After  : 2026-12-25 06:20:44 UTC
  SHA-256    : e2b701ff59a955e75d8cb06395fdc112de068a00a616ac1e0d562c991a6167ec

RDP produces a self-signed cert (Windows default) -- Subject equals Issuer, 6-month validity. Correctly identified as self-signed with no chain.

Dedup (cross-run, DB-backed)

Second run of the same module against the same host:port with CertificateTrace full produces no cert output -- the ssl.peer_cert_seen DB note from the first run suppresses it. The notes command confirms the note is present.

Notes

The ldap_query module fails with a schema query error after the cert prints -- this is pre-existing and unrelated to the tracing code (anonymous bind has insufficient privileges for schema discovery).

[Pushpenderrathore]

CI fix: LoginScanner::LDAP rspec failures

The rspec-rerun:spec --tag ~content jobs were failing with 10 failures in spec/lib/metasploit/framework/login_scanner/ldap_spec.rb. All failures showed "Unable to Connect" instead of "Successful" / "Incorrect".

Root cause: LoginScanner::LDAP includes Exploit::Remote::LDAP, so our new ldap_open hook calls _ldap_trace_peer_cert in scanner context. The scanner's RSpec doubles are spies that respond to any method (including peer_cert), so the respond_to?(:peer_cert) guard passed. The code then evaluated rhost and rport as arguments to certificate_peer_cert_trace -- but rhost internally calls datastore['RHOST'], and LoginScanner::LDAP has no datastore. That NoMethodError was caught by do_login's rescue StandardError and returned as UNABLE_TO_CONNECT.

Fix: Add return unless certificate_trace_enabled? at the top of _ldap_trace_peer_cert. certificate_trace_enabled? already guards on respond_to?(:datastore) && datastore, so it returns false in scanner context before rhost/rport are ever evaluated. Committed in 91f36cef.