Gültige TLS Zertifikate angeblich abgelaufen?!?

Rosendoktor

Well-Known Member
Hi,

hab' seit heute früh plötzlich Probleme mit den TLS Zertifikaten meiner beiden Domains, aber nur mit bestimmten Progtrammen. Das erste was auffiel war der Evolution Mail Client, sowohl unter FreeBSD als auch unter Debian:

Bildschirmfoto zu 2020-05-31 00-18-57.png

Das Zertifikat ist gültig bis 3. Oktober 2020, die Meldung "Das Zertifikat ist abgelaufen" passt nicht dazu. Dasselbe Problem hab' ich mit einem Zertifikat vom gleichen Reseller und der gleichen CA bei einer zweiten Domain.

Es sind nur wenige Programme, die diese Probleme machen: Evolution, Seafile Client, apt (bei Debian, meine eigenen Repos per https). Die Serverdienste dazu sind Dovecot, Seafile Server und Apache.

Andere Programme akzeptieren die Zertifikate klaglos, dazu gehören Firefox, Chromium, wget und curl, sowie Thunderbird unter Windows 10. Auch ein Test mit "openssl s_client -connect <domain>:443" (bzw. 993 imap) ergab ein "OK". Ein Test bei SSLLabs ergab ein "A+" für beide Domains.

Was ist denn da los?

Ich habe keinerlei Updates auf dem Server und auf den Clients eingespielt seit gestern. Stimmt da was mit den Zertifikaten nicht? Spinnt hier eine SSL Bibliothek (openssl wohl nicht, und ich hab' keine Ahnung was z.B. Evolution und apt benutzen)? Ist irgendein Stichtag heute zu dem alte 3 Jahres Zertifikate vorzeitig ungültig werden?

Das betrifft jetzt leider nicht nur mich privat, sondern auch die Kita deren Vorstand und IT Beauftragter ich bin, insofern wäre eine Lösung dringend.

Grüße,

Robert
 
Benutzten die Programme einen anderen "Certificate Store" in dem eventuell ein altes (abgelaufenes) Zertifikat von der Issuing/Intermediate/Root CA liegt? Kannst du in den Programmen die Chain sehen und das Ablaufdatum der Reihe nach prüfen?
 
Hm, ich hab keine Ahnung welchen Certificate Store diese Programme benutzten, oder wie ich da herausfinden soll... Das Intermediate Zertifikat und das Root CA kann ich z.B. im Firefox sehen, die sind alle von Comodo und bis 2028 bzw. 2039 gültig. OpenSSL ist überall 1.1.1irgendwas, eine ältere libssl ist nicht vorhanden auf den betroffenen Systemen.

Na ja, ich warte einfach mal ab. Hab' noch keine Beschwerden von meinen Kita Kollegen gehört, die benutzen alle Windows oder Apple und da scheint alles zu funktionieren. Übrigens auch der Seafile Client auf meinem Windows. Nur unter Debian (10/buster und testing) und FreeBSD (12.1-RELEASE und -CURRENT) gibt's offenbar diese Probleme.

Solange SSLLabs keine Probleme meldet bin ich beruhigt...

Danke für die Tips.

Robert
 
Hi,

selbiges Problem habe ich heute auch auf mehreren Maschinen gelöst. Wie MH1962 schreibt liegt es an der abgelaufenen AddTrust CA. Es reicht aus das abgelaufene AddTrust aus der Chain zu werfen und den Dienst der das ausliefert neu zu starten. Um herauszufinden welches Zertifikat in deiner Chain das ist kannst du "openssl crl2pkcs7 -nocrl -certfile bundle.crt | openssl pkcs7 -print_certs -noout" benutzen.

Nachtrag: Golem hat jetzt auch eine Erklärung dazu: https://www.golem.de/news/sectigo-abgelaufenes-root-zertifikat-sorgt-fuer-aerger-2006-148840.html
 
Okay...
Code:
openssl crl2pkcs7 -nocrl -certfile <meinedomain.bundle.crt>  | openssl pkcs7 -print_certs -noout
Ergibt:
Code:
[...]
issuer=C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
Grrr... Wo muss ich das jetzt rausschmeissen, aus dem *.bundle.crt auf dem Server? Ist mir aus dem Link nicht ganz klar geworden.

Danke für den Hinweis! Wär ich selber nicht draufgekommen.

PS: GnuTLS also... Dachte mir sowas, nicht das erste mal, dass ich Ärger mit dem Ding habe, nicht umsonst compiliere ich alle Serverdienste die das nutzen lieber selbst mit OpenSSL...

EDIT: Hab's jetzt aus den CA Bundles entfernt, alle Serverdienste neu gestartet und jetzt beschwert sich kein Client mehr. Nochmals vielen Dank an Euch!

Grüße,

Robert
 
Zuletzt bearbeitet:
Zurück
Oben