Ich habe StartSSL auf meinem Webserver installiert, auf dem Linux Apache auf CentOS 6.5 läuft. shaaaaaaaaaaaaa.com sagte
Gut. example.com hat eine überprüfbare Zertifikatskette, die mit SHA-2 signiert ist.
Allerdings sagte Google Chrome auf Debian 7.8
Die Verbindung wird mit AES_128_CBC verschlüsselt, mit SHA1 zur Authentifizierung und ECDHE_RSA als Mechanismus zum Schlüsselaustausch.
Auf der Debian-Box habe ich
mkdir ~/StartComCerts
mv /etc/ssl/certs/StartCom* ~/StartComCerts
und das Problem war weg. Allerdings ist es keine praktikable Lösung, wenn Kunden Änderungen an ihren Computern vornehmen. Also habe ich das GeoTrust QuickSSL Premium-Zertifikat von ssls.com gekauft. Dann ging ich zuhttps://knowledge.geotrust.com/support/knowledge-baseund es hieß: „Zertifikat ist korrekt installiert“. Wenn ich meine Site jedoch mit Chrome unter Debian 7.8 aufrufe, erhalte ich die Meldung:
Diese Site verwendet eine schwache Sicherheitskonfiguration (SHA-1-Signaturen), daher ist Ihre Verbindung möglicherweise nicht privat.
Und
Die Site verwendet veraltete Sicherheitseinstellungen, die möglicherweise verhindern, dass zukünftige Chrome-Versionen sicher darauf zugreifen können.
Ich habe meine Site auf www.ssllabs.com/ssltest/analyze.html getestet. Dort wurde meine Site mit A bewertet und es wurde mir gesagt, dass mein Signaturalgorithmus SHA256withRSA ist. Ich ging zu shaaaaaaaaaaaaa.com und sagte
Gut. example.com hat eine überprüfbare Zertifikatskette, die mit SHA-2 signiert ist.
Ich ging zu whynopadlock.com und alles war positiv. Ich testete auch mit Chrome auf einem anderen Computer mit Windows 7 und bekam ein grünes Vorhängeschloss ohne Fehlermeldungen.
Ich weiß nicht, warum ich bei Chrome unter Debian den SHA-1-Fehler erhalte.
Bearbeiten - 15.06.2015
Ich habe auch auf einigen Windows-Systemen ein Sha-1-Problem. Unten sehen Sie den Screenshot von Google Chrome auf meinem privaten Windows-System (links) und auf meinem Windows-Arbeitssystem (rechts). Es scheint, als würde auf verschiedenen Systemen ein zwischengespeichertes Sha-1-Zertifikat verwendet. Ich habe das Zwischenzertifikat gemäß den Anweisungen von GeoTrust eingerichtet.
Bearbeiten:
Ich betreibe von zu Hause aus ein Geschäft und das ist auch der Zweck meiner Website.
Antwort1
Das Problem besteht darin, dass auf Ihrem Windows-Computer das Antivirusprogramm Avast installiert ist. Avast fügt ein SSL-Zertifikat zwischen der Website und Google Chrome ein. Siehe „Avast Web/Mail Shield“ oben im linken Bild.
Google Chrome zeigt auf Ihrem Computer eine Warnung an, da Chrome das lokal gefälschte Zertifikat validiert. Avast AntiVirus fälscht die SSL-Zertifikate, damit sie den SSL-Verkehr sehen und scannen können. Scans wie Qualys SSL Labs sagen Ihnen die Wahrheit.
Sie können Avast Web/Mail Shield deaktivieren und es in Google Chrome erneut versuchen. Auf diese Weise validiert Chrome das von Ihrem Server bereitgestellte Zertifikat und nicht das eingefügte/gefälschte SSL-Zertifikat, das Avast zwischen Ihrem Server und Google Chrome einfügt.
Auf dem linken Bild sehen Sie Informationen zum Avast SSL-Zertifikat. Auf dem rechten Bild finden Sie Informationen zu Ihrem eigenen GeoTrust SSL-Zertifikat.
Ich gehe davon aus, dass Sie auf Ihrem Debian-Rechner auch die Linux-Version von Avast verwenden und dass dadurch eine ähnliche Situation entsteht wie auf dem Windows-Rechner.
Antwort2
Das Problem ist, dass Ihr Zertifikat SHA1 als Signaturalgorithmus verwendet. Wenn Ihr Zertifikat tatsächlich SHA2 verwendet, überprüfen Sie alle Zwischen- (und Stamm-)Zertifikate in Ihrer Kette. Jedes einzelne Zertifikat muss SHA2 verwenden.
SHA1 ist eine alte (schwache) Technologie und sollte nicht mehr verwendet werden. Die meisten PKI-Anbieter bieten beide Möglichkeiten. Laden Sie einfach SHA2-Kettenzertifikate herunter und laden Sie sie auf Ihren Server hoch. Dann ist das Problem gelöst.
Da Sie ein SHA2-Zertifikat verwenden (wie oben dargestellt), liegt das Problem bei einem der Zwischenzertifikate. Überprüfen Sie alle auf SHA1 und holen Sie sich stattdessen die SHA2-Zertifikate.