cURL Ignore SSL Errors: -k, --insecure, and Safer Fixes

What a cURL SSL Certificate Error Means

When cURL opens an HTTPS URL, TLS encrypts the connection and cURL verifies the server certificate against a trusted certificate authority (CA). It also checks that the certificate is valid for the requested hostname. If that identity check fails, cURL stops rather than silently sending the request to an endpoint it cannot verify.

A common message is error 60:

curl: (60) SSL certificate problem: unable to get local issuer certificate

This usually means cURL cannot build a trusted chain from the server certificate to a CA it recognizes. Causes include a missing intermediate certificate, a private or self-signed CA, an outdated CA store, the wrong hostname, or a TLS-inspecting proxy whose CA is not trusted by the client.

That is separate from basic encryption. A TLS connection can still encrypt traffic while certificate verification fails. The failure is that cURL cannot verify the peer's identity—not necessarily that no encryption exists.

Use -k or --insecure for Controlled Diagnosis

-k and --insecure tell cURL to continue without verifying the peer certificate and hostname. That makes the option useful when you need to confirm whether certificate validation—not DNS, routing, proxy authentication, or the application response—is what stops a controlled test.

curl -k https://example.test

The long form behaves the same way:

curl --insecure https://example.test

You can combine it with normal diagnostic flags. For example, request headers only while displaying connection details:

curl -k -I -v https://internal-dev-server.example

If the request works only with -k, you have isolated certificate verification as the difference. The tradeoff is precise: TLS may still encrypt the bytes, but cURL no longer proves that the certificate belongs to the intended server. Use the result to diagnose the trust problem, then configure the correct trust for production.

Fix Certificate Verification for Production

Fix the server certificate chain

When you control the server, first verify that it sends the leaf certificate plus the required intermediate certificates. A browser may recover a missing intermediate from its own cache while cURL on a server or container cannot, which explains why a URL can work in one client and fail in another.

Trust the intended CA with --cacert

For a private CA or a service-specific bundle, point cURL to the PEM file explicitly:

curl --cacert ./company-ca.pem https://service.internal.example

This keeps certificate and hostname verification enabled while adding the CA you intend to trust. It is a durable fix when the endpoint legitimately uses a private PKI.

Use the native CA store where supported

Depending on the cURL build and operating system, --ca-native tells cURL to use the platform's native certificate store:

curl --ca-native https://example.com

You can also update the container or operating-system CA package so every process receives the corrected trust store. The right choice depends on whether the CA should be trusted only for one command, one application, or the whole host.

Check hostname and system time

A certificate for another hostname should not be bypassed as if it were merely expired. Confirm that the URL matches the certificate's subject alternative names and that the client clock is correct, because validity periods are evaluated against local time.

Origin TLS and HTTPS-Proxy TLS Are Separate

When cURL connects to an HTTPS proxy and then to an HTTPS origin, there are two TLS relationships. Origin options such as --insecure and --cacert control verification of the destination server. Proxy options such as --proxy-insecure and --proxy-cacert control verification of the HTTPS proxy itself.

To diagnose only the proxy-certificate side:

curl --proxy-insecure \
  -x https://proxy.example:8443 \
  https://target.example

To trust a specific CA for the HTTPS proxy while preserving verification:

curl --proxy-cacert ./proxy-ca.pem \
  -x https://proxy.example:8443 \
  https://target.example

--proxy-insecure is not a substitute for --insecure, and --proxy-cacert is not a substitute for --cacert. Apply the option to the TLS hop that actually fails.

Using cURL with Evomi Proxies

Evomi's standard Residential HTTP endpoint can carry an HTTPS request through an HTTP proxy connection. In that common setup, cURL verifies the target website normally and there is no separate HTTPS certificate on the proxy hop:

curl -x rp.evomi.com:1000 \
  -U "customer-USER:PASS" \
  https://ip.evomi.com/s

If the origin certificate fails, diagnose or fix the origin trust with -k, --cacert, or the native CA store. If you deliberately use a TLS connection to an HTTPS proxy, use the proxy-specific flags for that hop. See our complete cURL proxy guide for authentication and request setup, or the PycURL proxy guide for Python workflows.

A Practical Diagnostic Sequence

1. Run the request normally and capture the exact cURL error.
2. Repeat once with -v to identify whether the failure occurs at DNS, TCP connection, proxy authentication, TLS, or HTTP response.
3. For a controlled endpoint, test with -k. If that changes the result, certificate verification is the differentiator.
4. Inspect the certificate hostname, validity period, issuer, and chain.
5. Fix the server chain or configure the intended CA with --cacert, --ca-native, or the relevant system store.
6. If the failing TLS hop is an HTTPS proxy, use --proxy-cacert or temporarily diagnose with --proxy-insecure.
7. Remove insecure diagnostic flags from the production command after trust is configured.

Wrapping Up

-k and --insecure are useful because they quickly show whether certificate verification is blocking a controlled test. They work by skipping peer and hostname verification, not necessarily by removing TLS encryption. For production, fix the certificate chain or configure the correct CA. When an HTTPS proxy is involved, troubleshoot its certificate separately with --proxy-insecure and --proxy-cacert.

The cURL project documents these behaviors in its official SSL certificate verification guide.