Fix “Outbound HTTPS not working” in Jetpack

If you see “Outbound HTTPS not working” in Jetpack, the problem is almost never the Jetpack plugin itself.

Your site is failing a simple connection test.

Jetpack is trying to open an HTTPS connection from your server to WordPress.com. The test fails, so Jetpack shows this warning instead of enabling full features.

Most of the time that means:

• Your server cannot make outbound HTTPS requests on port 443.
• Your SSL certificate or certificate chain is not valid.
• PHP cURL or OpenSSL are missing or outdated.
• A firewall or security layer is blocking Jetpack or WordPress.com.

We will start with the easy checks inside WordPress. Then we will move to server and hosting level fixes that often need your host to help.

What “Outbound HTTPS not working” actually means

When Jetpack tests your connection, it asks your server to:

1. Resolve WordPress.com and Jetpack related domains.
2. Open an outbound HTTPS connection on port 443.
3. Complete a TLS handshake using your server SSL libraries.
4. Exchange a small request and response.

If any step fails, Jetpack cannot trust the connection.

So you see:

Outbound HTTPS not working. Your site could not connect to WordPress.com via HTTPS.

This is almost always a server or network problem. You fix it either in your WordPress URL settings, in your SSL configuration, in PHP libraries, or in your firewall and hosting setup.

Quick WordPress checks inside wp-admin

These are simple and safe. Do them first.

1. Make sure your site actually runs over HTTPS

1. Open your site in a private browser window.
2. Check the address bar. It should show https:// and no certificate warnings.

If the browser itself shows a certificate warning or a “not secure” label, fix that first with your host. Jetpack will not connect cleanly while the browser is unhappy.

2. Confirm WordPress URL settings use HTTPS

In your WordPress dashboard:

1. Go to Settings → General.
2. Check WordPress Address (URL) and Site Address (URL).
3. Both should start with https://your-domain.com and match your real domain exactly.

If they still use http:// or a different hostname, update them, save, then log in again and retest Jetpack.

3. Re run the Jetpack test

In wp-admin:

1. Go to Jetpack → Dashboard.
2. Look for any notice about connection or “Outbound HTTPS not working”.
3. Click any “Test again” or “Check again” link if it appears. Jetpack also retests on its own after a while.

If the warning clears after fixing your URLs, you are done.

If it is still there, move on to the server checks.

Step 1: Test outbound HTTPS from your server

If you have hosting support, you can copy and paste this section into a ticket.

Your goal is to confirm:

• Outbound connections on port 443 are allowed.
• The server can reach WordPress.com and Jetpack endpoints.

If you have SSH access

Ask your host to run, or run yourself, simple curl tests from the server that runs WordPress.

Use something like:

curl -I https://wordpress.com
curl -I https://public-api.wordpress.com/wp-json/
curl -I https://jetpack.com

Things to look for:

• If all commands time out or say “Connection refused” then outbound HTTPS is blocked or filtered.
• If they show “SSL certificate problem” then the SSL libraries or CA bundle on the server are not set up correctly.
• If they work for https://wordpress.com but not for other URLs, the problem is likely a firewall rule or DNS rule specific to some hosts.

If you do not have SSH

Open a ticket with your hosting provider. Include this text you can adapt:

I am getting this Jetpack status in WordPress:

"Outbound HTTPS not working. Your site could not connect to WordPress.com via HTTPS."

Can you please:
1. Confirm that my server can make outbound HTTPS (port 443) requests to:
   - wordpress.com
   - public-api.wordpress.com
   - jetpack.com
2. Confirm that PHP cURL and OpenSSL are installed and can make outbound HTTPS requests.
3. Check that no firewall, mod_security rule, or rate limit is blocking requests to Jetpack or WordPress.com IP ranges.

Ask them to fix any blocked outbound HTTPS or firewall rule. Then re test Jetpack.

Step 2: Fix SSL certificate and chain problems

Even if your site seems to work in a browser, the certificate chain might not be fully correct from the server side. That can make Jetpack fail tests with messages like “SSL certificate problem” in logs.

Here is what to check.

1. Check your certificate with an external SSL checker

Use any reputable SSL checker service.

You want to see:

• The certificate is valid for your exact domain.
• The certificate is not expired.
• The full chain is sent, including any intermediate certificates.

If the checker reports:

• “Chain incomplete”
• “Unable to get local issuer certificate”
• Or uses a different hostname

then your host needs to reinstall the certificate or add the full chain.

2. If you use a shared or temporary SSL URL

Some hosts give a shared SSL URL that looks different from your real domain.

If WordPress is configured to use your own domain but the server certificate is issued for a shared hostname, Jetpack can see that mismatch and refuse the connection.

Ask your host to:

• Install a proper SSL certificate on your real domain.
• Or disable the shared SSL layer for your site if it conflicts.

3. After SSL changes

Once the host fixes the certificate:

1. Clear any caches on the server and in plugins.
2. Visit your site over https:// and confirm no browser warnings appear.
3. In wp-admin, go back to Jetpack → Dashboard and check the status again.

Step 3: Check PHP cURL and OpenSSL on the server

Jetpack uses the WordPress HTTP API. That often relies on the PHP cURL extension and OpenSSL library.

If they are missing or too old, outbound HTTPS can fail.

Check via Site Health

In WordPress:

1. Go to Tools → Site Health → Info.
2. Expand the Server and WordPress constants sections.
3. Look for entries mentioning cURL and OpenSSL.

If Site Health reports that cURL is missing, or that HTTPS requests are failing, your host must update PHP with cURL and SSL support.

Check via phpinfo

If you are comfortable and your host allows it:

1. Create a file called phpinfo.php in your WordPress root.
2. Put this in it:

<?php
phpinfo();

1. Visit https://your-domain.com/phpinfo.php.
2. Search for cURL and OpenSSL.

You should see:

• cURL support enabled.
• An OpenSSL version that supports modern TLS.

If not, ask your host to:

• Enable the PHP cURL extension.
• Update OpenSSL.
• Make sure PHP can load the system CA certificates.

When you are done, delete phpinfo.php for security.

Step 4: Whitelist Jetpack in firewalls and security plugins

Even with good SSL and libraries, a firewall can break Jetpack.

Possible blockers:

• Server side firewalls or ufw on Linux blocking outgoing port 443.
• Web application firewalls like mod_security.
• CDN or proxy firewalls.
• WordPress security plugins that block outgoing HTTP API calls.

Temporary test

To see if a firewall is the cause:

1. Temporarily disable any security plugins that filter traffic or block external calls.
2. If your host gives a control panel for a WAF, temporarily set it to a relaxed mode.
3. Ask your host to check their firewall logs for blocked connections from your server to WordPress.com or Jetpack IPs.
4. Re test Jetpack in Jetpack → Dashboard.

If the warning disappears while security is relaxed, you have found the cause. You now need permanent firewall rules.

Permanent firewall rules

Ask your host or network admin to:

• Allow outbound HTTPS to WordPress.com and Jetpack related endpoints.
• Allow the official Jetpack IP ranges that need to reach your site, as listed in Jetpack’s allowlist documentation.
• Exclude Jetpack related requests from overly strict rules where possible.

After rules are updated, re enable your security plugins and test again.

Step 5: Rule out plugin conflicts in WordPress

Some plugins hook into the WordPress HTTP API and can block remote requests by policy.

Typical candidates:

• Security plugins that disable wp_remote_get() or wp_remote_post().
• Plugins that restrict external domains for performance or privacy.

Safe test for conflicts

You can run a quick test without touching your theme:

1. Go to Plugins → Installed Plugins.
2. Temporarily disable any security, firewall, or “block external requests” plugins.
3. Leave Jetpack active.
4. Check Jetpack → Dashboard again.

If the warning disappears, re enable plugins one by one. After you turn each plugin back on, recheck Jetpack.

When the warning returns, you have found the plugin that needs configuration. Look in its settings for options like “Allow WordPress.com” or “Allow Jetpack” or exclude Jetpack domains from blocking.

Step 6: Last resort HTTP fallback constant

In some hosting setups, HTTPS between your server and WordPress.com simply does not work correctly. For example, a shared SSL layer that you cannot control.

Jetpack has a low level option that forces it to use plain HTTP for its internal calls from your site to WordPress.com.

This is less secure because the traffic between your server and WordPress.com is no longer encrypted. Only consider it as a temporary workaround while you or your host fix the real SSL issue.

If you still want to try it:

1. Open your site files in FTP or in your host file manager.
2. Edit wp-config.php in the WordPress root.
3. Above the line that says /* That's all, stop editing */ add:

define( 'JETPACK_CLIENT__HTTPS', 'NEVER' );

1. Save the file.
2. Visit Jetpack → Dashboard and see if the error changes or Jetpack connects.

Only leave this constant in place if you understand the security trade off. It is better to keep HTTPS working correctly if you can.

What to send to your hosting provider

If you are still stuck, send your host a focused ticket.

Include:

• The exact Jetpack message: Outbound HTTPS not working. Your site could not connect to WordPress.com via HTTPS.
• Confirmation that your WordPress and Site Address URLs both use https://.
• Any cURL error text from Site Health or from debug logs. For example “cURL error 60 SSL certificate problem”.
• The results of any curl tests they ran to WordPress.com and public API endpoints.

Ask them clearly to:

• Fix your SSL certificate or chain if any issue exists.
• Enable or fix PHP cURL and OpenSSL support.
• Allow outbound HTTPS to WordPress.com and Jetpack endpoints on port 443.
• Whitelist Jetpack IP ranges if their firewall needs explicit allow rules.

Once they confirm those items are good, Jetpack usually connects without further changes.

Verification checklist

You are in good shape when:

• Jetpack no longer shows “Outbound HTTPS not working” on its dashboard.
• Jetpack features like Stats and backups load without connection errors.
• Your site loads over https:// with no browser certificate warnings.
• Site Health no longer reports HTTPS or cURL errors for outgoing requests.

Still stuck?

For AI help

Hit Continue Chat below and tell me what you and your host have tried so far. Include any cURL error messages or firewall notes. I will help you translate those into concrete steps that your host or developer can apply.

For expert human help

Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.