How to Ignore Certificate Errors With curl: Risks and Alternatives

curl should ignore certificate errors only for short testing, never as a normal production fix. The command is simple: curl -k https://example.test or curl --insecure https://example.test. That flag tells curl to continue even when certificate checks fail, which the curl manual describes as allowing “insecure” SSL connections [source: curl]. The safer path is to fix the certificate chain, trust the correct certificate authority, or pass a known CA file to curl.

TLDR: Use -k or --insecure only when testing a known endpoint, such as a local API at https://localhost:8443 with a self signed certificate. A support team that runs 200 health checks per day might save 30 seconds per failed check with -k, but it also trains scripts to accept fake certificates. For staging, the better fix is usually --cacert company-ca.pem. For production, certificate errors should be treated as a broken security control, not a minor warning.

Certificate errors happen when curl cannot prove that the server is the real server. The certificate may be expired. The hostname may not match. The issuing certificate authority may be missing from the local trust store. A proxy may be inspecting HTTPS traffic. Or the server may be misconfigured and sending the wrong intermediate certificate.

Honestly, it feels annoying when a simple API test takes 20 seconds longer because curl blocks on a certificate problem. Still, that stop is useful. It is curl saying, “This connection cannot be trusted yet.”

How curl Certificate Verification Works

When curl connects to an HTTPS URL, it checks the server certificate before it trusts the response. It checks several things:

• Hostname match: The certificate must match the requested domain.
• Expiration date: The certificate must be valid at the current time.
• Trust chain: The certificate must chain back to a trusted root CA.
• Signature validity: The certificate must not be altered or fake.
• Revocation status: In some setups, curl or the TLS library may check if the certificate was revoked.

If one of these checks fails, curl usually stops and displays an error. Common examples include SSL certificate problem: self-signed certificate, certificate has expired, and unable to get local issuer certificate.

How to Ignore Certificate Errors With curl

The direct method is the -k option:

curl -k https://internal.example.test

The long form is clearer in scripts:

curl --insecure https://internal.example.test

It can also be used with other curl options:

curl --insecure -X POST https://api.example.test/login \
  -H "Content-Type: application/json" \
  -d '{"user":"demo","password":"demo"}'

The option works with downloads too:

curl -k -O https://files.example.test/build.zip

In all cases, curl still uses encryption, but it does not verify who is on the other end. That distinction matters. The traffic may be encrypted to an attacker if a machine in the middle presents a fake certificate.

When It May Be Acceptable

Ignoring certificate errors can be reasonable in narrow cases. The key word is temporary.

• Local development: A developer tests https://localhost with a self signed certificate.
• Short lived staging systems: A build server creates throwaway test endpoints.
• Initial debugging: An engineer checks whether a failure is caused by TLS or by the application.
• Isolated lab networks: A test machine has no route to public networks.

Even then, teams should avoid saving --insecure into shared scripts. It starts as a quick fix. Six months later, nobody remembers why it is there, and it quietly hides real certificate failures.

Risks of Using --insecure

The largest risk is a man in the middle attack. If curl stops checking identity, a hostile proxy, infected router, or compromised Wi Fi network can return a fake certificate. curl accepts it. The script keeps running. Credentials, tokens, cookies, and response data may be exposed.

The second risk is false confidence. A deployment pipeline may report success even while the real certificate chain is broken. Customers then see browser warnings, mobile apps fail, or partner integrations reject connections.

The third risk is habit. It drives many engineers crazy that some internal systems keep broken TLS for years because -k makes the pain disappear. The command saves seconds today and creates messy outages later.

Better Alternative: Use a CA Certificate File

If the server uses a private certificate authority, curl can be told to trust that CA. This keeps verification enabled while fixing the trust problem.

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

This is far safer than --insecure. curl still checks the hostname, expiration, and chain. It only adds the private CA as a trusted issuer for that command.

For repeated use, teams can place the CA certificate in the operating system trust store. That way, curl, browsers, package managers, and other clients can validate the same internal services without special flags.

Better Alternative: Fix the Server Certificate

If the server is public, the best fix is almost always on the server side. The certificate should be renewed, installed with the correct intermediate chain, and issued for the right hostname.

For example, if curl reports this:

curl: (60) SSL: no alternative certificate subject name matches target host name

The certificate probably does not include the requested domain in its Subject Alternative Name field. Running curl -k hides the error, but it does not fix the service. The correct fix is to issue a certificate that includes the actual hostname.

Better Alternative: Test With a Known Host Mapping

Sometimes a team needs to test a new server before DNS changes. Instead of disabling verification, curl can map a hostname to a specific IP address while still validating the certificate against the hostname.

curl --resolve www.example.com:443:203.0.113.10 https://www.example.com/

This is useful during migrations. It tests the target server while preserving TLS identity checks.

Better Alternative: Use --cert-status or Verbose TLS Output

For troubleshooting, more information is better than weaker security. The -v flag shows the TLS handshake details:

curl -v https://example.com

It can reveal which certificate was sent, which CA was used, and where the failure occurred. For some systems, --cert-status can request OCSP status from the server:

curl --cert-status https://example.com

These options help identify the real problem instead of bypassing it.

Safer Rules for Teams

• Allow -k only in local or temporary test commands.
• Ban --insecure in production scripts and CI release jobs.
• Use --cacert for private CAs.
• Document every certificate exception.
• Fail builds when public certificate validation breaks.

A practical policy is simple: if the command handles secrets, production data, customer traffic, or deployment artifacts, it should not use --insecure. If the certificate is wrong, the certificate should be fixed.

FAQ

What curl option ignores certificate errors?

The option is -k or --insecure. It tells curl to skip certificate verification for that request.

Is curl -k encrypted?

Yes, the connection can still be encrypted. The problem is identity. curl no longer proves that the server is the correct server.

Should production scripts use --insecure?

No. Production scripts should use valid certificates, a trusted CA store, or --cacert with an approved CA file.

How can a self signed certificate be used safely with curl?

The safer method is to pass the certificate or its CA file with --cacert. That keeps certificate validation active.

Why does curl fail when a browser works?

The browser and curl may use different trust stores. The browser may trust a CA that curl cannot find, especially on older systems or custom Linux images.

What is the best fix for “unable to get local issuer certificate”?

The server should send the correct intermediate certificate, or the client should install the missing trusted CA. Using -k should be only a short test.