cURL Ignore SSL Certificate Errors: Commands, Risks, and Proxy Fixes

Quick Answer

Use -k or its long form, --insecure, to make curl continue without verifying the destination server's TLS certificate:

This bypasses two checks curl normally performs: whether the certificate is signed by a trusted certificate authority (CA), and whether the certificate name matches the hostname in the URL. For HTTPS, -k skips certificate verification; it does not turn off TLS encryption. Instead, it removes proof that the encrypted connection reached the intended server. An active intermediary could impersonate that server.

Use -k only for a short, controlled diagnostic where no sensitive data is sent. The preferred fix is to repair the certificate, hostname, chain, or local trust configuration. For a private CA, point curl to the CA certificate with --cacert:

If the certificate error belongs to an HTTPS proxy, use --proxy-cacert instead. curl verifies an HTTPS proxy separately from the destination server.

Key Takeaways

• curl -k bypasses certificate verification; it does not reliably identify the peer. The connection can still be encrypted while remaining vulnerable to impersonation.
• --cacert is usually the correct fix for a private or internal destination CA. It changes which CA certificates curl trusts for that destination.
• --cert is not a replacement for --cacert. It presents a client certificate when the server requires mutual TLS.
• HTTPS proxy trust is separate from destination trust. Use --proxy-cacert for the proxy and --cacert for the destination.
• --insecure does not also disable HTTPS proxy verification. The separate proxy bypass is --proxy-insecure.
• A successful transfer under -k is diagnostic evidence, not a repair. It suggests verification is involved, but it does not identify whether the root cause is trust, hostname, expiry, chain delivery, or clock configuration.
• Verbose output can expose secrets. Redact authorization fields, cookies, proxy credentials, hostnames, and internal paths before sharing logs.

What Does curl -k Actually Do?

curl -k tells curl to proceed without its normal peer-verification step. For a TLS destination, curl normally checks that the certificate matches the requested hostname and chains to a CA certificate in a trusted store. The official curl manual documents -k as the short form of --insecure and warns that it makes the transfer insecure.

Three separate ideas are easy to confuse:

The practical risk is encryption without authenticated identity. An attacker who can intercept the route may establish one encrypted connection with curl and another with the intended server. Both legs can be encrypted even though curl is communicating with the attacker's endpoint.

The bypass also has consequences beyond the immediate response. The curl manual notes that an insecure connection can supply HSTS or Alt-Svc information that curl may store and use later. That is another reason not to put insecure in a global curl configuration.

Although users commonly search for “ignore SSL,” current HTTPS connections normally use TLS. curl retains the historical SSL wording in some options and errors, so this guide uses both terms where they help match the command or message.

How Do You Ignore an SSL Certificate Error in cURL?

Add -k or --insecure to the specific command you are diagnosing. Both forms have the same verification behavior for the destination connection.

Make a temporary GET request

Show connection diagnostics

Verbose mode can help distinguish name resolution, connection, TLS, and HTTP failures. It writes diagnostic details to standard error and can expose request fields, cookies, proxy details, certificate names, and internal network information. Use it briefly and sanitize the output before retaining or sharing it.

Send a request body

Do not send API keys, session cookies, personal data, production payloads, or other sensitive material while verification is disabled. A TLS connection whose peer was not verified is not an appropriate channel for secrets.

Use the correct ASCII hyphens

The option must contain two ordinary ASCII hyphens:

Commands copied from formatted documents sometimes contain an en dash or em dash, such as –insecure or —insecure. Those are different characters, and curl does not interpret them as the long option.

Why Does cURL Report a Certificate Error?

Certificate failures normally indicate a specific problem with the server identity, certificate chain, local trust source, system clock, or proxy layer. Read the complete curl message before choosing a fix.

These commonly encountered curl exit codes narrow the investigation:

The current curl exit-code reference gives the stable definitions. The text printed beside the code provides the context needed to diagnose a particular transfer.

What Is the Safer Fix Than curl -k?

The safer fix is to preserve verification and correct the trust or identity problem. Work through the following checks in order.

1. Confirm the hostname

Request the hostname the certificate was issued for. Connecting to an IP address while the certificate contains only a DNS name produces a legitimate mismatch. Do not hide that mismatch with -k.

If you need to test a hostname against a specific address, curl's --resolve option preserves the URL hostname for Server Name Indication (SNI) and certificate verification while choosing the address locally:

This example uses a documentation-only IP address. Replace it with an approved test address.

2. Fix the certificate chain

The server should present its leaf certificate and the required intermediate certificates. A server can appear valid in one client and fail in another when the first client retrieves or caches a missing intermediate independently. Repair the server configuration instead of distributing -k commands.

3. Trust the approved private CA

For an internal service issued by a private CA, point curl to the approved CA certificate or CA bundle:

The file supplied to --cacert can contain one or more CA certificates in PEM format. According to curl's TLS certificate documentation, this option changes the CA material used to verify the remote peer. It does not present a client identity.

For a managed workstation or server fleet, installing the private CA through the operating system or runtime's approved trust-management process can be more maintainable than passing a file on every invocation. curl's actual trust source depends on its TLS backend and build, so record curl --version and follow the platform's supported CA procedure.

4. Check the clock and validity window

An incorrect clock can make a valid certificate appear expired or not yet valid. Confirm the machine's time, timezone, and time synchronization before changing TLS options.

5. Determine whether mutual TLS is required

Some servers require the client to present a certificate. That is a different problem from trusting the server:

In this command:

• --cacert supplies CA material for verifying the server.
• --cert supplies the client certificate presented to the server.
• --key supplies the private key associated with that client certificate.

The official curl client-certificate guide explains this mutual-TLS role. A client certificate does not make an untrusted server certificate valid.

How Does Certificate Verification Work Through a Proxy?

Certificate verification depends on whether curl reaches an HTTP proxy or an HTTPS proxy. The proxy scheme and destination scheme describe different connections.

HTTP proxy with an HTTPS destination

For a normal HTTPS destination through an HTTP proxy, curl asks the proxy to create a CONNECT tunnel and then performs the destination TLS handshake through that tunnel. The destination certificate is still verified with curl's default CA store or --cacert.

--proxy-cacert does not apply to the client-to-proxy hop in this example because the proxy URL begins with http://; that hop is not TLS. The destination is still HTTPS.

HTTPS proxy with an HTTPS destination

With an HTTPS proxy and an HTTPS destination, curl has two independent trust decisions:

Use both CA options when the proxy and destination use different private trust chains:

The curl manual for --proxy-cacert explicitly allows the HTTPS proxy to use different trust material from the remote server.

Which insecure option affects which connection?

--insecure skips destination verification. It does not automatically skip HTTPS proxy verification. Conversely, --proxy-insecure skips HTTPS proxy verification but does not automatically skip destination verification.

This command bypasses only the HTTPS proxy check:

This command bypasses only the destination check:

Both are diagnostic commands, not production configurations. Supply the correct CA files after identifying the failing layer.

If you need the complete proxy syntax, authentication options, SOCKS behavior, environment variables, and route-verification workflow, read How to Use cURL With a Proxy.

How Do You Diagnose the Failing TLS Layer?

Start with the exact error and route, then change one variable at a time. Do not add both insecure flags immediately; that removes the evidence needed to identify the failing peer.

1. Run curl --version and record the curl version, TLS backend, and supported protocols.
2. Confirm the destination URL and its hostname.
3. Confirm the proxy URL scheme. http://proxy... and https://proxy... create different trust boundaries.
4. Run the request with --verbose in a protected diagnostic environment.
5. Identify whether the failure occurs before the proxy connection, during HTTPS proxy verification, during CONNECT, or during destination TLS verification.
6. Add the corresponding CA file and retest without a bypass.
7. Check the final HTTP status and required content; a completed TLS handshake does not prove the application response is correct.

For an HTTPS proxy, start with both explicit CA files:

An HTTP 407 Proxy Authentication Required response is a proxy-credential or authentication-method problem, not proof of a certificate failure. Fix --proxy-user or the provider's documented authentication setup instead of adding -k.

Proxidize supplies standard proxy endpoints and credentials; curl remains responsible for its destination and proxy TLS settings. Generate credentials through the dashboard, load them through the team's secrets workflow, and never paste production values into an article, repository, screenshot, shell history, or shared verbose log.

How Do You Inspect Response Headers During TLS Troubleshooting?

Use a normal request with --dump-header when you need the response fields without changing the method to HEAD:

On Windows, use NUL instead of /dev/null. The -D - shorthand is equivalent to --dump-header -.

curl -I is different: it asks the server for a HEAD response, which may not match the headers or behavior of a GET request. Use it only when HEAD is the method you intend to test.

Headers help distinguish redirects, proxy authentication responses, HTTP errors, caching behavior, and the final destination response. They do not repair a TLS failure because HTTP response fields normally arrive only after the relevant TLS handshake succeeds. The detailed guide to showing response headers with cURL compares -i, -I, -D, and -v without conflating their behavior.

How Should Scripts Handle Development and Production?

Scripts should keep verification enabled by default and require an explicit, narrowly scoped opt-in before a development diagnostic uses --insecure. A corrected Bash condition needs spaces around [ and ], a valid curl command, quoted variables, and a trustworthy default path.

This pattern fixes the syntax of the older example without requiring CA_FILE for every verified request. When CA_FILE is present, the script supplies that bundle with --cacert; otherwise, curl uses its normal trust configuration. The preferred development setup is still to trust a development CA and remove the bypass branch. An environment name alone does not make a network path or response trustworthy.

The -q option appears first after curl because that position tells curl not to read its default configuration file. This prevents an existing .curlrc from silently adding insecure or changing another option. The official -q documentation requires it to be the first command-line parameter for that behavior.

Do not add insecure to .curlrc, a shared configuration, or a reusable alias. That silently changes unrelated transfers and makes later debugging harder. Keep any exceptional bypass visible on the one command that needs it.

When Is curl -k Reasonable?

curl -k is reasonable only as a temporary diagnostic when you control the test, understand the route, and send no sensitive material. It answers one narrow question: “Does this transfer proceed when peer verification is removed?” It does not reveal whether the underlying cause is an untrusted CA, missing intermediate, expiry, hostname mismatch, interception, or another verification problem.

Do not use it for production or scheduled requests, sensitive payloads, trusted downloads, or any test intended to verify endpoint identity. “Internal,” “staging,” and “localhost” are deployment labels, not security guarantees; private services should still use an approved certificate and trust path.

Common cURL Certificate Mistakes

Treating --cert and --cacert as interchangeable

--cacert supplies trusted CA certificates for peer verification. --cert supplies a client certificate to identify the client. They solve opposite sides of the TLS relationship.

Adding --insecure to an HTTPS proxy error

If the failing certificate belongs to the HTTPS proxy, use --proxy-cacert to trust its CA. --insecure controls the destination and can leave the original proxy failure unchanged.

Adding --proxy-insecure to a destination error

The proxy bypass cannot fix a destination certificate. Use --cacert, repair the destination chain, or correct the requested hostname.

Assuming error 35 means “bad certificate”

Exit code 35 is a broad TLS handshake failure. Protocol compatibility, ciphers, client-certificate requirements, connection interception, and other causes can produce it. Use the accompanying message and controlled verbose output.

Hiding a hostname mismatch

A mismatch may mean the wrong endpoint, IP address, virtual host, or certificate was selected. Disabling verification can conceal a routing mistake with security consequences.

A Practical Decision Table

Use the failure location and requirement—not habit—to choose the option.

Final Recommendation

Use curl -k only long enough to isolate certificate verification as part of the failure. Then restore verification and apply the matching trust or client-identity option from the decision table above. When a proxy is involved, first determine whether its URL uses HTTP or HTTPS, then validate the response—not merely the TLS handshake—with the intended method, status, headers, and required content.

For the next step, use the complete cURL proxy guide to configure the route and authentication, then use the cURL response-header guide to inspect what the destination returned.