Haben wir Probleme mit einem Zertifikat, sind häufig fehlende Zwischen- oder Stammzertifikate das Problemdie Ursache.
Wir rufen zunächst im certs-Menü den Punkt "Show certificate chain" auf und wählen das zu prüfende Zertifikat aus.
Erscheint als letzte Zeile nicht "End of chain" sondern z. B.:
certificate : smtp.1und1.de.pem (6dc8b1dc)
subject : /C=DE/O=1 und 1 Internet
AG/ST=Rheinland-Pfalz/L=Montabaur/emailAddress=server-certs@1und1.de/CN=smtp.1und1.de
issuer : /C=DE/O=T-Systems International GmbH/OU=T-Systems Trust
Center/ST=NRW/postalCode=57250/L=Netphen/street=Untere Industriestr.
20/CN=TeleSec ServerPass DE-1 │1
SHA1 f-print:
0C:1D:EB:7C:16:91:73:B6:7A:CE:0B:30:18:6D:84:DA:7E:85:CC:E4 E4
+-> Error: file '/usr/local/ssl/certs/eb20b578.0' missing!
fehlt mindestens ein Zertifikat in der Kette.
Nun schauen wir in die Issuer-Zeile des vor der Fehlermeldung stehenden Zertifikats - insbesondere der (nicht immer vorhandenen) CN-Angabe und füttern Google damit, also in diesem Fall mit folgenden SuchgeriffenSuchbegriffen:
TeleSec ServerPass DE-1 Download
was uns u. a. folgenden Suchtreffer beschert:
https://www.telesec.de/serverpass/support_rootca_akzeptanz.html
Von dieser Seite laden wir uns nun das Zertifikat im pem-Format (es kann auch ascci-kodiert angegeben sein, binär ködiert hilft uns nicht weiter), und legen es auf dem eisfair-Server im Verzeichniss /usr/local/ssl/certs ab.
Falls die Endung der Datei nicht .pem pem sindern z. B. cer oder crt lautet, ändern wir diese dabei in . pem ab.
Anschliessend rehashen
/usr/bin/ssl/c_rehash /usr/local/ssl/certs
und erneute Prüfung der Zertifikatskette. Fehlt jetzt immer noch ein Zertifikat in der Kette, wiederholen wir die gerade gemachten Schritte.
Ganz zum Schluss rufen wir dann noch den Menüpunkt "Update Revocation list(s)" im certs-Menü auf.