curl SSL certificate problem: fix trust without using --insecure
Separate a local CA-store problem from an expired, mismatched, or incomplete server certificate, and check the fix with verification still enabled.
In this guide
curl: (60) SSL certificate problem means curl could not verify the HTTPS server’s certificate. The request has stopped before curl trusts that connection.
Keep verification enabled. Adding -k or --insecure can make the command return a page, but it removes the check that you are talking securely to the intended server. Instead, identify whether the problem is your computer’s trusted certificates, the server’s certificate, or an approved private-network certificate.
This guide uses Ubuntu 24.04 and curl 8.5 or newer. You need a terminal and the HTTPS address you intended to contact. Commands below do not need API keys or passwords.
Read the full error first
Check your curl version and the system’s UTC time:
curl --version
date -uIf curl is missing, install it using Ubuntu’s package manager before continuing. If the time is clearly wrong, ask the system administrator or hosting support to repair time synchronization; certificate validity depends on the clock.
Replace YOUR_HOST with your actual hostname in this diagnostic request. Use a public path without tokens or personal data:
curl --verbose --head --connect-timeout 10 --max-time 20 https://YOUR_HOST/--head requests response headers rather than the whole page. Verbose output shows connection and certificate details. It can reveal private hostnames, so remove those before sharing logs.
| Error detail | Likely next check |
|---|---|
| Unable to get local issuer certificate | Local trusted certificates or the server's missing intermediate chain |
| Certificate has expired / not yet valid | System clock and server certificate dates |
| Certificate does not match the target hostname | Correct URL and certificate names on the server |
| Self-signed certificate | Intended private/test service, or an untrusted/intercepted connection |
The wording is a clue, not proof of a single cause. For example, a missing intermediate on the server and a missing trusted authority locally can produce similar errors.
See whether the failure is specific to this server
Try a known public HTTPS endpoint from the same terminal:
curl --head --connect-timeout 10 --max-time 20 https://example.com/If this succeeds but your target fails, focus first on the target’s hostname, dates, and certificate chain. If multiple unrelated HTTPS endpoints fail, check the local trust store, clock, and network policy.
A browser working on another computer does not prove this curl installation is configured correctly. Different devices, containers, and TLS libraries can use different trust stores. Ubuntu’s curl normally uses a file-based CA store; the Windows build may instead use Windows’ native store.
Follow the relevant repair path
Ordinary public website: repair the server or local package
If you manage the failing website, renew an expired certificate and configure the web server with the correct hostname and full certificate chain according to your certificate issuer’s instructions. If you do not manage it, send the hostname and sanitized error to its operator. A visitor cannot repair a server’s certificate by changing their own DNS.
For an Ubuntu machine with a missing or damaged standard CA package, an administrator can restore the package and rebuild its trust bundle:
sudo apt-get update && sudo apt-get install --reinstall ca-certificates && sudo update-ca-certificatesThis changes the machine’s trust files. Use it only on a machine you administer and after checking local policy. If apt-get update itself fails because of HTTPS trust or a corporate proxy, stop and ask the administrator for the approved repair; do not disable certificate checks to fetch packages.
If curl runs inside a container, repairing the host’s package may not change the container’s CA files. Follow the image’s documented package/trust setup and rebuild that image; do not assume host and container share a store.
Intended private service: use its approved CA for this request
A company may have its own certificate authority, or CA—the organization trusted to sign certificates for that network. Obtain its root certificate through your administrator’s authenticated, approved channel. Do not simply download the failing server’s certificate and declare it trusted.
Save that approved CA certificate as company-root.pem in your working folder, then make one request with it:
curl --cacert company-root.pem --head --connect-timeout 10 --max-time 20 https://YOUR_HOST/This uses the supplied trust file for this transfer. Curl still checks that the server certificate is valid for the hostname. A private CA does not fix an expired or wrong-name certificate, and a legitimate corporate certificate should not be guessed from an error message.
Verify the fix with protection still on
Repeat the original command without -k, using the approved --cacert file only if this private-service path applies. You should no longer receive error 60 and should reach an HTTP response.
An HTTP 401, 403, or 405 is a separate application or method result: a successful TLS check does not grant access or guarantee that the server accepts HEAD requests. Likewise, HTTP success says nothing about the truth of the returned data.
If the same certificate failure remains, keep the error and the failing hostname together for support. Avoid repeatedly changing trust settings. The result you want is a verified connection to the intended host, not merely a command that prints something.
Sources and useful links
- curl certificate verification — explains trust stores, private CAs, and why verification should remain enabled.
- curl command reference — documents
--cacert, HEAD, verbose output, and time limits. - Ubuntu update-ca-certificates manual — explains the system trust bundle rebuilt by the Ubuntu command.