We are checking but it might be harder than it sounds. That is tied to the OS distribution so we are checking the version we are using now. We have a pretty standard distribution.. Will see what we can do.

I feared this would come up again.. Unfortunately the curl cacert bundles are seemingly sometimes incompatible with older versions of curl for an unknown reason.. It's a bug deep within curl (possibly fixed at some point) which I don't think we can easily work around.

Can everyone please include details of the curl version, openssl version (or whatever ssl library curl is using) AND the php version affected.

And to clarify, I don't think it's the removal, rather the adding or reordering of certs. We had this issue before, and were able to fix it by moving one certificate to the start of the file, it's trial and error to find which one though.

Recently, Mozilla has started to cleanup the Mozilla CA trust list and
remove CA certificates that use a weaker 1024-bit RSA key. I'll call
them legacy CAs.

When upgrading the trust store used by openssl to exclude the legacy CA
certificates, by default, openssl (e.g. s_client) can no longer verify
the server certificate of several popular SSL/TLS servers, examples are
www.flickr.com and www.amazon.com.

The cURL page for the certificate bundle also mentions this:

RSA-1024 removed

Around early September 2014, Mozilla removed the trust bits from the certs in their CA bundle that were still using RSA 1024 bit keys. This may lead to TLS libraries having a hard time to verify some sites if the library in question doesn't properly support "path discovery" as per RFC 4158. (That includes OpenSSL and GnuTLS.)

​This file is linked as the last version built from the NSS store before they started removing these certs.

Me: Alternatively, you can replace the wp-includes/certificates/ca-bundle.crt file with the one I attached. Please make a copy of the original one first. If you're on 4.4, this file should fix the issue. Let me know whether it does or doesn't.

Customer: OK, so that fixed the SSL error.

Another feedback:

Good news, i have updated to wo 4.4 applied the new certificate and all working now.

Exact steps i followed were:

Deactivated all plugins
Performed the wp automated updated.
Then replaced the ca-bundle.crt with the new one u gave
Next activated woo commerce
Made a dummy purchase -- All worked
Next activated subscriptions
Made a dummy purchase -- All worked
Activated all other plugins
Made a dummy purchase -- All worked
Deactivated plugin- Temporary SSLverify Disable for WooCommerce Subscriptions (sets sslverify to false)
Made a dummy purchase -- All worked

So that is very good news indeed - thanks for your help in solving that

Adding automated testing of different versions of cURL and OpenSSL with WordPress using HTTPS to connect to remote URLs, like an API, would help avoid these issues in the next release. Using the test results to allow WordPress to detect incompatible versions of cURL and OpenSSL on the server, and warn the WordPress admin to have their host update cURL or OpenSSL, would provide admins actionable feedback, so they can solve their own issue, even if the ca-bundle.crt isn't perfect.

Adding automated testing of different versions of cURL and OpenSSL with WordPress using HTTPS to connect to remote URLs, like an API, would help avoid these issues in the next release. Using the test results to allow WordPress to detect incompatible versions of cURL and OpenSSL on the server, and warn the WordPress admin to have their host update cURL or OpenSSL, would provide admins actionable feedback, so they can solve their own issue, even if the ca-bundle.crt isn't perfect.

Following feedback from users who had this problem and we asked them to update openssl and / or curl, they came back with that being fairly hard, as they're part of the server distribution they used.

One of them provided feedback from the host: they updated to 1.0.2, but php did not pick that change up. It's a lot easier to bundle a working ca-bundle.crt than asking hosts to update their openssl.

Absolutelly agree with @javorszky: people using shared hosting will be trapped in a cage because vast majority of hosting providers are not able/willing to upgrade their OS or templates due to just a few shared hosting customer complaints.

Hosting provider input here: Very standard cPanel shared hosting environment, running CentOS 6.7 OS with yum updates, as well as cPanel updates, every night. OpenSSL reports as version "1.0.1e-fips" but has backported patches (the most recent being June 23, 2015).

We had one customer running WooCommerce get bit by this ca-bundle issue. Specifically, a paid plugin for the Elavon payment gateway (purchased from WooCommerce, now owned by Automattic) generating 500 errors. WooCommerce tech support blamed our server configuration and suggested we "reinstall OpenSSL and Curl". I did not do that... however, after I updated ca-bundle.crt, the problem was immediately corrected.

If Automattic thinks this issue is a shared-hosting provider problem, then they should immediately contact cPanel tech support. There are likely hundreds of thousands of web servers set up exactly like ours, in this very standard shared hosting configuration.

Adding automated testing of different versions of cURL and OpenSSL with WordPress using HTTPS to connect to remote URLs, like an API, would help avoid these issues in the next release.

It is a huge amount of effort to test different cURL and OpenSSL versions (as various versions need to be used); finding and verifying this bug took me ~4 hours, even using git bisect. Thankfully, this issue turned out to be an easy one caused by OpenSSL itself, which meant I only needed to rebuild OpenSSL and use the command line client openssl s_client; if this was caused by OpenSSL and cURL (or worse, PHP cURL) having issues together, it could have taken days just to find the issue.

Testing every version of cURL and OpenSSL that's available isn't something we can do, which is why it's important for people to test release candidates.

We do monitor changes in the bundle, which is what caused this issue in the first place. The key of the issue is that Mozilla has decided to remove 1024 bit root certificates from their root (that bundle file is generated from it). Mozilla's software and infrastructure uses NSS (a different SSL library) that can handle alternate chains; OpenSSL 1.0.1l was the first version to introduce this to OpenSSL.

Monitoring the upstream changes isn't enough when we also need to have compatibility with years old versions of OpenSSL.

Hosting provider input here: Very standard cPanel shared hosting environment, running CentOS 6.7 OS with yum updates, as well as cPanel updates, every night. OpenSSL reports as version "1.0.1e-fips" but has backported patches (the most recent being June 23, 2015).

It may be worth reporting this to CentOS, since 1024 bit root certificates are going away eventually. This is going to break certificates that rely on alternate chains. We will endeavour to keep supporting this, but I wouldn't be surprised when other software starts breaking too.

Therefore: I believe we should be able to take our existing bundle, and pull the 1024 bit certificates back in.

Attaching patched version of the CA bundle that adds the 1024 bit certificates back; this fixes resolution for me via OpenSSL on the command line, but needs testing on a site that's broken.

I agree with this direction. With an explicit mention in the commit (and file if possible) specifically explaining why we're including no-longer-trusted-by-browser roots.

If there's any way of automatically generating the crt file for future maintenance that would also be grand. I'm thinking that even just pulling the latest NSS store + suffixing the 1024bit certs may be enough. Also worth noting is that we now need to monitor the status of these root certs, we've relied upon NSS to do that in the past, but since they no longer trust the certs, if one of them is compromised we'll need to be aware of it somehow.

Most browsers no longer trust 1024bit certificates, or certificates signed by them, instead verifying them by a trusted intermediate or a cross-sign from another trusted certificate.

Unfortunately, as it turns out, OpenSSL prior to 1.0.1g cannot correctly handle certificates chains such as this, even if one of the intermediates is trusted.
The solution is that we need to continue to trust the 1024bit legacy root certificates forthe foreseeable future

Most browsers no longer trust 1024bit certificates, or certificates signed by them, instead verifying them by a trusted intermediate or a cross-sign from another trusted certificate.

Unfortunately, as it turns out, OpenSSL prior to 1.0.1g cannot correctly handle certificates chains such as this, even if one of the intermediates is trusted.
The solution is that we need to continue to trust the 1024bit legacy root certificates forthe foreseeable future