WordPress 4.4 has just been released and it is highly recommended to update. BUT it is broken on many servers. The update will go OK but it will also update the SSL certificate bundle that WordPress uses to update itself, the themes and plugins. The certificate bundle appears to be damaged or incorrect and stops any WP updates
Update 7 January 2016: Word press updated to 4.4.1 last night and exactly the same thing has happened, with the same “SSL certificate problem: unable to get local issuer certificate” error messages
You will get a message saying http_request_failed: “SSL certificate problem: unable to get local issuer certificate” whenever you try to do anything involving WordPress updates, updating or installing themes or plugins or using Jetpack features like stats or sharing etc.
You can also get this error with many other plugins that use SSL to communicate for functionality like sending emails or even posting to twitter or Facebook etc. . Mailchimp is one that comes to mind. You also get this problem with Jetpack and the stats feature ( and probably every other jet pack option ) However you won’t see any SSL error messages like the screen shots shown, just get a warning saying something like “We were unable to get your stats just now. Please reload this page to try again”
The error screen will look something like this. It doesn’t matter what plugin or theme you try to update. the error message will be similar
I did a bit of searching and found this post on WordPress support that does fix the problem. All my WP sites gave me the SSL warning until I used the certificate bundle from that post
http://curl.haxx.se/ca/cacert.pem is a copy of the Mozilla open source ca certificates so are perfectly safe and legitimate. if you right click the link & select save as. You can save the pem as ca-bundle.crt. Save it to a safe place on your computer, say desktop or downloads folder. Then upload to your wp-includes/certificates/ folder and overwrite the existing ca-bundle.crt. It doesn’t matter what server you are running WP on, the certificates that WordPress uses will be inside the wp-includes/certificates/ folder. Some servers will be able to bypass the WordPress included certificates and use the ones bundled inside OpenSSL or PHP/Curl when the WordPress ones fail. But for simplicity and convenience replace the WordPress ones with the ones from the link. Only WordPress will use them not any other program on your server
Go to http://curl.haxx.se/ca/cacert.pem and save it as ca-bundle.crt
Upload this file to: wp-includes/certificates/ca-bundle.crt
Remember that any update WordPress does will overwrite this. So until WordPress fixes/updates themselves, you should manually do this yourself.
I wish WordPress could send out a hotfix of some sort now to make this update. Updated certs is very important for security and communication between sites.
Edit: You are better off using the HTTPS link on http://curl.haxx.se/docs/caextract.html and select the github https link. That way it is already named as ca-bundle.crt & you just need to upload it to your wp-includes/certificates/ folder and overwrite the existing ca-bundle.crt
I had to replace the WordPress installed ca-bundle.crt on 10 sites that I manage in the last half hour after updating to WordPress 4.4 and I am not a happy bunny
WordPress fix your error & fix it NOW !!!. Lots of users are complaining
The problem occurs because WordPress has followed “best practice security guidelines” and removed RSA-1024 certificates from its certificate bundle.
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.)
From what I can find out this seems to be a particular problem on CentOS 5 servers using cpanel. It is almost certainly related to the Openssl version that Cpanel use which is stuck on 0.98.x rather than the newer 1.x.x versions that come with newer server OS versions. However CentOS 5 is still supported and in very common use in hosting companies and dedicated servers.
There is a discussion about this on http://stackoverflow.com/questions/29943932/curl-php-ssl-unable-to-verify-server-side-but-not-always which explains the full technical reasons for this and why the millions of users that have older but still supported server OS. OpenSSl cannot be updated on these servers
The removed certificates where old Root-CA with only a 1024bit key. These certificates somehow got replaced with newer certificates, but not on the same place, i.e. if you often have multiple possible trust path:
host-cert -> intermediate.1 -> 2048bit intermediate.2 -> 1024bit root-CA host-cert -> intermediate.1 -> 2048bit new root
The public key of the
2048bit new rootis the same as the one of the
2048bit intermediate.2, so the signature for
intermediate.1will still match so that chain validation will succeed. But, while most TLS stack try to find the best chain OpenSSL insists of the longest chain. This means if the server sends the chain
host-cert -> intermediate.1 -> 2048bit intermediate.2
then OpenSSL will insist on finding a root-CA signing
intermediate.2, even if it has a root-CA signing
2048bit new root). If the old
1024bit root-CAis no longer in the trust store the validation will fail. If instead the server sends only
host-cert -> intermediate.1
then the validation will succeed with the
2048bit new root. But lots of servers will still send the longer chain to maintain compatibility with older clients which don’t have the
2048bit new root.
All very ugly and the bug was reported in 2012 and again in 2015. OpenSSL 1.0.2 (fresh released) has at least an option
X509_V_FLAG_TRUSTED_FIRSTto work around the problem and there are changes in OpenSSL git which seem to fix the issue but it is not clear if they get every backported to 1.0.2 or lower 🙁
For now you better just keep the old 1024bit certificates in the trust store.