A one-line SQL statement ("delete from pxy_exch_intermedia_cert where cert_id =219;") confirms the MITM certificate-interception service (certstore) persists its per-connection intermediate certificates in a relational database table named pxy_exch_intermedia_cert, keyed by cert_id — concrete corroboration of certstore's cert-lifecycle storage backend at the schema level.

An internal MESA Lab report (2021-06-25) documents a live test in which a second sapp instance ('sapp B') receives fully decrypted plaintext HTTP traffic via a Unix domain socket from a third-party TLS decryption platform, while sapp A separately captures raw ciphertext via the mrzcpd driver. 24 hours of the decrypted logs (319,569 HTTP records) show the top intercepted destinations are Facebook, Twitter, Google/YouTube and Instagram, with client IPs traced to residential China Telecom/Unicom/Mobile subscribers in Guangdong, Zhejiang and other provinces.

The same 224-column TSG per-session log schema carries a full TLS- interception field set — proxy_pinning_status, proxy_intercept_status, proxy_passthrough_reason, proxy_cert_verify, proxy_intercept_error, sc_rsp_raw and sc_rsp_decrypted (raw vs. decrypted server response content) — plus ssl_esni_flag and ssl_ech_flag (explicit ECH/ESNI-usage flags), ssl_ja3_hash/ssl_ja3s_hash, and ssh_hassh (SSH client fingerprinting), confirming certstore-style MITM interception, ECH/ESNI detection, and TLS/SSH fingerprinting are all first-class fields logged on every session, not experimental add-ons.

An internal TSG troubleshooting runbook ("HTTPS证书替换策略无效果") documents the certstore MITM-certificate service actively serving/validating forged certificates keyed by SNI, walking an operator through checking certstore logs for specific real-world domains including Google's update service (update.googleapis.com) and Nvidia's GFE service (services.gfe.nvidia.com), and cross-checking keyring config live via maat_redis_tool.

certstore's own commit history documents its transparent-TLS-MITM mechanics directly: it writes the client's observed SNI into the SAN field of the leaf certificate it mints on the fly, supports ECC issuance (secp192r1/secp256r1) for those forged certs, and reads its Trusted/Untrusted decryption-keyring configuration from MAAT's DECRYPTION_KEYRING table -- confirming the interception pipeline end-to-end: client SNI in, matching forged certificate out, gated by MAAT-synced keyring policy.

The same ADC/TSG-OS installation guide's built-in factory acceptance test ("tsg-diagnose-oneshot") enumerates the product's certified MITM/content-manipulation actions as standard, tested features of every deployment: SSL interception with expired/self-signed/untrusted-root cert handling, and both SSL and HTTP proxy policies supporting redirect, block, replace, hijack, and insert actions, plus DNS request handling with drop and A/AAAA redirect (including TTL-range variants). This is vendor self-documentation, not inferred behavior.

Production network-topology docs for the Astana and Almaty (Kazakhstan / K18) sites show a live decrypted-traffic forwarding pipeline between an ADC front-end and an ASEM front-end over a direct fiber link, plus a distinct 'IP Spoofing' business function and dedicated static/dynamic proxy interception business lines, and a certificate-management endpoint (port 9991) — confirming operational TLS interception (MITM) infrastructure in production, not just lab capability, at both K18 sites.