Free tools Windows power users keep installed
One-click scans. No signup required.
When WordPress says it “could not establish a secure connection to WordPress.org,” start with Tools > Site Health > Status and record the complete cURL or HTTP error, destination, and any REST API or loopback failures. This warning normally means the server cannot reach api.wordpress.org for version checks and updates; it does not, by itself, prove that your public website certificate is broken.
First, identify which secure-connection problem you have
Two different network paths are commonly described with similar wording. Diagnose the path that actually fails.
| Symptom | Connection being tested | Where to investigate |
|---|---|---|
| Site Health reports “Could not reach WordPress.org” | Your web server to api.wordpress.org |
DNS, outbound firewall rules, hosting policy, PHP/cURL, and WordPress HTTP configuration |
| A browser warns about the site certificate, TLS, or repeated HTTPS redirects | Browser to your website or reverse proxy | Certificate, web-server TLS settings, redirects, and proxy headers |
WordPress requires a TLS/SSL certificate to be installed and available on the web server before HTTPS features such as FORCE_SSL_ADMIN can work. See the WordPress HTTPS documentation for the browser-facing branch.
Capture the exact evidence before changing anything
- Open Tools > Site Health > Status and expand the WordPress.org, REST API, and loopback results.
- Copy the full message, cURL or HTTP code, destination hostname or IP (if shown), and the time of the failure.
- Open the Info tab and note the PHP and cURL versions and other server details. This screen reports configuration; it does not change server settings.
- Check the hosting account’s PHP and web-server error logs for entries at the same time. Remove passwords, tokens, cookies, and authentication headers before sharing excerpts.
WordPress describes the Site Health finding as an inability to reach api.wordpress.org, which can stop version checks and installation or updating of core, themes, and plugins. The official explanation is available in the Site Health screen documentation.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors“This message means your site is unable to reach WordPress.org at api.wordpress.org”
WordPress Site Health documentation
Match the error to the right repair
DNS or getaddrinfo errors
If the message explicitly reports name resolution, such as a getaddrinfo failure, ask the host to test DNS resolution from the web server. A WordPress.org support case reported cURL error 6 (getaddrinfo() thread failed to start) for both the WordPress.org check and a REST request; the reply treated that particular pattern as a host-side DNS problem. It is a case example, not a diagnosis for every cURL error 6.
Timeouts, refusals, or outbound firewall blocks
For timeout, connection-refused, or access-denied messages, give the host the destination and timestamp and ask whether outbound HTTPS/DNS traffic is restricted by a firewall, security policy, or network ACL. One support thread found local firewall/access rules behind a plugin-page failure; that report does not establish a universal cause.
PHP, cURL, or server trust configuration
Use the Site Health Info details and logs to show the host exactly what is failing. Missing or unsuitable cURL/PHP components, certificate trust configuration, or other server-level settings may require provider intervention. WordPress notes that some server settings are managed by the host.
Requests blocked by WordPress configuration
Check whether WP_HTTP_BLOCK_EXTERNAL is enabled in wp-config.php. Site Health documents that this setting can block HTTP requests when allowed hosts are not configured. Change it only when you understand the intended security policy and have confirmed that it is the blocking layer.
Browser certificate or reverse-proxy symptoms
If visitors or the administrator see certificate warnings, handshake errors, mixed HTTPS behavior, or redirect loops, inspect the certificate chain, hostname coverage, web-server TLS configuration, and proxy termination settings. With a proxy that terminates SSL, WordPress may need a correctly supplied HTTP_X_FORWARDED_PROTO value so it knows the original request used HTTPS. Fixing the public certificate will not normally repair a separate server-to-WordPress.org DNS or firewall failure.
Plugin or theme involvement
A plugin or theme is not established as the cause merely because the warning appears in the dashboard. If logs show that a recently changed extension is intercepting HTTP requests, isolate it carefully on staging or under a maintenance plan: deactivate plugins, test, then reactivate them one at a time; also test a default theme. This is the isolation method in WordPress’s common-errors guide, and should be evidence-led rather than the first guess.
Send your host a useful escalation package
- Exact Site Health wording and the cURL/HTTP code
- Destination hostname or IP, if displayed
- Timestamp and time zone
- Related REST API or loopback result
- Relevant, sanitized PHP/web-server log lines
- PHP and cURL versions from Site Health Info
Ask support to test DNS resolution and outbound network access from the web server, then review the applicable PHP/cURL/TLS and proxy configuration. Do not send secrets or unredacted debug output.
Re-test safely
- After one targeted change, return to Tools > Site Health > Status.
- Run the previously failing update, plugin page, or REST request again.
- Confirm whether the same destination and code still fail.
- Keep a record of the change so it can be reverted if another request breaks.
Do not broadly disable firewalls, HTTP restrictions, or certificate validation, and do not replace a public certificate solely because the dashboard uses the word “secure.” The remedy must match the failing connection and its evidence.
Use these questions to narrow the diagnosis
- Is the failed request server-to-WordPress.org, or browser-to-your site?
- Does the error identify DNS, timeout/refusal, blocked HTTP, TLS verification, or application behavior?
- Do multiple server-originated requests fail, or only one destination?
- Do all visitors see the issue, or only one browser, device, or network?
- Did it begin after a plugin, theme, proxy, firewall, or hosting change?
- Which layer owns the setting: WordPress, an extension, the web server, the proxy, or the host?
For WordPress installation requirements, consult WordPress.org’s Requirements page.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
