How to ignore SSL certificate errors in cURL

HTTPS traffic relies on valid SSL certificates so clients know which servers to trust. When a service presents a self-signed, expired, or hostname-mismatched certificate, strict validation causes cURL requests to fail even though the endpoint is reachable. Temporarily relaxing these checks can help diagnose internal services, staging APIs, and legacy systems that do not yet provide a complete, trusted certificate chain.

$ curl https://www.example.com/
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

curl: (60) SSL: no alternative certificate subject name matches target host name 'www.example.com'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

During an HTTPS request, cURL delegates certificate handling to the underlying TLS library, which validates the issuer chain, hostname, and expiry time against a trusted certificate store. Options such as --insecure (with short form ‑k) instruct cURL to skip these verification steps while still encrypting the connection. Per-user configuration in ~/.curlrc can toggle this behavior automatically, so repeated test calls do not need the option on every command line.

Disabling certificate checks removes protection against man-in-the-middle attacks and misconfigured or malicious endpoints. Credentials, tokens, or sensitive payloads sent over such connections can be intercepted if a rogue TLS endpoint can impersonate the target host. Insecure mode suits only controlled testing on trusted networks, with a strong preference for long-term fixes such as deploying valid certificates or importing an internal certificate authority into the trust store.

Steps to skip SSL certificate verification in cURL:

Open a terminal in an environment where cURL is installed.

Run a standard HTTPS request against a site with a self-signed or otherwise invalid certificate to reproduce the SSL error.

$ curl https://self-signed.badssl.com/
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Error codes such as curl: (51) and curl: (60) indicate certificate validation problems rather than DNS resolution or basic connectivity issues.

Repeat the request with the --insecure option so certificate validation is bypassed and the response body is returned.
```
$ curl --insecure https://self-signed.badssl.com/
<!DOCTYPE html>
<html>
  <head>
    <title>self-signed.badssl.com</title>
##### snipped #####
```
The short option ‑k behaves identically to --insecure and is commonly used in scripts and examples.
Persist insecure mode for controlled testing by adding the insecure option to the ~/.curlrc configuration file.
```
$ printf '%s\n' 'insecure' >> ~/.curlrc
```
Adding insecure to ~/.curlrc disables certificate validation for all cURL commands in that account, which can expose credentials and data to interception on untrusted or hostile networks.
Confirm that insecure mode is active by repeating a request that previously failed and ensuring that normal content is returned without SSL errors.
```
$ curl https://self-signed.badssl.com/ | head -n 3
<!DOCTYPE html>
<html>
  <head>
```
Successful bypass is indicated by normal HTML or API output, a zero exit status, and the absence of certificate-related error messages such as curl: (60) SSL certificate problem.
Disable insecure mode again by removing the insecure line from ~/.curlrc once testing is finished.
```
$ sed --in-place '/^insecure$/d' ~/.curlrc
```
Restoring strict certificate verification before regular use re-enables protection against man-in-the-middle attacks and misissued certificates.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.

Discuss the article:

Comment anonymously. Login not required.