Fix 'cURL Error 60: SSL Certificate Problem' in WordPress

You update a premium plugin, activate a license key, or try to check out through Stripe or Razorpay, and instead of the normal success message you get a wall of red: cURL error 60: SSL certificate problem: unable to get local issuer certificate or sometimes certificate has expired. The site itself loads fine over HTTPS, the padlock is green, so it's confusing that WordPress is complaining about SSL at all. Here's what's actually going on and how to fix it on cPanel hosting without touching a line of plugin code.

Why This Happens (and Why the Padlock Looks Fine)

There are two completely separate SSL stories on your server, and that's the part that trips people up.

One is the certificate your visitors' browsers check when they load your site — that's your Let's Encrypt or AutoSSL cert, and it's fine, which is why the padlock is green. The other is a bundle of root CA certificates that PHP's cURL library uses when your server reaches out to someone else's API — Stripe, a plugin's license server, Google, WooCommerce Payments, whoever. That bundle is a static file (commonly cacert.pem) sitting somewhere in your hosting environment, and unlike your site's own SSL cert, nothing auto-renews it. Root CAs expire and get replaced every few years (the DST Root CA X3 expiry in 2021 broke exactly this on thousands of shared hosting accounts). If the CA bundle on the server is old, PHP can't verify the chain when it calls out to a modern API, and you get error 60 even though every other part of SSL on the box is working perfectly.

Common triggers

• Plugin/theme license activation ("Invalid response from license server")
• WooCommerce/Stripe/Razorpay/PayPal API calls failing at checkout
• WP Mail SMTP or similar plugins failing to connect to Gmail/SendGrid APIs
• Any REST API call the site makes to an external service (weather widgets, maps, recaptcha verification)
• WordPress core/plugin update checks silently failing

If it were your site's own SSL certificate that was broken, visitors would see a browser warning. If only outbound calls are failing while the site itself loads fine over HTTPS, it's almost always the CA bundle PHP is using, not your site's certificate.

Step 1: Confirm It's Actually the CA Bundle

Turn on debug logging so you see the raw error instead of a plugin's generic "something went wrong" message. In wp-config.php, above the "That's all, stop editing" line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce the failing action (retry the license activation, retry checkout in test mode), then check wp-content/debug.log. If you see cURL error 60 anywhere in there, you've confirmed it. Turn WP_DEBUG back off once you're done — don't leave debug logging on in production.

If you have SSH access, you can confirm it even faster from the command line:

curl -v https://api.stripe.com 2>&1 | grep -i "certificate\|SSL"

A line like SSL certificate problem: unable to get local issuer certificate here is the same root cause — an outdated or missing CA bundle — just reached from a different door.

Step 2: The Shared-Hosting Fix (No Root Needed)

On shared cPanel hosting, you don't manage the server's CA bundle yourself — but you have two things you can do without opening a support ticket:

Option A — Ask us to run "Update Root Certificates" in WHM

This is a one-click server-level action on our end (WHM > Manage Root SSL Certificates > Update All Users). It refreshes the CA bundle cPanel installs into every account's PHP environment. If you're on SkyServer shared or reseller hosting and you hit this error, this is the first thing to ask support for — it fixes it for every account on the box in one pass, not just yours.

Option B — Point curl.cainfo at a fresh bundle yourself

If you have your own hosting package with file access, you can supply your own up-to-date bundle:

1. Download a current bundle: curl -o cacert.pem https://curl.se/ca/cacert.pem (run this from a machine where curl already trusts it, or download it via your browser and upload through File Manager)
2. Upload it somewhere outside your public web root, e.g. /home/yourusername/ssl/cacert.pem
3. In cPanel, go to MultiPHP INI Editor, select your domain, and add:

curl.cainfo = "/home/yourusername/ssl/cacert.pem"
openssl.cafile = "/home/yourusername/ssl/cacert.pem"

Save, then retest the plugin action. If the PHP handler is FastCGI/FPM, you may need to wait a minute or restart the PHP-FPM instance for your account (support can do this for you) before the new setting picks up.

Step 3: If You're on a VPS

With root access this is a package update, not a manual download:

After updating, confirm PHP is actually using the system bundle and not a stale one referenced in php.ini:

php -i | grep -i cainfo

If that line points at a custom path, that file is the one that's actually stale — update it or remove the override so PHP falls back to the system bundle you just updated.

Step 4: Rule Out the Usual False Positives

Before you conclude it's definitely the CA bundle, quickly check these — they produce a very similar symptom:

• Server clock drift. If your VPS's system time is wrong, certificate validation can fail even with a fresh bundle, since the cert's "not valid before/after" window gets checked against the local clock. Run date and compare to actual time.
• A firewall or outbound proxy silently blocking or intercepting the request before it reaches the API. Test with curl -v to the exact endpoint the plugin is calling.
• A security plugin stripping or modifying outbound request headers. Temporarily disable it and retest.

Prevention

You can't make root CA bundles stop expiring, but you can stop being surprised by it:

• If you manage a VPS, put ca-certificates in whatever unattended-upgrades/patch schedule you already run — it's a small, low-risk package to keep current.
• On shared hosting, if it's been over a year since your last "Update Root Certificates" pass, it's worth asking support to run it proactively rather than waiting for a checkout to fail.
• Keep WP_DEBUG_LOG instructions handy (or a logging plugin) so the next odd plugin failure gives you a real error message instead of a vague "something went wrong."

Frequently Asked Questions

Why does my site show a valid green padlock if the SSL certificate is the problem?

Because it's not your site's certificate that's broken — it's the separate bundle of trusted root certificates PHP/cURL uses to verify certificates on outbound connections to other services. Your visitors never touch that bundle; only your server's own outgoing API calls do.

Can I just disable SSL verification to make the error go away?

You can set CURLOPT_SSL_VERIFYPEER to false, and some plugins expose a "disable SSL verify" toggle, but this removes certificate validation entirely for that request — it's a security downgrade, not a fix, and we'd only ever suggest it as a five-minute diagnostic test, never as a permanent setting.

I updated the CA bundle and it's still failing — what next?

Check that PHP is actually reading the path you set — run php -i | grep cainfo or add a quick phpinfo() call to confirm. It's common to update php.ini for one PHP version while the site is actually running a different version selected in MultiPHP Manager.

Does this affect email sending too?

Yes, if you're using an SMTP plugin that connects to Gmail, Outlook, or SendGrid over an API rather than plain SMTP auth — those are also outbound HTTPS calls and hit the same CA bundle.

How often does the root certificate bundle actually need updating?

There's no fixed schedule, but expect it to matter every couple of years as major root CAs rotate. The safest approach is to update it whenever you see error 60 rather than trying to preempt every CA's individual expiry date.