The certificate error that appears after you configure a proxy can be a sign of two completely different things: either there is an inspection layer in the middle, or there is a simple configuration gap. Telling the two apart is critical for your security.
What Should Normally Happen?
In a correctly configured CONNECT tunnel, the proxy never touches the certificate. The TLS handshake is carried out directly between the client and the target server; the proxy only carries the encrypted bytes. The certificate is therefore the target site's real certificate.
A certificate error is not expected in this flow. If there is one, either there has been interception or the client's certificate store is incomplete.
Causes of Errors
The second row is a warning sign: if there is a self-signed certificate in the chain, your traffic may be being read.
How to Detect SSL Inspection
If the issuer values in the two outputs differ, the proxy is performing TLS interception and can read your traffic.
Silencing a certificate error with -k or verify=False does not fix the problem — it only makes it invisible. It means letting anyone in the middle read your traffic. Never use it in production.
The Right Solutions
Update the root certificate store
This is the most common cause. On Linux run update-ca-certificates, in Python a custom connector with certifi package.
Verify the corporate root certificate before adding it
If you are on a corporate network and that is the policy, add the root certificate you obtained from your IT department to your client's trust store. Never add a certificate you downloaded from the internet.
Check the system clock
A wrong system clock makes valid certificates appear "expired". This is common on virtual machines.
Use a channel without TLS interception
Applications that use certificate pinning will not accept interception. In that case you need mobile data or a direct connection.
Per-Application Certificate Stores
Not every application uses the system trust store. This is the explanation for the "it works in the browser but not in my script" situation:
| Environment | Certificate store | How to add |
|---|---|---|
| Linux system tools | /etc/ssl/certs | update-ca-certificates |
| Python (requests) | certifi package | REQUESTS_CA_BUNDLE variable |
| Node.js | Built-in store | NODE_EXTRA_CA_CERTS variable |
| Java | cacerts keystore | keytool -import |
| Firefox | Its own store | Settings → Certificates |
| Chrome | System store | Operating system setting |
Adding a certificate system-wide makes it trusted for every application. Do it only for certificates whose source you are sure of.
Certificate Pinning
Some mobile apps and banking clients pin the server's certificate inside the application. When they see an intercepting certificate they refuse the connection — no root certificate you add will change that behaviour.
This is the reason behind the complaint "the app does not open on the corporate Wi-Fi but works on mobile data". The only solution is to use a channel without TLS interception for that app.
Summary
In a healthy CONNECT tunnel the proxy does not touch the certificate; if you are seeing an error, either your client's root store is incomplete or there is an inspection layer in the middle. To tell the two apart, compare the issuer value in the certificate chain against a direct connection. Turning verification off is not a solution, it only makes the risk invisible. To see what your connection really leaks, anonymity test you can use our tool.