It started with a Slack message from someone on the support team: "is our dashboard hacked?" The internal analytics tool — served over HTTPS, certificate from a well-known CA, nothing unusual — was suddenly throwing certificate warnings for a handful of employees, all within about twenty minutes of each other.
The instinct, understandably, was to assume the worst. A man-in-the-middle attack is exactly what a sudden, unexplained certificate warning looks like from the visitor's side: the browser is telling you the certificate doesn't match what it expected. The team pulled the actual certificate being served and checked it against what was issued — identical, valid, correctly chained. Nothing was wrong with the server.
The pattern that gave it away
What actually cracked it open was noticing which employees were affected: all of them had had their laptops re-imaged by IT the same week, as part of a routine refresh cycle. The new corporate antivirus/endpoint-protection software installed on those machines was doing exactly what modern endpoint security products often do — intercepting HTTPS traffic to scan it, and re-signing it with its own locally-installed root certificate.
For most sites, that re-signed certificate is silently trusted, because the antivirus vendor's root was installed into the OS trust store as part of setup. The internal dashboard's certificate warning was happening because the new laptop image hadn't finished that trust-store provisioning step correctly — the interception was happening, but the trust wasn't.
What actually fixed it
The fix had nothing to do with the dashboard's own certificate at all. IT re-ran the endpoint protection's root certificate installation step on the affected machines, confirmed it landed in each OS's trust store, and the warnings disappeared identically across every affected laptop at once — which was itself a useful confirmation that the cause was client-side, not server-side.
The lesson that stuck
The unsettling part wasn't the bug — it was how convincingly it mimicked an actual attack. A security-conscious engineer's first instinct (assume compromise, start incident response) was the correct instinct in general, and the team didn't fault themselves for taking it seriously. But it's worth knowing this pattern exists before you're staring at it under pressure: an unexpected certificate warning that correlates with a recent device change, rather than a specific site or specific time, is worth checking against "did something change on the client" before escalating as a server-side compromise.
This case study is written to illustrate a genuine, common troubleshooting pattern. It is not a direct quotation or a verified account tied to a specific, identifiable individual or company. For the underlying technical reference, see: Fixing Antivirus/Proxy SSL Interception Warnings
Loading comments…