Certificate Pinning & MITM Simulator

Connection Security

Connection rate 2.0/s

Live Stats

Attempts

Secure

Blocked (pin)

Blocked (chain)

Compromised

Exposure rate

Exposure rate = attempts silently handed to the MITM proxy ÷ total attempts, while the attack is active.

How it works

Every connection attempt runs two independent checks before data flows. First, standard TLS chain validation: is the presented certificate signed by a CA the device trusts? A self-signed MITM certificate fails here regardless of pinning. Second — only if the app implements certificate pinning — the app compares the server certificate's actual fingerprint (a SHA-256 hash) against a fingerprint baked into the app at build time. A CA-valid certificate that isn't the pinned one is rejected here, even though it would sail through ordinary chain validation.

accept = chainValid(cert)
       AND (pinningOff OR sha256(cert) == pinnedHash)

Pinning On/Off — with pinning off, any CA-trusted certificate is accepted, including one issued to a rogue or compromised CA the attacker controls.
MITM attack — injects a proxy between app and server that terminates TLS and re-signs traffic with its own certificate.
MITM cert: CA-valid / Self-signed — toggles whether the attacker's certificate passes ordinary chain validation. Self-signed certs are blocked by the OS itself; CA-valid ones are the dangerous case pinning exists for.
Connection rate — how often the app opens a new connection, so you can watch the outcome distribution accumulate.

Real-world relevance: this is exactly why banking and messaging apps pin certificates — a compromised or coerced CA (or a corporate/malware root installed on the device) can mint a "valid" certificate for any domain, and only pinning catches it.

Pinned:

Presented:

Secure connection Compromised (accepted MITM) Blocked by pinning Blocked by TLS chain