System proxy is on. The CA is trusted. SSL proxying is on too.

Most HTTPS requests show up in the capture list—headers, bodies, responses, all readable.

A few sites just will not load.

The log may look like this:

PROXY_TO_SERVER_REQUEST_ERROR: Error [ERR_TLS_CERT_ALTNAME_INVALID]:
Hostname/IP does not match certificate's altnames:
Host: admin.shop-example.com. is not in the cert's altnames:
DNS:*.cdn-host.cn, DNS:cdn-host.cn

The browser fails the page. The capture row dies.

Turn off system proxy, or turn off SSL proxying, and the site works again.

Usually this is not a missing DevPeek root CA.

What actually happened: when DevPeek connected to the origin, the certificate the server returned did not match the current Host.

The simple fix is not to disable HTTPS capture globally. Exclude that host in SSL proxy settings and let it use an HTTPS tunnel.

This post unpacks the error, and why you need both Include and Exclude lists.

Who this is for

This article is for you if:

System proxy and the DevPeek CA are already set up
Most HTTPS captures fine
Only a few sites break when SSL proxying is on
The log shows ERR_TLS_CERT_ALTNAME_INVALID
The Host in the error and the cert SAN look like different domains
You want to spare those hosts, not turn off SSL proxying for everything

If you have not captured a first HTTPS request yet, start here:

Read the error first

For example:

Host: admin.shop-example.com.
is not in the cert's altnames:
DNS:*.cdn-host.cn
DNS:cdn-host.cn

Two parts matter.

The Host you meant to open:

admin.shop-example.com

The certificate the origin actually presented:

*.cdn-host.cn
cdn-host.cn

admin.shop-example.com is not in the cert’s SAN (Subject Alternative Name).

So when Node verifies the origin TLS cert, it sees: I am connecting to admin.shop-example.com, but you handed me *.cdn-host.cn.

The connection fails. That is ERR_TLS_CERT_ALTNAME_INVALID.

This is not “DevPeek CA not installed”

Easy to mix up.

If the browser or device does not trust the DevPeek CA, you usually get something like:

NET::ERR_CERT_AUTHORITY_INVALID

Meaning: I do not trust who issued this certificate.

This article is the other error: ERR_TLS_CERT_ALTNAME_INVALID.

It asks: do the names on the certificate match the Host we are connecting to?

If Host is admin.shop-example.com and the cert is DNS:*.cdn-host.cn, reinstalling the DevPeek CA will not help.

Why it only breaks with SSL proxying on

You have to see what SSL proxying actually does.

A plain HTTPS proxy looks like this:

Browser
   │
   │ CONNECT
   ▼
DevPeek
   │
   │ TCP tunnel
   ▼
Origin

The browser still completes TLS with the origin. DevPeek only splices the TCP. The browser verifies the origin certificate itself.

With SSL proxying on, there are two TLS sessions:

Browser
   │
   │ TLS
   ▼
DevPeek
   │
   │ TLS
   ▼
Origin

First hop: browser ↔ DevPeek. DevPeek mints a cert for that name, signed by the DevPeek CA.

Second hop: DevPeek ↔ origin. DevPeek is the TLS client and verifies the real site certificate.

The error in this article is the second hop.

Why CDNs and WAFs hit this so often

One IP often serves many names.

admin.shop-example.com, api.shop-example.com, cdn-host.cn, static.cdn-host.cn may all sit behind the same CDN, WAF, or reverse proxy.

Normally the server picks a cert from the SNI in the TLS handshake.

If the proxy chain, the client, CDN config, or Host / SNI handling is off, you can request Host admin.shop-example.com and get back *.cdn-host.cn.

Browser direct may still work. Through an SSL MITM proxy, hostname verification fails.

If you see Host written admin.shop-example.com. with a trailing dot, note it. That is a valid FQDN. It is not itself a bug, but some clients, proxies, or CDNs handle that form poorly.

Why not “fail, then automatically tunnel”?

A natural idea: if the first SSL-proxy attempt fails, fall back to a plain CONNECT tunnel.

Too late.

SSL proxying already built TLS between the browser and DevPeek. The browser’s ClientHello went to DevPeek. DevPeek has already started talking to the origin as a MITM.

If origin cert check fails, that CONNECT cannot simply rewind into a transparent tunnel. Tunnel vs intercept has to be decided before the connection is established.

That is why Fiddler, Charles, and similar tools let you configure which hosts get SSL intercept and which are skipped, instead of auto-downgrading after a bad cert. Charles calls the two lists Include / Exclude.

How DevPeek handles it

DevPeek splits SSL proxy scope into two lists:

SSL proxy these hosts — Include. Default * means every matching HTTPS host may be intercepted.

Skip SSL proxy (tunnel) — Exclude. Those hosts are not MITM’d; they get an HTTPS tunnel.

In one line:

SSL proxy
= SSL on
  && Include match
  && not Exclude match

If both match, Exclude wins.

This is not param encrypt/decrypt in Param Transform.

Exclude the host in SSL proxy settings

Open SSL proxy configuration.

Top: SSL proxy these hosts. Bottom: Skip SSL proxy (tunnel).

If Include is * and admin.shop-example.com fails with ERR_TLS_CERT_ALTNAME_INVALID, add to Exclude:

admin.shop-example.com

If a whole subtree has the same issue:

*.shop-example.com

Save applies to new connections. An existing CONNECT will not flip to a tunnel. Refresh the page; drop old connections if you need to.

Done when: the site loads, that HTTPS row is a tunnel, and other Include hosts still get SSL proxying.

How to write Include / Exclude

Patterns: *, *.example.com, *api*, api.example.com.

Typical cases:

Include	Exclude	Host	Result
`*`	`*.shop-example.com`	`admin.shop-example.com`	Tunnel
`*`	`*.shop-example.com`	`api.other.com`	SSL proxy
`*.example.com`	`api.example.com`	`api.example.com`	Tunnel
`api.example.com`	`*.example.com`	`api.example.com`	Tunnel

One rule: Exclude wins. A host on both lists still tunnels.

Putting * on Exclude tunnels all HTTPS. DevPeek asks for confirmation so you do not wipe out SSL capture by accident.

Easy to miss: you cannot exclude by URL path

You might want https://api.example.com/login or api.example.com/v1/*.

SSL proxy vs tunnel is decided at HTTPS CONNECT. The proxy has not seen /v1/login yet.

Exclude matches connection-level Host, not HTTP path. api.example.com is a rule. api.example.com/v1/login is not.

Do not mix three different failures

When HTTPS capture looks wrong, start here:

What you see	More likely
Untrusted issuer / `NET::ERR_CERT_AUTHORITY_INVALID`	DevPeek CA not installed or not trusted
Host is A, origin SAN is a different domain; direct works, SSL proxying fails	Origin cert / SNI / proxy-chain mismatch
Cert error remains with SSL proxying off	The origin cert is already wrong
HTTPS is already HTTP plaintext, JSON still ciphertext	Param Transform

Watch the last one: TLS is already open, but the JSON is still { "data": "7a3f..." }. That is application-layer encryption, not SSL proxying. Use Param Transform.

When should you skip SSL proxying?

Three common cases.

1. Origin cert and Host do not play well

ERR_TLS_CERT_ALTNAME_INVALID in this article. Put the host on Exclude; it becomes a normal HTTPS tunnel.

2. You never needed plaintext for that site

*.google-analytics.com, *.example-cdn.com—background noise. Exclude them to keep the capture list quieter.

3. The client pins certificates (or you simply must not MITM)

If an app should not be intercepted, or you do not need its HTTPS plaintext, tunnel that Host.

Skip SSL proxying does not “fix” pinning. It means you choose not to MITM that traffic.

Do not turn off SSL proxying for a handful of sites

If only admin.shop-example.com is broken, do not disable SSL proxying globally. Do not turn off origin certificate checks just to paper over one host. That means the proxy stops seriously authenticating the real server.

Keep both modes in one config:

Most hosts
    ↓
SSL proxy
    ↓
Plaintext capture

A few special hosts
    ↓
Skip SSL proxy
    ↓
HTTPS tunnel

One sentence to keep

If: direct access works + SSL proxying makes that site fail + Host does not match the origin SAN → check Skip SSL proxy (tunnel) first. Do not reinstall the CA. Do not kill all SSL capture.

Include
   │
   ├── no match → no SSL proxy
   │
   └── match
        │
        ├── Exclude match → tunnel
        │
        └── Exclude miss → SSL proxy

Most HTTPS stays readable. A few odd hosts do not take the whole proxy down.

Next steps

Same proxy chain for API work:

Param Transform: AES, Base64, and other field codecs
Forward rules: backend moved, frontend has not shipped
Mock: fake responses without changing the server
Capture and request details: HTTP / HTTPS / WebSocket

If you only need this article’s fix: find the Host → exclude it in SSL proxy settings → refresh.

TBD: Breakpoints, resend, and collaboration on the proxy chain—more ways proxy tools get in the way during joint debug.

If SSL proxying has taken down a few sites for you too, try DevPeek and add an Exclude rule, or talk certs, CDNs, and proxy quirks on GitHub Discussions.

HTTPS Capture Breaks a Few Sites? Add Them to Skip SSL Proxy