Fix curl Error 60: "SSL certificate problem: unable to get local issuer certificate"

beginner🔒 SSL/TLS2026-04-20| Linux (Ubuntu, Debian, CentOS, Alpine), macOS, Windows (WSL/Git Bash)

Error Message

curl: (60) SSL certificate problem: unable to get local issuer certificate
#curl#wget#ssl#certificate#ca-bundle#linux

What’s Happening?You go to download a tool or hit an API endpoint, but instead of data, you get a wall of text ending in Error 60. The connection stops instantly because your system can’t verify that the server is who it says it is. It’s a security roadblock designed to protect you from intercepted traffic, but it often triggers due to local configuration issues.

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.

Why Curl is ComplainingMost of the time, the problem boils down to a few common culprits. Your tools (curl or wget) are looking for a "source of truth"—a list of trusted Certificate Authorities (CAs)—and coming up empty.

  • Stale CA Certificates: Your system’s certificate store hasn't been updated in years. It doesn't recognize newer authorities like Let's Encrypt.
  • Stripped-down Environments: Minimal Docker images (like alpine:latest) often omit the ca-certificates package to save space.
  • Corporate "Man-in-the-Middle": Many offices use firewalls (like Zscaler) that swap out a website's real certificate for a company-owned one. If your system doesn't have the company's root cert, it panics.
  • Path Mismatches: The tool is looking for /etc/ssl/certs, but your distribution stores them elsewhere.

Method 1: Update the System Certificate StoreUpdating your system’s "address book" of trusted authorities is usually the quickest fix. This forces the OS to download the latest list of global providers.

Ubuntu / Debian```

sudo apt-get update sudo apt-get install --reinstall ca-certificates sudo update-ca-certificates


### CentOS / RHEL 7 & 8 / Fedora```
sudo yum update ca-certificates
# For newer RHEL-based systems
sudo dnf upgrade ca-certificates
update-ca-trust extract

Alpine Linux (Docker)```

apk update apk add ca-certificates update-ca-certificates


## Method 2: Manually Provide the CA BundleIf you’re working on a locked-down server without root access, you can bypass the system store entirely. Download the latest bundle directly from the curl maintainers and point your command to it.

- Grab the latest bundle: ```
curl -O https://curl.se/ca/cacert.pem
  • Run curl with the --cacert flag: ``` curl --cacert cacert.pem https://example.com
If you prefer **wget**, use this syntax:

wget --ca-certificate=cacert.pem https://example.com


## Method 3: Set an Environment VariableTyping flags for every command is tedious. Instead, tell your shell where to find the certificates globally. This is a lifesaver for CI/CD pipelines or automated scripts.

export CURL_CA_BUNDLE="/home/user/certs/cacert.pem" curl https://example.com


To make this stick, add that export line to the bottom of your `~/.bashrc` or `~/.zshrc` file.
## Method 4: Working Behind a Corporate FirewallIn a corporate environment, the firewall often acts as a proxy. It intercepts your traffic, decrypts it, and re-encrypts it using an internal certificate. You need to tell your machine to trust your employer’s Root CA.

- Ask your IT team for the `.crt` or `.pem` root certificate.
- Move it to the trust folder: ```
sudo cp office-proxy-root.crt /usr/local/share/ca-certificates/
  • Run sudo update-ca-certificates to index it.

Method 5: The Insecure "Quick Fix"Sometimes you just need to get things moving on a local development server using a self-signed cert. You can tell curl to ignore security entirely. Warning: Never use this for public websites or in production code.

# Short flag
curl -k https://localhost:8080

# Long flag
curl --insecure https://localhost:8080

# For wget
wget --no-check-certificate https://localhost:8080

VerificationRun curl with the -v flag to see if the handshake completes successfully. You are looking for the "SSL certificate verify ok" message near the end of the output.

curl -vI https://google.com

Your terminal should confirm the chain of trust:

* TLSv1.3 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* Server certificate:
*  subject: CN=*.google.com
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1C3
*  SSL certificate verify ok.

Stay SecureKeep your environment healthy with these three habits:

  • Auto-Update: Run apt upgrade weekly to keep your CA store fresh.
  • Docker Best Practices: Always add ca-certificates in your Dockerfile during the initial build phase.
  • Avoid Manual Moves: Don't manually move /etc/ssl files. Use the update-ca-certificates utility to manage links safely.

Related Error Notes