technology · PRACTICAL GUIDE
curl error 60? Audit the certificate chain and trust store before using --insecure
“Unable to get local issuer certificate” does not identify one universal fix. Capture curl’s TLS backend, CAfile, CApath and proxy route, then repair the server chain, client trust input or inspection proxy without disabling verification.
curl error 60 is a verification failure, not a command to turn verification off. The missing link may be in the server’s presented chain, curl’s selected trust input, an application-specific bundle or a TLS-inspecting proxy.
Audit in this order: endpoint, chain, backend, trust input, repair. The evidence determines whether to fix the server, install a verified private CA, select the intended native or file store, or repair proxy-specific trust.
Freeze the failing endpoint and curl build
Record the exact URL, hostname, port, user context, proxy variables and full error before changing trust. Run curl -V to capture the curl version and TLS backend, then curl -v URL and save the lines that name CAfile, CApath, the connection target and any CONNECT proxy. Redact credentials, not the certificate issuer or path. A browser working only proves that the browser found a chain it trusts; it may use a different store, cached intermediate or inspection policy.
Repeat the request from the same shell, container or service account that failed. Root, a desktop user, PHP, Git and Composer can resolve different configuration files or CA bundles. If -k makes the transfer work, treat that only as evidence that peer verification is the boundary. Remove it immediately; the curl project explicitly warns against skipping verification in production.
Inspect the chain the endpoint actually presents
Use a chain-inspection tool against the exact hostname and port, including SNI, and record the leaf subject, issuer and sent intermediates. For a public site, an omitted intermediate is a server deployment defect: serve the leaf with the required intermediate chain and retest from a clean client. Do not solve that by teaching every client to trust the leaf certificate as a root.
If a proxy or security appliance terminates TLS, the issuer may belong to the organization rather than the public site. Prove that route with curl -v, environment variables and the presented issuer. HTTPS proxy trust is separate in curl: proxy CA options control the proxy connection, while --cacert and --ca-native control verification of the origin connection.
Prove which trust input this curl build uses
curl verifies both the certificate signature chain and the hostname. Builds using Schannel normally use the Windows native CA store; many other TLS backends use a file-based store by default. curl -v often reports CAfile and CApath. Check CURL_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR, application settings and mounted container files before replacing a system bundle.
Use --cacert only with a verified PEM CA file and --capath only with a correctly prepared directory. Use --ca-native when the current curl build supports the native store and that is the intended policy. On Apple systems, combining --ca-native with --cacert can consider both native trust and a supplied file; exact behavior still depends on the build.
Apply the smallest verified repair
If the server omitted an intermediate, fix the served chain. If a known private or corporate CA is intended, verify its fingerprint and owner through an authenticated channel, then trust that CA at the narrowest required scope. Ubuntu’s documented system path is a PEM certificate with a .crt extension under /usr/local/share/ca-certificates followed by update-ca-certificates; Red Hat documents its own anchor directories and update-ca-trust. Record how to remove the anchor.
If only one application fails, repair its CA path or runtime configuration instead of modifying global trust. If only an HTTPS proxy fails, use the proxy-specific CA controls. If the issuer is unexpected, stop and escalate rather than importing it. A downloaded public bundle can refresh stale public roots, but it is not a substitute for validating an enterprise or self-signed CA.
Retest verification, scope and rollback
Retest without -k and without temporary overrides. Confirm the expected hostname, issuer, backend and CA source in verbose output, then test the real application and a clean environment. A successful curl command with a one-off --cacert proves that file can validate the peer; it does not prove that PHP, Git, a container or a service will read the same file.
Document the failing evidence, the exact trust change, who owns the CA, its expiry and the rollback command. For a server-chain repair, test more than one clean client. For a private anchor, verify removal as well as installation. Keep peer verification enabled so the next unexpected issuer remains visible rather than becoming a silent security exception.
