[wp-trac] [WordPress Trac] #62711: `external-http` test failures in 4.1-4.5 branches

[WordPress Trac]

#62711: `external-http` test failures in 4.1-4.5 branches
--------------------------+---------------------
 Reporter:  desrosj       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  6.8
Component:  Security      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by mrsdizzie):

 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:
 {{{
 echo | 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.
 I think updating these warrants a release for all older versions, and
 shouldn't wait for a next security release.

 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"), // Print to stdout
     ]);
 }, 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62711#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform