What matters first: The outbound HTTPS connection reached a server, but certificate validation failed. The cause may be an expired certificate, missing intermediate, wrong hostname, stale CA bundle or intercepted traffic.
What this symptom actually tells you
This is a trust failure, not a generic network timeout. Disabling sslverify makes the warning disappear by removing the protection that prevents man-in-the-middle responses.
Capture evidence before changing anything
- Record the destination hostname and full certificate error.
- Inspect the certificate chain from the WordPress server, not only a browser.
- Check the server’s date, CA bundle and OpenSSL/cURL versions.
- Confirm no proxy or security appliance is substituting its own certificate.
Most common causes
- Incomplete remote chain: The origin does not serve the intermediate certificate needed to reach a trusted root.
- Expired or mismatched certificate: The certificate is outside its validity period or does not cover the requested hostname.
- Outdated CA store: The hosting image or operating system lacks a current trust bundle.
- TLS interception: A proxy presents a private certificate the server does not trust.
Safe diagnostic and repair sequence
- Repair the certificate chain on the remote service when you control it.
- Update the operating system CA certificates and restart the relevant PHP service.
- Use the correct hostname and remove redirects to hosts not covered by the certificate.
- Re-test with verification enabled and document any required private CA installation.
How to choose between the likely causes
Do not treat Incomplete remote chain and Expired or mismatched certificate as interchangeable. The origin does not serve the intermediate certificate needed to reach a trusted root. By contrast, the certificate is outside its validity period or does not cover the requested hostname. Use two checks to separate them: Record the destination hostname and full certificate error; and inspect the certificate chain from the WordPress server, not only a browser. Those observations usually show whether the next safe move is to repair the certificate chain on the remote service when you control it or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Never ship a permanent filter that sets sslverify to false. It exposes updates, licences, webhooks and API traffic to tampering.
How to verify the repair
- The server validates the complete chain with the intended hostname.
- WordPress performs the outbound request with SSL verification enabled.
- No certificate warning remains in Site Health or the calling plugin’s logs.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
This is a trust failure, not a generic network timeout. Disabling sslverify makes the warning disappear by removing the protection that prevents man-in-the-middle responses.
- Record the destination hostname and full certificate error.
- Inspect the certificate chain from the WordPress server, not only a browser.
- Check the server’s date, CA bundle and OpenSSL/cURL versions.
- Confirm no proxy or security appliance is substituting its own certificate.
What must be verified
- The server validates the complete chain with the intended hostname.
- WordPress performs the outbound request with SSL verification enabled.
- No certificate warning remains in Site Health or the calling plugin’s logs.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it safe to just disable sslverify to stop this error from appearing?+
No. Disabling sslverify removes the exact protection that prevents a man-in-the-middle response from being accepted as legitimate. It should never be shipped as a permanent fix since it exposes updates, licences, webhooks, and API traffic to tampering.
The certificate looks fine in my browser — why does WordPress still report error 60?+
A browser and a server can see different certificate chains. The server may lack an updated CA bundle, or the remote origin may not be serving the intermediate certificate needed to build a trusted chain, even though a browser's own trust store papers over the gap.
Could a corporate proxy be the actual cause instead of the certificate itself?+
Yes. TLS interception by a proxy or security appliance presents its own certificate in place of the real one, which the server correctly refuses to trust. Confirming no proxy is substituting its certificate is one of the first checks before assuming the remote chain is broken.
If I fix the certificate chain, do I still need to update anything on the WordPress server?+
Possibly. Even with a correct remote chain, an outdated CA store on the hosting image or operating system can still fail validation. Update the server's CA certificates and restart the relevant PHP service, then re-test with verification enabled rather than assuming the remote-side fix alone is sufficient.