SSL certificate errors with a proxy: check time, software and configuration

How an HTTP proxy handles HTTPS

To open https://example.com through a proxy, the browser sends CONNECT example.com:443 to the proxy. The proxy opens a connection to the site and relays data in both directions without being able to read it. The SSL handshake, certificate check and encryption all happen between the browser and the website. The proxy only sees the hostname and the amount of data.

Two things follow. First, a proxy does not make traffic more or less secure than HTTPS already does; it is not a VPN and adds no encryption, as explained in proxy vs VPN. Second, if the certificate you receive is not the website's, some software is sitting in the middle and you need to find it.

Common errors at a glance

Step 1: check the system clock

Certificates have a start date and an expiry date. If your clock is far off, every certificate looks either not yet valid or expired. This is common on freshly restored virtual machines, computers with a dead CMOS battery, or when someone changes the clock by hand to match a proxy's time zone and gets the time wrong.

Fix it by enabling automatic time sync in Windows or macOS date settings. If you want the browser's time zone to match the proxy country, set it in your antidetect browser profile rather than changing the system clock; see matching time zone and language to your proxy.

Step 2: see who issued the certificate

In Chrome, click the icon left of the address bar, open the connection details and view the certificate. Look at the issuer. If it names an antivirus product, a debugging tool such as Fiddler or Charles, or your employer, that software is decrypting your HTTPS traffic.

Antivirus products with HTTPS scanning install their own root certificate so the browser trusts them. Some of them mishandle tunnels through a proxy and trigger errors. Pause web or HTTPS scanning to test, then add an exception rather than leaving it off. On a company network, talk to IT before using a private proxy on a work machine.

Step 3: SSL errors in code and command-line tools

The most common coding mistake is writing the proxy address with https://. For a standard HTTP/HTTPS proxy, the proxy address is still http://user:pass@ip:port even when the target site uses HTTPS. HTTPS in the proxy type means the proxy can relay HTTPS pages, not that you connect to the proxy over SSL.

A correct example with Python requests:

• proxies = {"http": "http://user:pass@ip:port", "https": "http://user:pass@ip:port"}
• requests.get("https://api.ipify.org", proxies=proxies, timeout=15)
• If you still see CERTIFICATE_VERIFY_FAILED, update the certifi package and check whether REQUESTS_CA_BUNDLE or SSL_CERT_FILE point to an unexpected file.
• With curl, compare results with and without -x. If it fails without the proxy too, the proxy is not the cause.

Do not switch off certificate checks

Tricks like curl -k, verify=False or clicking through the browser warning make the error disappear, but they also remove the protection that tells you you are talking to the real website. Use them for a few seconds of diagnosis at most, never in production code and never while logging into accounts. For proper integration, see Python requests with a proxy or Node.js axios.

When to suspect the proxy

A private proxy from a reputable provider has no reason to insert certificates. If you have ruled out the clock, local software and your code, yet certificates are issued by an unknown party only when going through one specific proxy, stop logging into accounts through it and report it to the provider. For VinaProxy proxies, open a ticket with the proxy IP, the website and a screenshot of the certificate details. This is also why random free proxies are a poor choice for important accounts; read more about the risks of cheap proxies.

Frequently asked questions