How to skip SSL certificate verification in cURL

HTTPS requests fail immediately when the server certificate does not match the hostname, has expired, or chains to a certificate authority that the local trust store does not recognize. Temporarily bypassing that check can keep a staging API, internal service, or broken renewal visible long enough to confirm whether the problem is trust validation rather than basic network reachability.

For HTTPS transfers, cURL normally asks its TLS backend to verify both the certificate chain and the hostname in the URL before any application data is trusted. The --insecure option, or its short form -k, skips that verification so the transfer can continue and return a response even when identity checks fail.

That bypass keeps the connection encrypted but removes proof that the remote endpoint is the right server. Credentials, tokens, cookies, and API payloads can therefore be exposed to man-in-the-middle interception, and current curl documentation also warns that insecure sessions can cause HSTS or Alt-Svc data from malicious servers to be trusted later. Use it only for short-lived diagnostics, then return to normal verification or fix trust with the correct CA bundle or a valid certificate. The hostnames, paths, and response bodies below are masked examples that preserve the shape of a real staging-service check without exposing a live endpoint.

1. Reproduce the certificate validation failure first so the problem is clearly a trust or hostname check.

   $ curl --silent --show-error https://api.staging.example.net/health -o /dev/null
   curl: (60) SSL: no alternative certificate subject name matches target host name 'api.staging.example.net'

   On current curl builds, curl: (60) is the common HTTPS certificate-verification failure code; the exact wording after it depends on the certificate problem that the TLS backend detects.

2. Repeat the same request with --insecure when the goal is to confirm that the endpoint itself is reachable despite the bad certificate.

   $ curl --silent --show-error --insecure https://api.staging.example.net/health
   {
     "status": "ok",
     "service": "orders-api",
     "environment": "staging"
   }

   The short option -k is equivalent to --insecure.

   Use insecure mode only against a known test target. A successful response here proves reachability, not identity.

3. Compare strict and insecure runs side by side to confirm that only certificate verification is blocking the transfer.

   $ curl --silent --show-error https://api.staging.example.net/health -o /dev/null || printf 'verify-failed=%s\n' $?
   curl: (60) SSL: no alternative certificate subject name matches target host name 'api.staging.example.net'
   verify-failed=60
   
   $ curl --silent --show-error --insecure https://api.staging.example.net/health -o /dev/null --write-out 'response_code=%{response_code}\n'
   response_code=200

   A nonzero exit without --insecure plus a normal HTTP status with it is a strong sign that routing and application handling are fine and the failure is limited to trust validation.

4. Use a dedicated config file when several temporary test calls need the same bypass, instead of placing insecure in a default account-wide curl config.

   $ cat > curl-staging-insecure.cfg <<'EOF'
   insecure
   silent
   show-error
   EOF
   
   $ curl --config curl-staging-insecure.cfg https://api.staging.example.net/health -o /dev/null \
     --write-out 'response_code=%{response_code}\n'
   response_code=200

   Current curl versions read default config files automatically, so a persistent insecure line in ~/.curlrc can weaken every later cURL command run by that account.

5. Remove the temporary bypass as soon as testing is finished and return to normal certificate validation.

   $ rm -f curl-staging-insecure.cfg
   
   $ curl --silent --show-error https://api.staging.example.net/health -o /dev/null || printf 'verify-failed=%s\n' $?
   curl: (60) SSL: no alternative certificate subject name matches target host name 'api.staging.example.net'
   verify-failed=60

   The long-term fix is to repair the certificate, hostname, or trust chain rather than leaving verification disabled.

   Related: How to use client certificates and CA certificates with cURL
   Related: How to debug TLS handshake with cURL