A browser can build a missing TLS intermediate from its cache while the server-side WordPress HTTP client cannot. The result is a Site Health loopback or REST API error even though normal visitors see a valid certificate.
Use this when Site Health reports cURL certificate errors, scheduled events fail only over HTTPS, or the same hostname works in a browser but fails from the web server or queue worker.
Quick answer
WordPress Loopback Certificate Chain Intermediate Debug should be handled with a narrow evidence-first workflow: test from origin, compare both ip families, serve full chain, then verify the result before making broader changes.
What to check first
- Run openssl and curl from the actual WordPress web or queue host, not only a laptop.
- Compare the served leaf and intermediate chain for the hostname over IPv4 and IPv6 with SNI enabled.
- Inspect the web server fullchain configuration and confirm no node serves an older certificate bundle.
- Check the operating system and PHP CA bundle paths, permissions, and update dates.
- Retest Site Health, wp-cron, REST API, and one authenticated loopback after correcting the chain.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Test from origin | Run openssl and curl from the actual WordPress web or queue host, not only a laptop. | The origin host validates the full chain without downloading or ignoring certificate errors. |
| Compare both IP families | Compare the served leaf and intermediate chain for the hostname over IPv4 and IPv6 with SNI enabled. | IPv4 and IPv6 return the same valid hostname and intermediate chain. |
| Serve full chain | Inspect the web server fullchain configuration and confirm no node serves an older certificate bundle. | Site Health no longer reports the loopback certificate error. |
| Align CA stores | Check the operating system and PHP CA bundle paths, permissions, and update dates. | wp-cron and REST API tests succeed with normal TLS verification enabled. |
Why this usually happens
- The server can send only the leaf certificate instead of the full chain.
- IPv4 and IPv6 listeners can use different virtual host configurations.
- A load balancer node can retain an older certificate bundle.
- PHP and command-line curl can use different CA stores.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
curl -sS -I --max-time 15 https://example.com/wp-json/
curl -4 -sS -I --max-time 15 https://example.com/wp-json/
curl -6 -sS -I --max-time 15 https://example.com/wp-json/
wp cron test
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Test from origin
- Compare both IP families
- Serve full chain
- Align CA stores
- Retest WordPress paths
What to tell the client or owner
Share hostname, resolved IPs, listener, leaf issuer, intermediate names, verify code, PHP CA path, curl CA path, affected worker, and the post-fix Site Health result.
Production verification checklist
- The origin host validates the full chain without downloading or ignoring certificate errors.
- IPv4 and IPv6 return the same valid hostname and intermediate chain.
- Site Health no longer reports the loopback certificate error.
- wp-cron and REST API tests succeed with normal TLS verification enabled.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix a WordPress loopback error.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references