#62711 closed defect (bug) (fixed)
`external-http` test failures in 4.1-4.5 branches
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 6.8 | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Security | Keywords: | has-patch |
| Focuses: | Cc: |
Description
A new test failure has started occurring in the 4.5 branch and earlier.
1) Tests_HTTP_streams::test_ssl stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed /var/www/src/wp-includes/class-wp-http-streams.php:150 /var/www/src/wp-includes/class-http.php:433 /var/www/src/wp-includes/class-http.php:342 /var/www/src/wp-includes/class-http.php:496 /var/www/src/wp-includes/http.php:170 /var/www/tests/phpunit/tests/http/base.php:387
On December 2, w.org switched to using Lets Encrpyt, which seems to be causing the problem.
Change History (36)
This ticket was mentioned in PR #8019 on WordPress/wordpress-develop by @desrosj.
4 months ago
#2
- Keywords has-patch added
Trac ticket: https://core.trac.wordpress.org/ticket/62711
#3
@
3 months ago
So maybe some of those certificates expired? It makes sense to me to keep that certificate list updated everywhere, considering these branches still receive security updates.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
3 months ago
#5
@
3 months ago
@swissspidy After looking at this more, I agree. I opened #62811 to update the certificate bundle for 6.8, and #62812 to make it easier to update this in the future.
I think after the updates in #62811 are merged, those should be backported along with [48707] to the older branches and shipped in the next security release (when and if that happens).
#7
@
6 weeks ago
- Focuses tests removed
Removing the tests focus as this will require changes to the bundled certificate file and is not isolated to test files.
#9
@
6 weeks ago
I experienced this too while trying to set up testing for WordPress 4.9 locally so it isn't limited to 4.1-4.5. The specific details of the problem are
wordpress.org has a SSL certificate like:
openssl s_client -showcerts -connect api.wordpress.org:443 | openssl x509 -noout -issuer -subject -dates Connecting to 198.143.164.251 depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1 verify return:1 depth=1 C=US, O=Let's Encrypt, CN=E5 verify return:1 depth=0 CN=wordpress.org verify return:1 DONE issuer=C=US, O=Let's Encrypt, CN=E5 subject=CN=wordpress.org notBefore=Jan 31 19:43:55 2025 GMT notAfter=May 1 19:43:54 2025 GMT
The direct certificate wordpress.org has is an intermediate certificate from lets encrypt
depth=1 C=US, O=Let's Encrypt, CN=E5
Which chains up to this root certificate
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
Lets encrypt made this to start using ISRG Root X1 as the root certificate in April of 2024: https://letsencrypt.org/2024/04/12/changes-to-issuance-chains/
The ISRG Root X1 root certificate was not added to WordPress core until https://core.trac.wordpress.org/changeset/46094 in 2019 (around WordPress 5.1 ?). So older versions of WordPress can't verify the SSL connection to wordpress.org because they are missing the ISRG Root X1 root certificate.
This caused a problem for me on MacOS because of the way OpenSSL is set up. On a debian linux install it still works because:
$ wp eval '
add_filter("http_api_curl", function($handle, $r, $url) {
$options = [];
curl_setopt_array($handle, [
CURLOPT_VERBOSE => true, // Log details
CURLOPT_STDERR => fopen("php://stdout", "w"),
]);
}, 10, 3);
var_dump(wp_remote_get("https://api.wordpress.org/plugins/update-check/1.1/"));
'
* Trying 198.143.164.251:443...
* Connected to api.wordpress.org (198.143.164.251) port 443 (#0)
* ALPN: offers http/1.1
* CAfile: /var/www/html/ex/example.com/oldwp/wp-includes/certificates/ca-bundle.crt
* CApath: /etc/ssl/certs
Specifically that CApath: /etc/ssl/certs is set. On MacOS, this was not the case, so it had no fallback to a system certificate store. I'm not 100% sure on how/why openssl is compiled differently across different systems, but it explains why some systems might see this issue and others don't.
#35
@
5 weeks ago
- Owner set to desrosj
- Resolution set to fixed
- Status changed from new to closed
In 60029:
I'm not quite sure exactly why the failure is occurring yet, but applying [48707] to the branches fixes the problem.
It's also possibly related to https://letsencrypt.org/2024/03/19/new-intermediate-certificates/.