# Firefox erkennt Zertifikatspfad erst nach Umweg



## DaRealMC (9. Oktober 2015)

Hallo Forum,

ich habe hier ein seltsames Probem und hoffe, dass es trotz Anonymisierung verständlich wird.
Ich habe einen Webservice, der mit einem Wildcard-Zertifikat über https erreichbar ist: 
Das Zertifikat ist gültig für *.domain.tld und wurde ganz normal von einer Zertifikatsstelle ausgestellt.
An mehreren Client-PCs klappt der Aufruf problemlos. Zert wird sofort als valide erkannt.
Auf zwei Servern aber sagt mir der Firefox (41.0.1), er vertraut diesem Zertifikat nicht, weil kein Zertifizierungspfad vorhanden ist.
Lasse ich mir das Zert anzeigen, sieht das auch so aus.
Gehe ich jetzt auf einen andren Webservice, der ebenfalls mit einem Wildcard-Zert (*.sub.dmain.tld) von der selben CA (am selben Tag) ausgestellt wurde, wird dort der Pfad richtig erkannt.
Gehe ich jetzt wieder auf den ersten Webservice, wird auch hier der Pfad richtig erkannt und das Zert ist valide.
Schließe ich den FF und öffne ihn neu, geht das von vorne los.
(Der Workaround, dem Zert einfach manuell für immer zu vertrauen kommt nicht in Frage)


----------



## Bullja (10. Oktober 2015)

Stichwort "Zertifizierungsketten", siehe http://pki.uni-regensburg.de/hintergrund.py
Es gibt Root-CAs
Es gibt eventuell Zwischen-CAs
Es gibt eventuell weitere Unter-CAs

Im default Firefox Profil sind nur die Root-CAs enthalten. Beim Aufruf einer Webseite mit einem Zertifikat welches von einem der "Unter-CAs" ausgestellt wurde, kann der Browser der Webseite nicht blind vertrauen.
Der Webserver muss neben dem eigentlichen Zertifikat auch die cert chain zur Verfügung stellen. Die cert chain beinhaltet praktisch alle Zertifikat zwischen dem Root-CA bis zum ausgestelltem Zertifikat (Je nach Webserver, ohne das letztere). Nur mit dieser *Zertifikatskette - die man von der Zertifikatsstelle erhält *- kann der Browser das Zertifikat validieren.

Ein Apache wird z.b. so konfiguriert:

  SSLCertificateFile /etc/ssl/localcerts/server.cert.pem
  SSLCertificateKeyFile /etc/ssl/localcerts/server.key.pem
  SSLCertificateChainFile /etc/ssl/localcerts/ca-chain.crt

NGINX: http://nginx.org/en/docs/http/configuring_https_servers.html#chains

Chrome und IE verwenden einen Windows certificate store. Firefox erstellt für jedes Firefox-Profil einen neuen cert store (Dateien im Firefox Benutzer Profil). Um zu testen ob der Webserver nun korrekt konfiguriert ist, reicht es ein neues Firefox erstellen und damit auf die Website draufgehen. (oder die Unter-CAs aus den trusted CAs herauslöschen)


Der Grund wieso die erste Webseite wieder "funktionioert" nachdem man auf der *.sub.domain.tld war ist: Der Webserver hinter *.sub.domain.tld wurde korrekt mit der Zertifikatskette konfiguriert. Firefox merkt sich diese Zertifikatskette (wird im cert store vom Benutzer hinterlegt) und somit kann auch das Zertifikat der ersten Webseite validiert werden, auch wenn der Webserver die Zertifikatskette "nicht liefert"


----------



## DaRealMC (12. Oktober 2015)

Danke für die Antwort. War tatsächlich ein falsch konfigurierter Zertifikatspfad am Loadbalancer.
Seltsam ist, dass es bei den normalen Clients problemlos funktionierte. Aber vermutlich hat dort einfach ein andrer Dienst das Zwischenzertifikat richtig erhalten.


----------



## Bratkartoffel (12. Oktober 2015)

Hi,

sehr hilfreich für derartige Probleme finde ich auch den Test von SSLLabs:

https://www.ssllabs.com/ssltest/

Hiermit lassen sich generelle Probleme recht einfach rausfinden, vorallem auch die technischen Gründe mit denen man danach Google füttern kann.

Grüsse,
BK


----------



## DaRealMC (12. Oktober 2015)

Die Seite kenne ich, klappt bei rein internen Seiten aber nicht


----------

