curl Error 60: SSL Certificate Problem — Self-Signed Certificate

curl refused the connection because the server's certificate is self-signed (or your internal CA signed it). Fix by trusting the CA properly, not by disabling verification in production.

What you'll see

Root causes

Genuinely self-signed cert (dev/lab environment)

The server presents a cert with no trusted chain. Legitimate for internal tooling: import the cert (or your internal CA) into the trust store instead of bypassing checks per command forever.

Internal CA not installed on the client

Corporate environments sign internal certs with a private CA: browsers ship with it via policy, but a server/container won't have it. The error says self-signed but the real issue is the missing CA in the OS trust store.

Fix it

  1. Inspect the actual chain
    openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
  2. Trust the CA (Debian/Ubuntu)
    sudo cp internal-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates
  3. Container images: bake the CA in
    # Dockerfile: COPY internal-ca.crt /usr/local/share/ca-certificates/ && RUN update-ca-certificates
  4. One-off testing only: disable verification explicitly
    curl -k https://internal.example.com/   # or --insecure; never in scripts or CI that touches real systems

Field note

-k moves the failure from curl to your security posture: it accepts ANY certificate, including an attacker's. For internal CAs, install the CA once; for self-signed dev boxes, add the cert to the trust store. Python requests (verify=), Node (rejectUnauthorized), Java (cacerts) each have their own trust stores — fixing the OS store fixes curl, but per-runtime knobs exist for those.

Common questions

Why does the browser accept it but curl rejects it?

The browser either has your corporate CA installed via policy or you clicked past its warning once. curl has no warning click-through — it enforces verification strictly, which is correct.

Is adding the self-signed cert to the trust store safe?

Trusting a specific internal CA you control is standard practice. The risky part is disabling verification (-k), which trusts everything. Scope it: keep the CA internal, and never add it to public-facing systems.

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.

Get new fixes by email

One short email when new fixes and production templates drop. No spam, unsubscribe anytime.

Partner pick — sponsored

NordLayer — our security pick for this stack

Zero-trust access and device security for your whole team — covers the hardening steps above.

Get NordLayer →
Also vetted

Sentry — Catch the error behind this class of bug — exact line, stack and user context.

Get Sentry →

We earn a commission if you buy through our links — it never costs you extra. More vetted tools on our picks hub · comparing clouds? DigitalOcean vs Vultr and vs AWS · full deals: DigitalOcean · Vultr · NordLayer · Semrush