Einmal – nur ein einziges Mal möchte ich mit Profis arbeiten. Das der Dienst E-Post unbenutzbar ist, darüber schrieb ich ja bereits.
WIE grottenschlecht der Dienst allerdings wirklich ist, war mir in DIESEM Umfang allerdings noch nicht bewusst:
Soviel zum Thema Sachverstand bei der Post! LÄCHERLICH!!!!!
Danke an Marco, der mich auf diesen Brüller aufmerksam machte.
Passiert bei mir nicht, adresse-sichern.epost.de hat eine geschlossene Zertifikatskette. Und zwar egal ob ich die Seite mit Internet Explorer 8 oder mit Chromium oder Opera unter Linux aufrufe. Das liegt offenbar daran, daß Firefox sich anders als andere Browseranbieter entschlossen hat, das entsprechende CA Root Certificate von Comodo aus dem Standardsatz zu entfernen.
Dafür mag es Gründe geben, aber ich finde es etwas unfair, daraufhin den Kübel der Inkompetenz über dem E-Post-Dienst auszuschütten. Das wäre IMHO dann angebracht, wenn das Zertifikat abgelaufen oder für den falschen CN ausgestellt wäre. Aber so?
Nein, das ist nicht unfair, sondern tatsächlich Inkompetenz, und das kannst Du auch selbst überprüfen ( openssl s_client -connect adresse-sichern.epost.de:443 ):
Der Webserver liefert tatsächlich eben keine komplette Zertifikatskette zurück, sondern genau 1 Zertifikat, welches von „/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Extended Validation Secure Server CA“ signiert wurde. Diese intermediate CA wurde von der Comodo Root CA signiert (siehe http://www.tbs-certificats.com/fom-serve/cache/591.html ), welche bei Firefox standardmäßig eingebaut ist. Sie hätten also einzig und allein noch das Zertifikat für die EV-CA noch mit anhängen müssen, um den Kreis tatsächlich zu schließen.
Es ist aus gutem Grund „common practice“, dass man Webserver so einstellt, dass sie die komplette Zertifikatskette bis zur Wurzel zurückgeben (also bis zu einem selbstsignierten Root-Zertifikat), und nicht einfach bei irgendeinem Intermediate aufhört.
Dass einige Browser es offenbar erlauben, sich den allerletzten „Hop“ zu ersparen, kann nicht als Entschuldigung dienen — schon gar nicht, wenn das auf einen der meistverwendetsten Browser in Deutschland nicht zutrifft, also offenbar noch nicht mal vernünftig getestet wurde.
Nachtrag:
http://www.sslshopper.com/ssl-checker.html#hostname=www.epost.de
vs.
http://www.sslshopper.com/ssl-checker.html#hostname=adresse-sichern.epost.de
zeigt das auch nochmal schön grafisch.
Ja, Schuster bleib bei deinen Leisten und die Post sollte lieber bei Briefen und Päckchen bleiben.
@Christoph:
Ah, interessant. Ich habe den Fehler also an der falschen Stelle gesucht — wollte aber auch nicht Stunden in die Fehlersuche stecken. Du wußtest offenbar schneller, wo Du suchen mußt.
Stellt sich mir nun nur die Frage, warum Chromium die komplette Zertifikatkette bis zum eingebauten CA-Zertifikat anzeigt (sie also vorhanden ist, auch wenn der Host sie vielleicht nicht sendet), während Firefox dafür zu doof ist … ich habe jetzt leider keine Zeit, das weiter zu untersuchen, aber ganz so einfach, wie Du das darstellst, scheint mir der Fall auch nicht zu liegen …
Doch, so einfach ist es 🙂
Vermutlich haben Chromium und Konsorten ganz simpel auch schon die (recht neue) Intermediate CA in ihrem Store (macht FF bei einigen anderen Anbietern ja auch so), was es dann erlaubt, den kompletten Pfad nachzuvollziehen, obwohl der Server ihn nicht mitsendet. Eigentlich ist aber genau das IMO bad practice, eben weil es die Leute dazu erzieht, schludrig sein zu können.
Eigentlich ist mir auch egal, warum es nicht funktioniert. Alleine der Punkt, dass es mit einem der geläufigen Browser nicht funktioniert deutet darauf hin, dass hier geschludert worden ist. Entweder ist gar nicht getestet worden oder nur unzureichend. In beiden Fällen ist es ein Armutszeugnis…
Und wenn sie da schon nicht ordentlich testen dann weiß ich ja, wie das bei den restlichen sicherheitsrelevanten Bereichen aussieht…