API Debugging New Tricks
Origin Certificate Mismatch: Why DevPeek Still Captures the Site
SSL proxying is on. The page loads, and its request headers, body, and response are all readable.
Yet DevPeek marks the request and shows this warning in request details:
Origin certificate does not match the hostname
Open the origin certificate and you might find that the requested Host is:
admin.shop-example.com
while its SAN (Subject Alternative Name) contains only:
*.cdn-host.cn
cdn-host.cn
This is not a false positive, and it does not mean that the DevPeek CA was installed incorrectly. The origin certificate cannot prove that the server represents the Host being requested.
DevPeek does not silently ignore this condition or block you from examining it. Instead, it:
- Completes the TLS connection to the origin.
- Preserves HTTPS decryption and capture.
- Checks and records the origin certificate problem.
- Flags the risk in the capture list and request details.
- Lets you inspect the saved origin certificate.
In debugging, certificate failures are evidence too.
Understanding ERR_TLS_CERT_ALTNAME_INVALID
An HTTPS certificate lists the domain names it represents in SAN.
For example:
Requested Host: admin.shop-example.com
Certificate SAN: *.cdn-host.cn, cdn-host.cn
Because admin.shop-example.com is outside the certificate’s names, standard TLS hostname verification reports:
ERR_TLS_CERT_ALTNAME_INVALID
It does not necessarily mean that the certificate file is corrupt. It means:
I connected to A, but the server presented a certificate for B, so I cannot verify its identity.
Common causes include:
- The wrong certificate is bound at a CDN or WAF
- SNI is misconfigured at a reverse proxy
- DNS points to the wrong service
- A test environment reuses another environment’s certificate
- a Forward Rule or internal network sends traffic to a different server
- The origin certificate simply does not cover the requested domain
A trailing dot such as admin.shop-example.com. is also worth checking. It is a valid FQDN form, but a few proxies, gateways, and CDNs handle it inconsistently.
This is not an untrusted DevPeek CA
SSL proxying creates two TLS sessions:
Browser / App
│
│ TLS: DevPeek dynamic certificate
▼
DevPeek
│
│ TLS: origin certificate
▼
Origin
The first session runs from the client to DevPeek. The client must trust the DevPeek CA so it can accept dynamically generated debugging certificates.
The second runs from DevPeek to the origin. This is where DevPeek receives the real origin certificate discussed in this article.
If the first certificate is not trusted, a browser commonly reports:
NET::ERR_CERT_AUTHORITY_INVALID
If the second certificate does not match the requested Host, DevPeek reports:
Origin certificate does not match the hostname
Reinstalling the DevPeek CA does not usually fix an origin mismatch. The two errors belong to different TLS sessions.
If you have not captured your first HTTPS request yet, start with Quick Start and Proxy & SSL certificates.
Why does DevPeek keep the request running?
Browsers, Node.js, and ordinary HTTP clients in strict mode normally treat a certificate verification failure as a hard error and terminate TLS.
That is a sensible default for regular browsing because the client cannot authenticate the server.
A debugging proxy has another concern. If DevPeek terminated the request immediately, you would also lose:
- The actual page or API response
- Request and response plaintext
- The certificate returned by the origin
- CDN, SNI, DNS, and forwarding results
- Context needed to diagnose a test-environment certificate issue
DevPeek therefore does not use origin verification failure as a hard stop. It completes the connection, independently checks the certificate, and associates any problem with the recorded request.
More precisely, DevPeek does not “skip certificate checks.” It:
performs the checks without letting a failed check erase the debugging session, and clearly exposes the resulting risk.
A page loading successfully means that TLS and HTTP completed. It does not mean that the origin certificate is valid.
What appears in request details?
Depending on the certificate, DevPeek can report:
- Origin certificate does not match the hostname
- Origin certificate has expired
- Origin certificate is not trusted
- Origin certificate check failed
Select View origin certificate to inspect:
- Subject
- Issuer
- SAN
- Validity
- Serial number
- SHA-1 and SHA-256 fingerprints
- PEM
For a hostname mismatch, compare the request Host with SAN first.
For example:
Requested Host: api.test.example.com
Certificate SAN: *.example.com
Those names do not match either. *.example.com covers one subdomain level such as api.example.com, not api.test.example.com.
The capture-list marker helps you find affected requests before opening request details for the full certificate.
What should you do with the warning?
A test environment has the wrong certificate
DevPeek lets integration work continue, but the warning still identifies a configuration problem.
Check:
- Whether DNS resolves to the intended address
- Whether the CDN or WAF has the correct certificate
- Whether SNI is forwarded correctly
- Whether SAN covers the current Host
- Whether a reverse proxy returned its default-site certificate
- Whether a Forward Rule sent the request into another environment
“Continue debugging” does not make the origin trustworthy.
You are investigating a certificate or gateway issue
This is exactly why preserving the request helps.
Compare:
- Request Host
- Actual remote address
- Origin Subject and SAN
- Issuer and validity period
- Applied Forward Rules
- Certificates returned for the same Host on different networks
The certificate failure becomes part of the request evidence instead of making the evidence disappear.
Production or sensitive data is involved
Do not interpret “the page loads” as “the connection is safe.”
A verification warning means DevPeek cannot authenticate the peer. It may be a test configuration mistake, or it may indicate an unexpected DNS, proxy-chain, or network endpoint.
Until the cause is understood, avoid sending passwords, tokens, payment details, or other sensitive data.
Should you add the Host to Exclude?
You do not need to exclude an origin-mismatch Host just to keep the site open. DevPeek keeps plaintext available and shows the warning so you can investigate it.
With a CONNECT tunnel, certificate verification returns to the browser or app. If the origin certificate truly does not match, a strict client will probably block the connection itself.
Exclude is a better fit when:
- HTTPS interception breaks the request, but tunneling restores it.
- The client pins certificates and rejects debugging certificates.
- You do not need plaintext for that traffic.
- You want the client to perform end-to-end certificate verification.
For that separate case, see HTTPS Capture Breaks a Few Sites? Add Them to Skip SSL Proxy.
Do not confuse TLS with application encryption
After HTTPS has been decrypted, JSON may still look like:
{
"data": "7a3f..."
}
That is application-layer AES, RSA, Base64, or custom encoding—not a certificate problem.
Use Param Transform for that layer. TLS protects the transport; Param Transform handles business payloads.
Three points to remember
First, a certificate that does not match Host means DevPeek cannot authenticate the origin. The warning is real.
Second, DevPeek neither hides the problem nor stops debugging by default. The site and HTTPS plaintext remain available, and request details retain the certificate evidence.
Third, Exclude controls which Hosts are not decrypted. It is not the mandatory fix for a certificate warning. The real fix belongs in the origin certificate, DNS, SNI, CDN, or forwarding configuration.
Next
This is currently the last article in the API debugging series. Continue with the blog index or learn more about capture and request details.
If you are investigating a test certificate, CDN, or SNI issue, try DevPeek to preserve the request and origin certificate evidence. Share unusual cases on GitHub Discussions.