Ich denke wir haben das Problem lokalisiert.
Durch den Aufruf von "update-ca-certificates" wird das Tool "c_rehash" ausgeführt, welches wiederum alle Zertifikate in /etc/ssl/certs/ ausliest und einen Hashwert berechnet. Dort speichert LiveConfig ja auch die Zertifikatsketten der eigenen Zertifikate.
c_rehash stößt somit unter anderem auf das Zwischenzertifikat "R3" (US/O=Let's Encrypt/CN=R3, Hash=8d33f237) und legt dafür einen entsprechenden Symlink an (/etc/ssl/certs/8d33f237.0).
Wenn nun ein OpenSSL-Client eine Verbindung irgendwohin aufbaut, erhält er vom Server dessen SSL-Zertifikat sowie eine Liste der Zwischenzertifikate, mit denen der Client einen Validierungspfad erzeugen kann. Aktuell sieht diese Liste bei Let's Encrypt so aus:
#0: Subject: /CN=(Domainname)
#0: Issuer:/C=US/O=Let's Encrypt/CN=R3
#1: Subject: /C=US/O=Let's Encrypt/CN=R3
#1: Issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
#2: Subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
#2: Issuer: /O=Digital Signature Trust Co./CN=DST Root CA X3
#0 ist das eigentliche Client-Zertifikat, #1 das Zwischenzertifikat (R3), und #2 eben der Sonderfall für alte Clients, welche das Let's-Encrypt-CA-Zertifikat noch nicht kennen (also alte Android-Endgeräte etc.).
Das Problem liegt nun irgendwo im Verhalten von OpenSSL bei der Prüfung des Zwischenzertifikates (#1). Wenn hierfür nämlich der Hashwert-Symlink /etc/ssl/certs/8d33f237.0 existiert, dann hüpft es direkt weiter zur Prüfung von #2 - sucht also nach einem gültigen Zertifikat vom Aussteller "DST Root CA X3". Gibt's ja aber nicht, weil abgelaufen.
Existiert der Hash-Symlink (8d33f237.0) nun aber nicht, dann sucht OpenSSL erst im eigenen CA-Truststore ob es einen Aussteller namens "ISRG Root X1" findet. Den gibt's, also ist alles prima.
Auf den ersten Blick würde ich sagen, dass es sich hier um einen Bug in OpenSSL handelt. Möglicherweise ist dieses Verhalten aber auch bewusst und irgendwo in den Untiefen dokumentiert. Es dürfte bislang schlicht keine Rolle gespielt haben, weil wohl noch nie im vergleichbaren Umfang "abgelaufene" Chain-Zertifikate (hier: #2) in großem Stil ausgeliefert wurden, um Legacy-Clients noch eine Weile zu unterstützen.
Workaround: die Datei /etc/ssl/certs/8d33f237.0 löschen. Das hält auch eine Weile an, die Hash-Files werden i.d.R. erst beim Update von CA-Zertifikaten aktualisiert:
rm /etc/ssl/certs/8d33f237.0
Wir bereiten nun ein Update vor, welches u.a. folgende Änderungen vornimmt:
- die Datei /etc/ssl/certs/8d33f237.0 wird gelöscht
- die Chain-Zertifikate werden künftig nicht mehr in /etc/ssl/certs/[...]-ca.crt gespeichert, sondern in /etc/ssl/certs/[...].chain (also nicht mehr mit der Dateiendung ".crt", damit c_rehash diese künftig nicht mehr berücksichtigt.
Ich melde mich noch mal sobald das Update bereitsteht und wir das Verhalten so bestätigen konnten.