[wp-trac] [WordPress Trac] #63876: Certificate verification failure causing PHP 8.3 and 8.4 workflows to fail
WordPress Trac
noreply at wordpress.org
Thu Sep 4 20:02:22 UTC 2025
#63876: Certificate verification failure causing PHP 8.3 and 8.4 workflows to fail
-------------------------------------+---------------------
Reporter: johnbillion | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.9
Component: Build/Test Tools | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-testing | Focuses:
-------------------------------------+---------------------
Changes (by desrosj):
* keywords: has-patch => has-patch needs-testing
* milestone: Awaiting Review => 6.9
Comment:
Today a working meeting took place in the form of a Slack Huddle in the
#core-build-test-tools channel
([https://wordpress.slack.com/archives/C08D0Q6BHNY/p1757001596202369 full
thread]). In attendance was @desrosj, @johnbillion, @jorbin, and
@davidbaumwald. The intention was to record the huddle, but it seems that
is not supported by Slack.
Instead, here are some notes, and the
[https://wordpress.slack.com/archives/C08D0Q6BHNY/p1757001596202369 full
thread can be found in Slack].
== Understanding so far
The upstream official Docker PHP images were recently updated, switching
the Debian base image reference from `bullseye` to `trixie`. This change
[https://github.com/docker-
library/php/commit/686f9529f8659f929509a2c3ec2df34a14a4594a happened on
August 7th], and these [https://github.com/docker-
library/php/actions/runs/17014582658 updated images were published on
August 26th].
The workflow that publishes the wordpressdevelop images to Docker Hub
began [https://github.com/WordPress/wpdev-docker-
images/actions/runs/16243572424 failing on July 12th] due to the Debian 10
packages being moved to the archive (this was fixed in
[https://github.com/WordPress/wpdev-docker-images/pull/173 PR-173]).
Because `fail-fast` is set to `true`, no containers were published from
July 12th to August 23rd when PR-173 was merged.
At that point, the upstream base image change began flowing into the local
environment containers maintained by WordPress.
The MySQL/MariaDB containers auto-generate a self-signed certificate when
they are spun up for the first time. Something related to the change of
the underlying version of Debian is changing the expectations of the SSL
certificate chain.
== Some additional things that have been tried
The following approaches have been explored thanks to varying levels of
input from different AI models, however they did not fix the issue fully
or at all.
- Using a script to generate a certificate set locally using a trusted
certificate authority, mounting the certificates to the appropriate places
within the database containers, and telling the database to use those
certificates.
- Downloading the relevant details about the auto-generated
certificate/certificate authority from the database container and
attempting to add the CA to the CLI container's trust store.
- Using a script to generate a certificate set using a locally generated
certificate authority before mounting to the database container and adding
the CA to the trust store for both the database and CLI containers.
== Questions explored during the call
=== What changed in the new trixie base container vs. how it was
previously in bullseye?
As expected, a [https://www.debian.org/releases/ lot changed between
Debian 11 (bullsey) and 13 (Trixie)]. This felt too broad to begin the
search.
==== Can different base images be used?
While the images based on bullseye were removed, the images based on
Debian 12 (bookworm) still remain. A [https://github.com/WordPress/wpdev-
docker-images/pull/183 PR to the wpdev-docker-images repository] was
opened to specify Debian 12 (bookworm) as the base image to see if the
problem was present. The bookworm-based images did not have the same
issue, so the change causing the issue can be narrowed down further to
between Debian 12 and 13.
==== Are the versions of OpenSSL different? And how do they differ? Could
possibly be changing how strict the certificate chain must be.
Yes, the versions of OpenSSL were wildly different.
==== Does the failure also happen in PHP 8.5?
Yes the same issue happens in the `wordpressdevelop/php:8.5-fpm` images.
==== Which versions of Docker's official PHP images would be affected by
this
The change to the underlying base image was made to the PHP 8.1-8.5
containers. So any of these versions should see the problem.
==== Why is the problem only surfacing in PHP 8.3 and 8.4?
Docker only seems to publish updates to PHP images when there is a change
in the PHP version being included. Because [https://www.php.net/supported-
versions.php 8.1 & 8.2 are now only receiving security support], no
changes have been made to the underlying PHP version for these images
since the version of Debian was changed. However when (if) a security
update is published for 8.1 and 8.2, new versions of the containers will
be published and the issue would have presented for those versions.
== Observations
The issue is only happening in the `cli` container and not the `php` one,
despite both containers interacting with the `mysql` container. The `cli`
image has the `virtual-mysql-client` installed while the `php` one does
not.
As noted earlier in the ticket, `mysql --version` outputs the following
within the `cli` container: `mysql from 11.8.2-MariaDB, client 15.2 for
debian-linux-gnu (x86_64) using EditLine wrapper`. Before the failures
began, the `wordpressdevelop/cli` image shipped with `mysql Ver 15.1
Distrib 10.11.11-MariaDB, for debian-linux-gnu (x86_64) using EditLine
wrapper`.
Looking into this further, it appears that [https://mariadb.com/docs
/release-notes/community-server/mariadb-11-4-series/what-is-mariadb-114
#ssl-tls MariaDB 11.4 included several changes to how SSL connections and
certificate verification is handled]. Notably:
- SSL is now enabled in the server by default.
- Clients now require SSL and have `--ssl-verify-server-cert` enabled by
default ([https://jira.mariadb.org/browse/MDEV-31857 MDEV-31857]).
- Use `--disable-ssl` or `--disable-ssl-verify-server-cert` to revert to
the old behavior.
This caused connections from the MariaDB client (always the same, even if
connecting to a MySQL container because the client is installed within the
`wordpressdevelop/cli` container) to the WP-CLI container because the
certificate chain is no longer allowed to contain a self-signed
certificate.
After some trial and error, instructing the MariaDB client to use `ssl=0`
fixes the issue, however [https://github.com/wp-cli/db-
command/blob/b2a51db6c2312b1666835a199e181083cae73b1b/src/DB_Command.php#L2083-L2104
WP-CLI uses the `--no-defaults` flag for `wp db` commands], which causes
this config value to be ignored and the commands to continue to fail.
Therefore the `--defaults` flag needs to be used when calling `wp db`
commands.
The recent issues with the `memcached` container proved to be unrelated to
the SSL issues. They were solved by [https://github.com/WordPress/wpdev-
docker-images/pull/181 wpdev-docker-images#181]. Adding `memcached` jobs
back to the test matrix resulted in those jobs passing.
In order to experience the original certificate chain issue, someone must
be using the `wordpressdevelop/cli` Docker image OR an image with a mysql
client running `11.4.1-MariaDB` or higher AND relying on the default auto-
generated certificate within the database container OR implementing a
custom SSL cert that was not issued by a trusted certificate authority.
A side effect of this fix is that the
`Tests_Image_Editor_Imagick::test_resizes_are_small_for_16bit_images` and
`
Tests_Image_Editor_Imagick::test_png_color_type_is_preserved_after_resize`
test methods are now failing for an unknown reason. The plan is to
temporarily skip these when the test suite runs on PHP >= 8.1 until the
cause can be determined. The tests are not completely disabled because
they will run on PHP 7.2-8.0.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/63876#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list