• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Zertifikatsfehler mit Chrome

fuchs

New Member
Hallo,

seit ein paar Tagen klagen manche Besucher meiner Seite über Zertifikatsprobleme mit Chrome. Seit März habe ich ein Wildcard / Multidomain Class 2 Zertifikat (3 Domains) von StartCom. Bei SSL Labs sieht meiner Meinung alles OK aus:
https://www.ssllabs.com/ssltest/analyze.html?d=kunstnet.de&latest
https://www.ssllabs.com/ssltest/analyze.html?d=kunstnet.org&latest
https://www.ssllabs.com/ssltest/analyze.html?d=kunstnet.info&latest

Selber kann ich die Fehler mit gleichem OS und Chromeversion nicht reproduzieren.

Mit: Win7 Chrome Version 47.0.2526.106 m
Diese Website verwendet eine schwache Sicherheitskonfiguration (SHA-1-Signaturen). Daher ist Ihre Verbindung möglicherweise nicht geschützt.

Mit Android 4.2.2 und Chrome 47.0.2526.83 evtl. mit dem Stockbrowser?
Das Zertifikat wurde von einer nicht vertrauenswürdigen Stelle ausgegeben

Meine Nginx (1.9.9) Config sieht in etwa so aus:

Code:
listen [::]:443 http2;
ssl on;
ssl_certificate /pfad/abc.crt;
ssl_certificate_key /pfad/abc.key;

ssl_ciphers EECDH+AESGCM:EDH+AESGCM:EECDH:EDH:!MD5:!RC4:!LOW:!MEDIUM:!CAMELLIA:$
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /pfad/dhparams.pem;

ssl_stapling on;
ssl_trusted_certificate /pfad/abc.pem;
ssl_stapling_verify on;

resolver 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220 valid=300s;
resolver_timeout 5s;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Auf dem Server läuft seit ein paar Tagen noch ein weiteres Class2 Zertifikat vorher hatte ich viele Class1 Zertifikate, kommen vielleicht dadurch die Fehler zustanden? Auf das zweite Class2 Zertifikat könnte ich auch verzichten. Eine Meinung war, es könne an den "subjectaltnames" liegen. Hat jemand von euch eine Idee?
 

Attachments

  • win7chrome.png
    win7chrome.png
    140.9 KB · Views: 228
  • android.jpg
    android.jpg
    59.4 KB · Views: 185
Last edited by a moderator:
Wenn ich das richtig sehe ist das verwendete RootCA mit SHA1 gesichert und das mögen ein paar Browser eben nicht mehr.
 
Dass die Root-CA mit SHA1 signiert ist ist zwar ein Problem, das führt aber AFAIK nur zu dem Fehler, wenn man das Root-CA mit dem Intermediate-Zertifikat zusammen vom Server rausschickt (was man ohnehin unterlassen sollte).
Wenn du das Root-Zertiifkat aus dem Intermediate-Zertifikat herausnimmst, sollte die Warnung wieder verschwinden.
Hinweis dazu: Chrome hat einen Cache für TLS-Zertifikate - am Besten schließt du alle Chrome-Instanzen und versuchst es nach der Änderung erneut, um diesen Cache zu umgehen.
 
https://www.ssllabs.com/ssltest/ wird dir sagen wo das Problem liegt.

Aber wenn du weißt das etwas "depricated" ist stellt sich die Frage doch gar nicht ob es sein muss oder nicht. :confused:

Btw: Das ROOT-CA darf SHA1 sein.
 
Last edited by a moderator:
Auf Android 4.3 komme ich mit keinem Browser auf deine Domain kunstnet.de per SSL, es ist kein vertrauenswürdiges Zertifikat.
 
Das sind Screenshots von Usern meiner Seite, selbst habe ich diese Fehlermeldungen nicht.

Ja, ich habe wieder den ursprünglichen Stand eingespielt, aber mit den Zertifikaten haben manche Probleme. Oder wäre es möglich, dass bei den Users irgendwas falsch konfiguriert ist?

edit: Ein User hat mal für mich nachgeschaut, ob Startcom bei Android 4.2.2 aktiviert ist: "Einstellungen -> Sicherheit -> Vertrauensw. Anmeldedaten -> System" und es fehlte das Häkchen...

Jetzt bleibt nur noch dieser Fehler:
https://serversupportforum.de/threads/zertifikatsfehler-mit-chrome.56411/

Den kann ich aber aber mit Windows 7 (32bit und 64bit) und gleicher Chrome Version nicht auslösen. Der User benutzt in der Regel einen anderen Browser...
 
Last edited by a moderator:
Muss er halt schauen ob er die Certs im Trust hat.

Chrome, FireFox & Edge nicht reproduzierbar.
 
Da ist kein Fehler, lediglich ein Hinweis.
Google (und etliche Andere) möchte halt ab 2017 keine SHA1-Signaturen mehr in Zertifikaten sehen und weist rechtzeitig darauf hin. Das ist völlig in Ordnung und kann derzeit weitestgehend ignoriert werden...

Vielmehr solltest Du Dich um Deine restliche suboptimale SSL-Konfiguration kümmern und insbesondere das SPDY-Modul deaktivieren, denn das ist seit längerem deprecated da nicht standardkonform.
 
Da ist kein Fehler, lediglich ein Hinweis.
Google (und etliche Andere) möchte halt ab 2017 keine SHA1-Signaturen mehr in Zertifikaten sehen und weist rechtzeitig darauf hin. Das ist völlig in Ordnung und kann derzeit weitestgehend ignoriert werden...
Im Chain ist aber nur das Root (StartCom Certification Authority) in einem der Pfade SHA1 und darüber warnt Chrome nicht.

Edit: https://googleonlinesecurity.blogspot.de/2014/09/gradually-sunsetting-sha-1.html
SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

Desweiteren ist nginx's "http2" nicht "spdy"
 

Attachments

  • ccertwarn.jpg
    ccertwarn.jpg
    62.1 KB · Views: 170
Last edited by a moderator:
Das ist ein bekannter Bug den die Chrome/Chromium Entwickler seit einiger Zeit umherschleppen aber wohl nicht lösen wollen oder können. StartCom hat seit einiger Zeit die Zertifikate sowohl mit SHA1 und SHA256 Intermediate signiert um einen fliessenden Übergang zu erlauben und aus einem nicht näher erklärten Grund wird vom Browser gerne aus einem Cache das falsche (alte) Intermediate genommen.

Startssl hat das Problem seit kurzem (16. Dezember) durch das Erstellen neuer Intermediates mit anderem Namen gelöst.

und insbesondere das SPDY-Modul deaktivieren, denn das ist seit längerem deprecated da nicht standardkonform.
Nginx Spdy ist standardkonform, um genauer zu sein Draft 3.1 des SPDY-Standards. Dass der Standard als solcher deprecated und von HTTP/2 abgelöst wurde ist eine andere Sache mit anderer Ursache.
 
Last edited by a moderator:
Ich stehe gerade auf dem Schlauch, ich bin extra auf eine aktuellere nginx Version gewechselt, um http2 einsetzen zu können. Spdy wird mir mit nginx -V nicht angezeigt, sondern nur mit --with-http_v2_module Den Eintrag "ngx_http_spdy_module" finde ich nicht.

@d4f, meinst du das hier: https://shaaaaaaaaaaaaa.com/check/kunstnet.de "If Chrome still says the site uses SHA-1, it's probably a chain caching bug on your computer."
 
@d4f, meinst du das hier:
Ja, hier der Link zum Bugreport in Chromium, hatte ich vergessen bei zu fügen:
$https://code.google.com/p/chromium/issues/detail?id=473105

Ich stehe gerade auf dem Schlauch, ich bin extra auf eine aktuellere nginx Version gewechselt, um http2 einsetzen zu können
Aktuell setzt du auch HTTP/2 ein und nicht Spdy. Ob du zum Zeitpunkt von Joe User's Kommentar es auch schon eingesetzt hatte kann ich nicht sehen :D
 
Nginx Spdy ist standardkonform, um genauer zu sein Draft 3.1 des SPDY-Standards. Dass der Standard als solcher deprecated und von HTTP/2 abgelöst wurde ist eine andere Sache mit anderer Ursache.
SPDY war niemals und ist auch aktuell kein Standard (RFC).

Und selbst wenn Nginx mitlerweile ein HTTP/2 Modul haben und der OP es einsetzen sollte, so ist es dennoch deprecated, da es NPN statt ALPN verwendet.
 
featuring experimental HTTP/2 module.
Sollte klar sein das dass nicht im produktiven Einsatz landen sollte.

Und selbst wenn Nginx mitlerweile ein HTTP/2 Modul haben und der OP es einsetzen sollte, so ist es dennoch deprecated, da es NPN statt ALPN verwendet.
Nur als "Fallback":
Note that accepting HTTP/2 connections over TLS requires the “Application-Layer Protocol Negotiation” (ALPN) TLS extension support, which is available only since OpenSSL version 1.0.2. Using the “Next Protocol Negotiation” (NPN) TLS extension for this purpose (available since OpenSSL version 1.0.1) is not guaranteed.
http://nginx.org/en/docs/http/ngx_http_v2_module.html#issues
 
Last edited by a moderator:
Back
Top