Gecompromitteerde eMudhra-tussen-CA-sleutels: wat PHP-servers moeten controleren

Wat er gebeurde

• Op 17 oktober 2026 meldde een onderzoeker dat acht eMudhra-tussencertificaten (zes TLS, twee codeondertekening) P-384-sleutels hadden die gehele getallen onder 256 waren: 4, 56, 66, 115, 155, 156, 230 en 237. Mozilla bevestigde dat elke sleutel op de laatste byte na uit nullen bestond (Bugzilla 2083449).
• Volgens eMudhra komen de sleutels uit een sleutelceremonie op 30 april 2025 met HSM’s van FIPS 140-2 niveau 3, waarbij een wrap/unwrap-stap een tweede, zwakke set sleutels maakte die per vergissing werd gepubliceerd.
• De TLS-tussencertificaten leiden naar emSign ECC Root CA - G3. Sectigo’s AAA Certificate Services had dezelfde sleutels kruisondertekend; Sectigo trok die op 19 oktober in.

Is mijn PHP-server geraakt?

PHP heeft geen eigen CA-lijst. De extensies openssl en curl lezen openssl.cafile / curl.cainfo als die zijn ingesteld, anders de standaardpaden van OpenSSL, normaal de ca-certificates-bundel van de distributie. CRLSet of OneCRL ontvangen ze niet. Staat emSign ECC Root CA - G3 (of AAA Certificate Services voor de kruisondertekeningen) nog in die bundel, dan vertrouwt uw server de gecompromitteerde keten nog.

# Which CA file does PHP use? Run as the same user/SAPI as the site if you can.
php -r 'print_r(openssl_get_cert_locations());'
php -i | grep -E 'openssl.cafile|openssl.capath|curl.cainfo'

# Does PHP still trust the compromised eMudhra intermediates?
# Good result: bool(false) plus a "certificate verify failed" warning.
# Bad result: the page body is printed (the chain was trusted).
php -r 'var_dump(file_get_contents("https://dv-g3b-emudhra.we-have-a-problem.com/"));'
php -r 'var_dump(file_get_contents("https://dv-g3b-aaa-emudhra.we-have-a-problem.com/"));'

# Same check through the curl extension
php -r '$c = curl_init("https://dv-g3b-emudhra.we-have-a-problem.com/");
curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
var_dump(curl_exec($c), curl_error($c));'

# Is the eMudhra root still in the bundle?
ls /etc/ssl/certs | grep -i emsign            # Debian/Ubuntu symlinks
grep -n "emSign ECC Root CA - G3" /path/to/cacert.pem   # curl/Mozilla-format bundle
# composer/ca-bundle version inside a project
composer show composer/ca-bundle | grep versions

Controleer elke relevante SAPI. PHP-FPM en Apache mod_php kunnen een andere php.ini laden dan de CLI; vergelijk php --ini met een phpinfo()-pagina van de site.

Zo lost u het op

# Debian / Ubuntu (and Debian-based php:* Docker images)
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates
dpkg -l ca-certificates

# RHEL / Fedora / AlmaLinux / Rocky
sudo dnf upgrade ca-certificates

# Alpine (php:*-alpine images)
apk upgrade --no-cache ca-certificates

# Composer projects that ship composer/ca-bundle
composer update composer/ca-bundle    # 1.4.16+ or 1.6.0+

# Restart long-running PHP processes afterwards
sudo systemctl restart php8.3-fpm     # or apache2 / httpd / your queue workers

; php.ini — for stacks with their own stale bundle (XAMPP, WAMP, old panels)
; Download a current Mozilla-derived bundle from https://curl.se/ca/cacert.pem
; (the 2026-10-20 release or later), then point both settings at it:
curl.cainfo   = "/path/to/cacert.pem"
openssl.cafile = "/path/to/cacert.pem"
; Restart Apache / PHP-FPM so the new values load.

Oudere alles-in-één-stacks en lang niet onderhouden panelen zetten curl.cainfo vaak op een meegeleverd bestand dat nooit wordt vernieuwd. Bekijk de releasenotes van de leverancier of laat php.ini zoals hierboven naar een actuele cacert.pem verwijzen.

Wie al een fix heeft uitgebracht

Wij hebben de actuele cacert.pem van curl opgehaald (Last-Modified 20 oktober 2026): die bevat geen emSign ECC Root CA - G3 en geen AAA Certificate Services meer. composer/ca-bundle 1.4.16 en 1.6.0 voegen ook CaBundle::findDistrustedCertificate toe.

Releases die niet in de lijst staan, waaronder oudere distributies zoals Ubuntu 20.04 of Debian 11, stonden in de geraadpleegde bronnen niet als gepatcht. Controleer de tracker van uw leverancier.

FAQ

Bundels en hostingpanelen

XAMPP en hostingpanelen leveren eigen PHP-builds, dus hun CA-bundel volgt niet per se de ca-certificates-updates van het besturingssysteem. Zie de productpagina’s van XAMPP, cPanel, Plesk, DirectAdmin, CloudLinux, aaPanel en 宝塔面板, of de productlijst.