Page Comparison

Haben wir  

Gibt es Probleme mit einem Zertifikat, sind häufig fehlende Zwischen- oder Stammzertifikate die Ursache.

...

fehlt mindestens ein Zertifikat in der Kette.

Nach dem Hashlink eb20b578.0 Ausschau zu halten, ist keine gute Idee. Hier  das Verzeichnislisting für das gesuchte Zertifikat, nachdem es installiert wurde; man sieht, dass es zwei Hashlinks auf das eigentliche pem-Zertifikat gibt.

-rw-r--r-- 1 root root 2350 Nov 7 19:35 TeleSec_ServerPass_DE-1.Nun pem
lrwxrwxrwx 1 root root 27 Apr 21 21:06 eb20b578.0 -> TeleSec_ServerPass_DE-1.pem
lrwxrwxrwx 1 root root 27 Apr 21 21:06 4804495f.0 -> TeleSec_ServerPass_DE-1.pem

Daher schauen wir in die Issuer-Zeile des vor der Fehlermeldung stehenden Zertifikats - insbesondere der in die (nicht immer vorhandenenvorhandene) CN-Angabe an - und füttern Google damit, also in diesem Fall mit folgenden Suchbegriffen:

"TeleSec ServerPass DE-1 Download"

was uns u. a. folgenden Suchtreffer beschert:

https://www.telesec.de/de/serverpass/support_rootca_akzeptanz.htmlVon 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), /root-sub-ca-zertifikate

Wir wählen auf der Übersichtsseite den Link "TeleSec ServerPass DE 1" aus und landen auf der Downloadseite für dieses Zertifikat.

Nun müssen wir schauen, in welchem Format uns das Zertifikat angeboten wird, im binär-Format oder ascii-Format (pem). Letzteres brauchen wir für den eisfair-Server.

Nach dem Download eines Zertifikats kann auch mit dem file-Befehl geprüft werden, ob es im binär- oder ascii-Format vorliegt:

# file --mime-encoding telesec-serpass-de-2.cer
telesec-serpass-de-2.cer: binary
# file --mime-encoding telesec-serpass-de-2.cer
telesec-serpass-de-2.cer: us-ascii

Finden wir einen Download-Link für das Zertifikat im ascii-Format, laden wir es uns herunter und legen es auf dem eisfair-Server im Verzeichniss /usr/local/ssl/certs ab.

Ein ascii-kodiertes pem-Zertifikat hat ungefähr folgendes Aussehen:

-----BEGIN CERTIFICATE-----
MIIGmzCCBYOgAwIBAgIIIbZ3foy9DqgwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UE
BhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQt
VGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g
...
Penv1Pe7MhUkCK0LqdTvkI/AHFzPYg/l5E3j8lQQ8hiKx8U6wf9xVKECLA2RlRqY
UX2rpjQNxnvEq/mEQv3x3mLOEFJ3TAKI+soDgOOi0OG8+ywhm6S+7Z9lTlJ+BcD6
oy1MNKd4CQbltHLMTFUH
-----END CERTIFICATE-----

Enthält das Zertifikat weitere lesbare Zertifikatsinformationen, löscht man diese bis auf den durch "BEGIN" und "END" eingeschlossenen Block einschliesslich der "BEGIN"- und "END"-Zeile.

Falls die Endung der Datei nicht pem sindern sondern z. B. auf 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 ZertifikatsketteAktuell wird das Zertifikat allerdings nur binär-kodiert angeboten. Wir nutzen den Download-Link und erhalten TeleSecServerPassDE-1.der. Blicken wir z. B. per Editor in diese Datei, finden wir keine "BEGIN CERTIFICATE"-Zeile, es ist also binär-kodiert.

Nun speichern wir diese Datei zunächst in einem beliebigen Verzeichnis des eisfair-Servers ab, wandeln sie in das ascii-Format um

openssl x509 -inform der  -in TeleSecServerPassDE-1.der -out TeleSecServerPassDE1.pem

und legen sie auf dem eisfair-Server im Verzeichniss /usr/local/ssl/certs ab.

Anschliessend rehashen

/var/install/bin/certs-update-hashes (Option 1 wählen)

und führen anschließend eine erneute Prüfung der Zertifikatskette durch. 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.

Über den Menüpunkt "Download ca certificate bundle" im certs-Menü werden eine ganze Reihe von Stamm- und Zwischenzertifikaten installiert. Seit der Version 1.3.3 des certs-Paketes wird hierbei das Zertifkatsbundle des Mozilla-Projektes geladen.