WordPress cURL error 60: repair the trust failure

cURL error 60 is irritating because the website may be loading perfectly well over HTTPS in a visitor’s browser. That only proves the inbound connection to the public site is working. A WordPress update is an outgoing request made by the server, using its own certificate trust setup.

Abstract certificate chain break between server panels and update package

For a business in Dubai, the UK or anywhere else, the immediate risk is less dramatic than an outage but still worth sorting properly: updates remain blocked, plugin fixes get delayed, and somebody eventually suggests weakening SSL checks just to get the download through. Don’t do that.

Record the failed request before anyone starts changing certificates

Start with the exact update destination and the full redacted error message. A vague note saying SSL failed is not enough to establish which connection, certificate chain or trust store is involved.

Capture the plugin, theme or core update being attempted, the destination hostname, the time of failure, and whether the same error occurs on another update. Keep API keys, cookies and any private paths out of what you share.

  • The update package or service destination
  • The exact cURL error text and number
  • Whether WordPress core, one plugin, or several downloads fail
  • The hosting environment and whether a recent server, PHP or security change occurred
  • Whether a separate server-side request to the same destination succeeds

This is the point where a broader WordPress website repair assessment can be useful. The practical question is not whether SSL exists somewhere on the site. It is which machine made the failed request, what it trusted, and why.

What cURL error 60 actually tells you

cURL defines error 60 as a failure to verify the remote certificate. Its guidance points to problems such as an unavailable or outdated CA bundle, or a certificate chain that cannot be verified back to a trusted authority. The same guidance warns that disabling certificate verification makes the transfer insecure. See the cURL certificate verification guidance for the underlying behaviour.

In plain terms, WordPress asked the server to fetch something over HTTPS and the server could not establish enough trust in the remote certificate presented to it. That could involve the operating system CA store, a PHP or cURL CA configuration, a hosting control layer, a proxy, or the remote service’s supplied chain. It is a verification issue, not a permission issue.

A WordPress update can fail with cURL error 60 when the server cannot verify the certificate for the update destination. Record the destination and exact error, establish which CA trust store and certificate chain the server uses, then have the responsible administrator repair that verification path. Keep SSL verification enabled and retry the same download after the repair.

Do not confuse the public padlock with the update route

A valid padlock in Chrome, Safari or Edge proves that browser can verify the certificate for the public website address. It does not prove the web server can verify a separate plugin repository, licensing endpoint or update host.

Take a simple illustrative case: a service business website loads over HTTPS without warnings, but an installed plugin returns cURL error 60 when WordPress checks for an update. The public site certificate may be entirely fine. Replacing it could change nothing, because the failed connection is from the server to the plugin provider’s destination.

Likewise, this is separate from mixed-content and unsafe-page warnings in WordPress. Mixed content usually concerns insecure resources being loaded into a visitor-facing page. Error 60 concerns certificate verification on an outgoing request.

Identify the trust store used by the failing caller

The server administrator or hosting provider needs to identify the actual caller. On managed hosting, that may be their responsibility. On a VPS, it may sit with whoever manages the operating system, web stack and PHP configuration. For an agency-managed setup, it is worth being clear about that ownership before random changes land on production.

The boring but useful detail is that an old CA bundle can remain in place after other work has moved on. A PHP version change, an isolated runtime configuration, a container image, or a hosting security layer may use a different certificate store from the one assumed by the person looking at the browser padlock.

Compare one failing path with one working path

If a working system can reach the same update destination, compare the caller rather than treating the destination as guilty by default. A local computer, another server or a different PHP runtime may trust the chain successfully while the affected WordPress server does not.

Useful comparison points include:

  • The hostname used for the update request
  • The certificate chain returned by that hostname
  • The CA bundle or system trust store used by the affected runtime
  • Any outbound proxy, firewall inspection or hosting gateway on the server path
  • Recent changes to PHP, cURL, operating system packages or hosting controls

Keep the repair narrowly focused. An administrator may need to update or correct the relevant CA store, amend a bad CA path configuration, or address a chain issue at the remote endpoint. What they should not do is switch off verification and call it fixed.

Keep directory errors in their own lane

WordPress can also fail an update after the download stage because it cannot write files to the intended location. That is a different failure boundary. If the message says WordPress could not create a directory, investigate WordPress update directory ownership checks rather than chasing SSL settings.

It is possible for a site to have more than one issue, of course. But repair works better when each error is tied to its actual stage: download and certificate verification first, then unpacking and filesystem access if the process gets that far.

Retest the same download, not a nearby assumption

Once the responsible administrator has repaired the trust path, repeat the original update check or download. Confirm that WordPress can retrieve the same destination without an SSL verification error. Then check that the update completes normally and does not expose a separate write-permission fault.

A restore point or recent backup is sensible before applying the update, particularly on a live lead generation website during business hours. That does not solve cURL error 60, but it keeps the update itself from becoming a second, unrelated repair job.

Repair the trust failure instead of bypassing certificate verification. Send the update destination and redacted error for a repair assessment.