Update the bundled Root SSL Certificate file

[dd32]

Previously: #27017

In #25007 we added a static set of root certificates for usage with WP_HTTP as hosts certificates were often out of date.
In order for us to not end up in the same boat, we need to keep our certificate file up to date.

Commands run to generate:

wget https://raw.githubusercontent.com/bagder/curl/master/lib/mk-ca-bundle.pl
chmod +x mk-ca-bundle.pl
./mk-ca-bundle.pl src/wp-includes/certificates/ca-bundle.crt

I then manually applied r25569 by moving that same certificate higher in the file.

This is using the Mozilla "release" set of certificates (the list included with the latest stable Mozilla release).
The NSS certificates are tracked through ​the Mozilla BugZilla.

[dd32]

Commit missed the ticket.

[30491]
Update the bundled root CA's used for outgoing HTTPS requests.
Fixes #30434

A bunch of certificates have been removed, which appear to be the old 1024 bit certificates, which hasn't been sold since 2013 and browsers have been removing trust for the certificates since September.

[SergeyBiryukov]

I see errors in WordPress News dashboard widget in trunk, which appears to be related to this change:

WP HTTP Error: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Also a lot of "WordPress could not establish a secure connection to WordPress.org" errors on the Updates screen.

No errors on 4.0.1 in the same environment (Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8e PHP/5.2.17).

[dd32]

I see errors in WordPress News dashboard widget in trunk, which appears to be related to this change:

Can you verify if this happens with both the Streams and cURL transports? Can you verify that the wp-includes/certificates/ca-bundle.crt file is clean without svn conflicts?

I don't have a PHP 5.2.x server at present, but am going to try setting up a VM for it now.

[dd32]

The good news (or bad news?) is that I can't duplicate with a PHP 5.2 VM, although it's entirely possible it's related to your config.

I've tested with:

• PHP 5.2.17-0.dotdeb.0
• libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
• OpenSSL 0.9.8g 19 Oct 2007

[SergeyBiryukov]

Replying to dd32:

Can you verify if this happens with both the Streams and cURL transports?

Correct, tested with Core Control plugin.

With cURL, I get a lot of "WordPress could not establish a secure connection to WordPress.org" errors on the Updates screen.

With Streams, I get this:

Warning: stream_socket_client() [function.stream-socket-client]: SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in wp-includes/class-http.php on line 1006

Warning: stream_socket_client() [function.stream-socket-client]: Failed to enable crypto in wp-includes/class-http.php on line 1006

Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://api.wordpress.org:443 (Unknown error) in wp-includes/class-http.php on line 1006

Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in wp-includes/update.php on line 295

Can you verify that the wp-includes/certificates/ca-bundle.crt file is clean without svn conflicts?

The file is clean, no conflicts.

[dd32]

Okay, so basically the error means that OpenSSL cannot find a valid root certificate which authenticates the api.wordpress.org cert.

This is a re-occurence of r25569 / #25007:46

This probably means there's a certificate in the new additions at the bottom of the file that the older openssl chokes on, removing some of those certs, or re-ordering them, will help track down which cert is causing the trouble.

I guess we'll have to revert this for 4.1 if we can't track down the cause this time.

[dd32]

Recommending reverting for 4.1, adding immediately to 4.2-alpha (or if we branch 4.1 prior to release, reverting in said branch).

The risk of breaking HTTPS communication has worse consequences than a newly-released cert not being trusted (which most browsers wouldn't yet trust either), or a old cert being trusted when browsers won't (ie. 1024bit signed certs, which might still be in the wild).

[dd32]

In 30765:

WP_HTTP: Revert r30491 which updated the bundled root certificates. There's a report that this is breaking under certain PHP/OpenSSL versions (which we've encountered before), and we're safer with a slighty out of date CA bundle than breaking HTTPS communication on affected sites.
See #30434

[obenland]

No movement in 4.3, maybe in a future release.

[aaroncampbell]

I think we need to look at this again. The number of certificates using newer roots that WP is missing is growing. People are starting to have to turn off verify peer again (just recently had to myself). 30434.diff​ pulls the ​certs from mozilla and moves the EE cert to the top.

As an alternative, could we just add the new ones without removing the old ones? I mean, I don't want to collect them forever, but not adding the new ones doesn't seem like a reasonable solution either.

[dd32]

As an alternative, could we just add the new ones without removing the old ones? I mean, I don't want to collect them forever, but not adding the new ones doesn't seem like a reasonable solution either.

I don't think that'll fix the cause for the revert originally. The original reason for the EE cert being higher in the file, is that OpenSSL couldn't parse the file (for a still unknown reason). The reason it was reverted again here though, isn't clear, it broke, but we have no idea why.

We should update it, but we really need people to test it against every old environment they have access to.
I'll commit the latest certs in the next 24hrs and see what explodes.

[rmccue]

Replying to dd32:

I don't think that'll fix the cause for the revert originally. The original reason for the EE cert being higher in the file, is that OpenSSL couldn't parse the file (for a still unknown reason). The reason it was reverted again here though, isn't clear, it broke, but we have no idea why.

What version of OpenSSL was this with? I might try digging through the source to see if I can work it out.

[dd32]

Replying to rmccue:

What version of OpenSSL was this with? I might try digging through the source to see if I can work it out.

Original or the 10 month old revert?
See 2 & 5 for the latest revert cause. ticket:25007:46 for the original stuff.

[dd32]

In 34283:

HTTP: Update the Root Certificate bundle.

See #30434

[dd32]

List of removed/added certificates, generated by svn diff src/wp-includes/certificates/ca-bundle.crt | grep '^[-+][^-]\+ .\+'

Removed:
-AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.
-America Online Root Certification Authority 1
-America Online Root Certification Authority 2
-Entrust.net Secure Server CA
-Equifax Secure eBusiness CA 1
-Equifax Secure Global eBusiness CA
-Firmaprofesional Root CA
-GTE CyberTrust Global Root
-NetLock Business (Class B) Root
-NetLock Express (Class C) Root
-RSA Root Certificate 1
-TC TrustCenter Class 3 CA II
-TDC Internet Root CA
-Thawte Premium Server CA
-Thawte Server CA
-ValiCert Class 1 VA
-ValiCert Class 2 VA
-Verisign Class 3 Public Primary Certification Authority
-Verisign Class 3 Public Primary Certification Authority
-Verisign Class 3 Public Primary Certification Authority - G2

Added:
+Atos TrustedRoot 2011
+CFCA EV ROOT
+COMODO RSA Certification Authority
+DigiCert Assured ID Root G2
+DigiCert Assured ID Root G3
+DigiCert Global Root G2
+DigiCert Global Root G3
+DigiCert Trusted Root G4
+Entrust Root Certification Authority - EC1
+Entrust Root Certification Authority - G2
+GlobalSign ECC Root CA - R4
+GlobalSign ECC Root CA - R5
+IdenTrust Commercial Root CA 1
+IdenTrust Public Sector Root CA 1
+QuoVadis Root CA 1 G3
+QuoVadis Root CA 2 G3
+QuoVadis Root CA 3 G3
+Staat der Nederlanden EV Root CA
+Staat der Nederlanden Root CA - G3
+TeliaSonera Root CA v1
+USERTrust ECC Certification Authority
+USERTrust RSA Certification Authority
+WoSign China

[dd32]

#26955 was marked as a duplicate.

[swissspidy]

#34382 was marked as a duplicate.

[dd32]

Marking as resolved for 4.4 pending no final breakage reports.

[DvanKooten]

Could it be that this change is causing issues? The update to WordPress 4.4 introduced a ton of error reports by users telling me that SSL certificate verification failed when connecting to any site over SSL.

Telling WP_HTTP to skip SSL verification gets rid of the errors.

​https://wordpress.org/support/topic/error-connecting-to-mailchimp-ssl-certificate-problem
​http://myonlinesecurity.co.uk/wordpress-4-4-update-breaks-itself-with-ssl-certificate-problem-unable-to-get-local-issuer-certificate/

[dd32]

See #34935 for discussion of incompatible curls as a result of this change.

[webdevelopment]

I was told this would be fixed in 4.4 1 month ago, but I just installed version 4.4 and was hoping to see a fully functioning Wordpress, but I get the same SSL error because WP (you all) aren't using the right cacert.pem file.

PLEASE FIX THIS!!! THERE ARE PEOPLE ALL OVER THE INTERNET COMPLAINING ABOUT THIS BUG.

I WAITED 1 WHOLE MONTH FOR NOTHING TO BE FIXED!!!

[swissspidy]

@webdevelopment Please calm down. As you can see from the notes above, there were no breakage reports during RC.

It took a lot of time to investigate any bugs with SSL certifcates. A fix got committed yesterday, see #34935. it will land in 4.4.1.

[dd32]

In 36570:

HTTP API: Certificate bundle: Attempt to move a certificate lower in the file to allow older OpenSSL versions to parse it & communicate with WordPress.org securely again.
The OpenSSL version which was failing in this case was OpenSSL 0.9.8e 23 Feb 2007.

See #35637 #30434 #25007