Sorry, we can't switch this site to ClassicPress at this time

During an attempt to migrate with migration plugin 1.4.1 from WP 4.9 to CP:

“Could not communicate with the ClassicPress API server {“status”:“cURL error 60: SSL certificate problem: certificate has expired”}”

Do you see any problems on the CP server side?

It’s a trouble with the server (the one that tries to communicate with ClassicPress API server). Root certificates are not updated.
Even if you can migrate you’ll have issues with future updates, dashboard and plugin updates.

I’ve solved this issue in a very bad way, but it’s on an internal test server, just forcing cURL not to check certificates. This gist is a mu-plugin that does the thing.

1 Like

This also causes issues (with cURL) on localhost. I tried a cURL request with PHP 7.1.33, 7.2.25, 7.3.12, 7.4.11 – of these, only 7.1.33 was affected by the certificate issue. In the case of 7.1.33, I applied the same fix Simone mentioned above, but, as he implied, it’s not a good way. We’ll have to wait until new certificates are issued (I guess) for this issue to be fully resolved.

More Info

The new cartificate is already issued but not present in old systems. I’ve unsuccessfully tried to add the new certificate on osX 10.11. :cry: Think the problem is that openssl is old.

The certificates are already issued, nobody will be fixing this externally.

The best fix I know of is to get in touch with your server provider and get them to upgrade PHP and its components (possibly the web server software also) until it works again. I’m not entirely clear on what component specifically needs to be upgraded, but getting everything onto the latest version fixes this issue.

There is also apparently another way to fix it, that involves manipulating the certificates that are trusted by your web server, but again, this is a task for your hosting provider to do.

Updating PHP wont fix it, PHP uses the root certs installed on your OS, typically you have to update the openssl and ca-certificates packages. This is what we have been handing out as a workaround:
add_filter( 'https_ssl_verify', '__return_false' );

WP are updating the cert bundle for 5.8.2 to remove the old cert. You might want to backport this one @james #54207 (ca-bundle.crt contains expired certificate DST Root CA X3) – WordPress Trac


Firefox ships with and uses its own Trusted Certificate Store, so, I figured an update might possibly fix the issue on this end. I updated, no dice. However, Edge is also complaining about the expired cert, so, I’m about to update Windows (which I’ve been putting off for 2 weeks already.) Hopefully they added the new certs to the update. I’ll report back when I know.

Edit: Nope. Issue persists with local PHP 7.3.11. Totally fine on my other PHP 7.x installs.

Updating PHP did fix this issue on a couple of my servers. These are using the PHP packages from, maybe they did something specific to fix it.

I’ve seen that you can check the version of openssl to see if a server is affected, but this has not been working clearly for me. I have seen OpenSSL 1.1.x not working even though it is supposed to work, and OpenSSL 1.0.x working even though supposedly it should not work.

In any case “update everything related to the web server” seems to be good advice.

I wouldn’t recommend this - it leaves sites vulnerable to some kinds of attacks based on impersonating the update server.

Will look into this, thanks.

On a test site with the issue, applying the patch was an insta fix

1 Like

This looked promising, but unfortunately it is not fixing the issue for the site I am testing on.

You should probably let the WP people know

1 Like

I did:

I also started a PR to get this change into ClassicPress:

I’m all for including this, if it fixes the issue for some sites (based on your report it seems like that is the case). I would like to understand why it’s not working for me though.

OK, I figured it out.

Removing that certificate from ClassicPress’ certificate bundle is part of the fix. However, if a web server is using the cURL extension with an old version of OpenSSL, and the expired “DST Root CA X3” certificate is still present in the system certificate store, then this fix is not enough.

In that case the only ways to get these requests working again are to upgrade PHP/cURL, remove the certificate from the system certificate store, or disable certificate verification entirely.

I’ve created a small plugin that will diagnose and work around this situation in the most secure way possible:

There are three different modes it can operate in, depending on the web server configuration.

(1) Do nothing if the server is not suffering from this issue:

(2) Automatically use a corrected certificate bundle if this is an issue that ClassicPress can fix by itself:

This is a much better alternative than disabling all certificate verification.

For these sites, the issue will also be fixed once the PR above is merged and shipped in a new release of ClassicPress. This plugin will be able to help users of these sites to get that update applied.

(3) Provide the option to switch to insecure requests for a few minutes if there is no other solution. The real fix is to upgrade/reconfigure the webserver but this can help get upgrades and other tasks unblocked in the meantime:


I put your plugin on a client site I have running WP 5.2.12. I haven’t had any problem there.
My result doesn’t look like any of the ones you listed.

1 Like

Thanks. It looks like this site is not able to reach for some other reason (for example, we have seen hosts’ firewall rules prevent this a few times). There was a logic error for sites in this situation, and I’ve pushed an update to fix it. If you install the latest version from GitHub, you should now see a proper error message on that site:

It’s interesting that I put the new version of the plugin on the same site as before and I got the result 3 this time, with the button to Enable Insecure Requests. Did you also change something over at

Nope. The plugin is indicating that that site can’t make requests to unless certificate verification is disabled. Given that your site has a newer version of OpenSSL I’m not sure why that would be happening, but if the plugin is running all 3 of those checks then the result is probably correct.