Skip to content

Proxy Certificate

Some Evomi features need to read the responses passing through the proxy rather than tunnelling them untouched. Response Caching is one of them: to store a stylesheet or an image, the proxy has to see it.

For HTTPS that means the connection is terminated at our proxy and re-signed on the fly with the Evomi Proxy CA. Your client has no reason to trust that certificate, so it aborts the handshake until you tell it to.

There are two ways to handle it and neither is more correct than the other:

Skip verification Trust the Evomi CA
Setup One flag or variable per client Download and install once
TLS verification Off for that client Stays on
Suits Scraping and automation against public pages Shared machines, or processes that also talk to your own services

Most people scraping public pages take the first option, because it is a single flag and there is nothing to install or keep track of. Pick the second if the same process handles anything you actually need certificate guarantees for.

Only needed for cache-enabled requests

Standard proxying tunnels HTTPS end to end and needs neither option. You only need this page if your proxy password uses _cache-.

Option 1: Skip Certificate Verification Permalink to Option 1: Skip Certificate Verification

Every HTTP client has a switch for this. Nothing to download:

curl -k -x http://rp.evomi.com:1000 -U testuser:testpassword_cache-all https://ip.evomi.com/s

-k and --insecure are the same flag.

This is fine for scraping public pages, where you are reading content rather than trusting it. The trade-off is that the client then accepts any certificate from any host, so it can no longer detect interception by anyone else on the path. Keep it scoped to the code doing proxy work and don’t apply it to code that also handles logins, payments or your own APIs — in Node and Go the per-client form above does exactly that, leaving the rest of the process verifying normally.

Option 2: Trust the Evomi CA Permalink to Option 2: Trust the Evomi CA

This keeps certificate verification switched on, so your client still rejects anything that is not signed by us or by a public CA.

Download Permalink to Download

curl -O https://cdn.evomi.com/downloads/evomi.crt
Field Value
Common Name Evomi Proxy CA
Format PEM
Valid until 6 January 2036

Verify the download before installing it:

openssl x509 -in evomi.crt -noout -fingerprint -sha256

The SHA-256 fingerprint must be:

E3:75:7D:4F:CB:87:9F:6A:52:24:92:0F:20:93:8F:D4:89:D1:92:01:87:C7:EA:E4:3C:40:68:C2:4D:CC:1F:42

Per-Tool Setup Permalink to Per-Tool Setup

Most clients accept an extra CA through an environment variable or a single argument, which applies to that process only:

# Per command
curl --cacert evomi.crt -x http://rp.evomi.com:1000 -U testuser:testpassword_cache-all https://ip.evomi.com/s

# Or for every command in the shell session
export CURL_CA_BUNDLE=/path/to/evomi.crt

Chromium ignores all of the above and reads the operating system trust store, so headless browsers need the system-wide install below — or the --ignore-certificate-errors flag from Option 1, which is why most browser automation ends up using that instead.

System-Wide Installation Permalink to System-Wide Installation

Scope the trust as narrowly as you can

Adding any root CA to a machine’s system trust store lets certificates signed by it be accepted for every host that machine talks to, not only traffic you send through Evomi.

Prefer the per-tool options above, which apply to a single process, and prefer a dedicated machine or container for proxy work over your daily-driver workstation. Install system-wide only when a tool gives you no other option.

sudo security add-trusted-cert -d -r trustRoot \
-k /Library/Keychains/System.keychain evomi.crt

To remove it later: sudo security delete-certificate -c "Evomi Proxy CA" /Library/Keychains/System.keychain

Certificate renewal

The CA is valid until January 2036, so no rotation is required in normal use. If we ever need to replace it early we will announce it in advance — the download URL stays the same, so re-running the steps above is all that is needed.

Verifying Setup Permalink to Verifying Setup

Send one request through a cache-enabled password. A response means the certificate is being accepted:

# If you skipped verification
curl -k -x http://rp.evomi.com:1000 -U testuser:testpassword_cache-all https://ip.evomi.com/s

# If you trusted the CA
curl --cacert evomi.crt -x http://rp.evomi.com:1000 -U testuser:testpassword_cache-all https://ip.evomi.com/s

Troubleshooting Permalink to Troubleshooting

Error Fix
certificate signed by unknown authority Neither option is active for this client — apply one of them
unable to get local issuer certificate (curl) Add -k, or pass --cacert evomi.crt
SSLCertVerificationError (Python) Set verify=False or verify="evomi.crt" on the request
ERR_CERT_AUTHORITY_INVALID (Chromium) Launch with --ignore-certificate-errors, or install the CA system-wide
Handshake fails with no HTTP error at all Expected when the certificate is rejected — the connection closes during the handshake, before any response
Works in curl but not in your app The app has its own trust store; check for a bundled CA file such as certifi
Trusted the CA but a tool still refuses it That tool likely reads the system store rather than the environment variable — install system-wide or skip verification for it