Kaspersky HTTPS Inspection Broke HTTPS — Here's the Fix

Cause #1: The Kaspersky root certificate isn't trusted by the browser

Nine times out of ten, this is your problem. When you flip on HTTPS inspection in Kaspersky Endpoint Security (11.x, 12.x, or the newer 12.4+ builds), Kaspersky generates a local root CA on the endpoint and tries to push it into the Windows certificate store under Trusted Root Certification Authorities. If that push fails — Group Policy blocks it, the machine is domain-joined with a locked-down cert store, Firefox uses its own store, or the install is on a fresh image — every HTTPS site breaks with ERR_CONNECTION_RESET in Chrome or a blank page in Edge.

Firefox is the worst offender here. Mozilla has shipped its own certificate store for years, and it does not read the Windows Root store by default. So Chrome works, Edge works, Firefox dies. That asymmetry is the tell.

The fix

1. Open Kaspersky Endpoint Security → Settings → Security controls → Encrypted connections scanning.
2. Click Install certificate (or Add to trusted depending on the build). Choose Trusted root certification authorities.
3. Restart the browser. Fully — check Task Manager for orphaned chrome.exe or firefox.exe processes.
4. For Firefox specifically: also install it into Firefox's own store. about:config → security.enterprise_roots.enabled → set to true. That tells Firefox to read the Windows store. Don't skip this.

You can verify the cert landed by running this from an elevated prompt:

certutil -store Root | findstr /i kaspersky

If nothing comes back, the cert never made it. On domain machines, check whether a GPO is stripping third-party roots. I've seen this on locked-down finance environments more times than I care to count.

Cause #2: The site uses certificate pinning or HSTS preload

Some apps refuse to talk through any proxy that terminates TLS. Banking portals, Microsoft 365 endpoints (some of them), Apple services, and anything using certificate pinning will kill the connection the moment Kaspersky tries to swap the cert. The server says "that's not my certificate" and drops the TCP session. Browser shows reset. Users blame the browser. It's not the browser.

Google, Microsoft, and a bunch of SaaS vendors pin their certs. You can't intercept them without breaking things. Full stop.

The fix

Exclude those sites from inspection. Don't try to make it work — you'll waste an afternoon.

1. Kaspersky Endpoint Security → Settings → Security controls → Encrypted connections scanning → Manage exclusions.
2. Add the domain. Use the wildcard form: *.microsoft.com, *.apple.com, *.google.com.
3. Better yet, create a category-based exclusion. Kaspersky ships a default list of "trusted applications" and "sites with EV certificates" — enable Do not scan encrypted traffic for sites with extended validation certificates. That handles most banks automatically.

If you're pushing this via Kaspersky Security Center, the policy path is Endpoint control → Encrypted connections scanning → Exclusions. Set it once, deploy to the group, done. Chasing this per-endpoint is a rookie move.

Cause #3: Application-level conflicts (VPN clients, proxies, other AV)

Two TLS terminators on one box never ends well. If you've got a Cisco AnyConnect, Zscaler, Netskope, Palo Alto GlobalProtect, or a second AV with its own SSL inspection, Kaspersky and the other product fight over the same socket. Result: RST packets everywhere and users staring at The connection to the server was reset.

I've seen this most with Cisco Umbrella roaming clients and older versions of Forcepoint. The Kaspersky WFP (Windows Filtering Platform) callout and the other vendor's callout collide at the kernel level. Browsers can't recover because the RST arrives mid-handshake.

The fix

1. Pick one TLS inspector. Disable HTTPS inspection in one product — usually the second one you installed.
2. If you must keep both, exclude the other product's process from Kaspersky scanning. Add the exe under Settings → Exclusions → Specify trusted applications.
3. For VPN clients specifically: exclude the VPN adapter's virtual NIC from Kaspersky's Firewall and Network Attack Blocker. The virtual adapter name matters — Cisco AnyConnect Virtual Miniport, PANGP Virtual Ethernet Adapter, etc.
4. Reboot. WFP callouts don't unload cleanly without one.

Quick sanity test: disable the other product's SSL inspection, leave Kaspersky on. If things work, you've found the culprit. Don't bother with registry hacks — this is a driver-level conflict and no registry key is fixing it.

When nothing works: turn it off and use a different control

HTTPS inspection has a dirty secret — it breaks more than it catches, and it opens you to a boatload of compliance headaches (you're decrypting employee banking traffic, PII, health data). For most small and mid-size shops, the ROI is negative. Turn it off, rely on endpoint behavior detection, DNS filtering, and proper egress rules. I've said this in every shop I've run and I'll keep saying it.

If your compliance framework demands inspection, do it at the network edge with a dedicated appliance that has proper cert distribution, not on 400 endpoints with a local root CA. That's the real fix.

Quick-reference summary

Start at the top. Work down. Don't jump to reinstalling Kaspersky — that fixes it maybe 5% of the time and costs you an hour.