WordPress cURL Error 60: SSL Certificate Problem

WordPress cURL error 60 means an HTTPS client’s certificate verification failed. The rest of the message matters: “unable to get local issuer certificate,” “certificate has expired,” and a hostname mismatch lead to different investigations. Keep verification enabled and identify the destination, certificate chain, and trust store used by the failing request.

This is not automatically a problem with the certificate visitors see on your WordPress homepage. WordPress may be calling an update server, payment API, plugin service, or its own URL. A browser opening that destination successfully does not prove the server-side PHP client trusts the same chain.

Quick triage: destination, trust store, or runtime?

1. Record the complete failure and affected operation

Capture the exact error string, destination hostname and safe path, observation time, and operation. Is a plugin update failing, a background API call stopping, or a loopback test reporting trouble? Remove query-string credentials and customer information before sharing evidence.

The libcurl error reference defines code 60 as peer verification failure. It is distinct from a timeout, DNS lookup failure, or local CA file-read problem. Do not reduce a detailed certificate message to “the network is slow.” For a genuine timeout instead, see our cURL error 28 diagnostic guide.

Note whether every attempt fails and whether the problem started after a certificate renewal, migration, PHP change, or plugin update. If the failure affects a charge or renewal, inspect external transaction state before retrying that operation. Fixing TLS does not make a business request automatically safe to replay.

2. Inspect the endpoint from the relevant server

An authorized administrator can make one unauthenticated diagnostic request to a known safe, public endpoint on the affected hostname. Replace the example below. Avoid payment endpoints, signed URLs, cron triggers, and any URL where a GET or HEAD could initiate work.

date -u
curl --version
curl --verbose --head --connect-timeout 10 --max-time 20 https://example.com/

These checks do not change WordPress settings and do not disable verification. The request is still network activity and may be logged remotely. A server can reject HEAD even when TLS is healthy; a later HTTP 403 or 405 should not be confused with the preceding certificate-verification result. Inspect redirects individually rather than forwarding sensitive headers automatically.

Verbose output can reveal the selected CA file, TLS backend, certificate issuer, hostname, and failure reason. Review and redact it before sharing. For deeper chain inspection, ask the host to use a TLS diagnostic with SNI set to the intended hostname. Testing only an IP address can produce a name mismatch that normal hostname requests would not have.

Do not install a certificate merely because the failing connection presented it. If DNS, routing, or interception is wrong, trusting that certificate can authorize the wrong server. Confirm the expected issuer and endpoint with the service owner through an independent trusted channel.

3. Compare shell curl with WordPress’s actual trust path

The official WordPress HTTP request reference defaults to certificate verification enabled and a bundled CA file under wp-includes/certificates/ca-bundle.crt. Plugins can override request arguments, and some integrations use a separate HTTP library or raw PHP cURL. Establish which path the failing integration uses before changing a configuration file.

For this reason, updating the operating system’s CA package does not necessarily update the bundle used by WordPress. Setting curl.cainfo may affect a direct PHP cURL client while leaving a WordPress HTTP API request using an explicitly supplied bundle unchanged. Likewise, the shell’s curl can use a different TLS backend and trust source from web PHP.

Ask the host to compare the web-facing PHP handler, CLI PHP, loaded configuration files, CA paths, and file readability. Use Site Health’s PHP information and protected host diagnostics, not a publicly accessible phpinfo() page. Our active PHP handler guide explains why a command-line check does not establish the web runtime’s configuration.

A passing browser test is only a comparison. Browsers can use different trust stores and chain-building behavior. Even two server clients may reach different addresses or traverse different proxies; record the actual route before concluding the remote certificate is universally healthy.

4. Correct the evidenced certificate or trust defect

The remote chain is incomplete, expired, or wrong for the hostname

Have the endpoint owner install the correct leaf certificate and required intermediates, renew an expired certificate, or correct the requested hostname. If you do not own that service, send the sanitized verification result to its operator. Changing the certificate on your WordPress site will not fix an unrelated outbound API endpoint.

The client’s trust data or configuration is stale

Update through the responsible software’s supported release process after a backup and compatibility test. Check whether the CA bundle being used is current and readable by the PHP worker. Correct a wrong path or system clock through the host’s normal configuration process. Do not download a replacement trust bundle from an arbitrary forum attachment.

A private CA or TLS inspection proxy is intentional

Ask the organization to verify and supply the approved CA through its managed trust process. Scope trust to the intended environment or client where possible. The official curl certificate guide explains CA-store selection and explicitly warns never to skip verification in production. Adding a trust root is a security decision, not a harmless workaround.

A real WordPress case: an old bundled CA store

In this WordPress.org support case, an administrator reported download failures with “unable to get local issuer certificate.” The moderator identified an extremely old WordPress installation and discussed its outdated bundled CA certificates and a backed-up upgrade path.

The case supports checking WordPress’s own trust data, not blindly adopting its version-specific upgrade sequence. A current installation can fail for a different reason, including the remote server’s chain. Preserve the exact environment when escalating.

5. Verify through the original application path

After the focused correction, repeat the safe endpoint check with verification enabled. Then test the original WordPress workflow under controlled conditions. For a loopback warning, rerun the relevant Site Health check; for a third-party integration, use its documented non-transactional connection test where available.

A verified outcome means the original client accepts the correct peer and the intended operation succeeds. A shell-only success, suppressed warning, or insecure bypass is insufficient. Check logs for the former error, remove temporary diagnostics, and document the changed trust source. If loopbacks now fail with a timeout rather than error 60, that is a different remaining problem; use our loopback request guide.

What not to do

• Do not use sslverify=false, global verification-disabling filters, or an insecure curl option in production.
• Do not replace HTTPS with HTTP to hide a certificate failure.
• Do not trust an unexpected self-signed certificate without independent verification.
• Do not replay purchases or renewals merely because a TLS test now passes.

FAQ

Will a longer timeout fix error 60?

No. Verification failure requires correcting identity, chain, trust, or configuration evidence, not waiting longer.

Does renewing my website’s certificate fix outbound requests?

Only if that website is the failing destination and its certificate is the cause. Identify the actual hostname first.

When should a developer become involved?

When a plugin overrides CA paths or uses a separate transport, provide its version and sanitized request evidence. ModelGain WordPress development can scope integration investigation; host-level trust and third-party certificate repairs remain with their respective owners.