web-dev-qa-db-de.com

Firefox und SSL: sec_error_unknown_issuer

Mein Client erhält eine sec_error_unknown_issuer-Fehlermeldung, wenn er https://mediant.ipmail.nl mit Firefox besucht. Ich habe FF auf einem Vista- und einem XP -Maschine installiert und hatte keine Probleme. FF auf Ubuntu funktioniert auch gut.

Bekommt jemand die gleiche Fehlermeldung und hat jemand ein paar Hinweise für mich, so dass ich meinem Internetdienstanbieter mitteilen kann, dass er einige Einstellungen ändern soll? ). War ich falsch, den billigsten auszuwählen?

56
Overbeeke

Hatte gerade das gleiche Problem mit einem Comodo Wildcard SSL-Zertifikat. Nach dem Lesen der Dokumente besteht die Lösung darin, sicherzustellen, dass Sie die Zertifikatskettendatei, die Sie Ihnen senden, in Ihre Konfiguration aufnehmen, d. H.

SSLCertificateChainFile /etc/ssl/crt/yourSERVERNAME.ca-bundle

Vollständige Details auf Comodo-Site

41
user126810

Wir hatten dieses Problem und es war sehr viel Firefox-spezifisch - nur Repro in diesem Browser, Safari, IE8, Chrome usw. waren alles in Ordnung.

Behebung erforderlich ein aktualisiertes Zertifikat von Comodo erhalten und installieren.

Keine Ahnung, welche Magie sie veränderten, aber es war definitiv etwas, was Firefox NICHT gefiel.

12
Jeff Atwood

Firefox ist strenger als andere Browser und erfordert die ordnungsgemäße Installation eines Zwischenserverzertifikats. Dies kann von der Zertifizierungsstelle bereitgestellt werden, von der das Zertifikat erworben wurde. Das Zwischenzertifikat wird normalerweise am gleichen Ort wie das Serverzertifikat installiert und erfordert den richtigen Eintrag in der Datei httpd.conf.

viele züchtigen Firefox wegen seiner (im Allgemeinen) exklusiven "Kennzeichnung", zeigen aber tatsächlich höhere Sicherheitsstandards.

6
Jason Clark

Für nginx machen Sie folgendes Generieren Sie eine verkettete CRT-Datei mit

$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt

Die resultierende Datei sollte in der Direktive ssl_certificate verwendet werden:

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.chained.crt;
    ssl_certificate_key www.example.com.key;
    ...
}
4
Cc65

Ich weiß, dass dieser Thread ein wenig alt ist, aber auch wir sind darauf gestoßen und werden unsere mögliche Lösung hier für andere archivieren.

Das gleiche Problem hatten wir mit einem Comodo-Wildcard-Zertifikat "positive ssl". Wir betreiben unsere Website mit einem Squid-Reverse-SSL-Proxy, und Firefox beschwert sich weiterhin über "sec_error_unknown_issuer", wie Sie sagten.

Ich habe festgestellt, dass dies ein Problem der unvollständigen Zertifikatskette ist. In Firefox ist anscheinend kein Zwischenzertifikat eingebaut, obwohl Firefox der Stammzertifizierungsstelle vertraut. Daher müssen Sie die gesamte Zertifikatskette für Firefox bereitstellen. Die Unterstützung von Comodo lautet:

Ein Zwischenzertifikat ist das Zertifikat oder Zertifikate, die zwischen Ihrem Standort (Server) abgelegt werden Zertifikat und ein Root-Zertifikat. Das Zwischenzertifikat oder Zertifikate vervollständigt die Kette zu einem Stammzertifikat, dem die .__ vertraut. Browser.

Wenn Sie ein Zwischenzertifikat verwenden, müssen Sie ein .__ ausfüllen. zusätzlicher Schritt im Installationsprozess, um Ihre Site zu aktivieren Zertifikat, das mit dem vertrauenswürdigen Stamm verkettet werden soll, und zeigt keine Fehler in der Browser, wenn jemand Ihre Website besucht.

Dies wurde bereits früher in diesem Thread angesprochen, es wurde jedoch nicht beschrieben, wie Sie dies tun.

Zuerst müssen Sie ein verkettetes Zertifikatspaket erstellen. Dazu verwenden Sie Ihren bevorzugten Texteditor und fügen ihn einfach in der richtigen Reihenfolge ein, d. H.

  • Intermediate CA Certificate 2 - IntermediateCA2.crt - über der -Datei 
  • Intermediate CA Certificate 1 - IntermediateCA1.crt
  • Root-CA-Zertifikat - root.crt - am Ende der Datei

Die genaue Reihenfolge erhalten Sie von Ihrem SSL-Anbieter, wenn Sie den Namen nicht entnehmen können.

Speichern Sie dann die Datei unter Ihrem gewünschten Namen. Z.B. yourdomain-chain-bundle.crt

In diesem Beispiel habe ich das eigentliche Domänenzertifikat nicht hinzugefügt. Solange Ihr Server so konfiguriert werden kann, dass ein separates verkettetes Zertifikatspaket verwendet wird, verwenden Sie dies.

Weitere Daten finden Sie hier:

https://support.comodo.com/index.php?/Knowledgebase/Artikel/View/643/0/how-do-i-make-my-own-bundle-file-from-crt-files

Wenn Sie Ihren Server aus irgendeinem Grund nicht für die Verwendung eines separaten verketteten Bundles konfigurieren können, fügen Sie einfach Ihr Serverzertifikat am Anfang (oben) des Bundles ein und verwenden Sie die resultierende Datei als Serverzertifikat. Dies muss im Fall von E.g Squid erledigt werden. Siehe unten in der Squid-Mailingliste zu diesem Thema.

http://www.squid-cache.org/mail-archive/squid-users/201109/0037.html

Dies hat es für uns gelöst.

3
leancode

Ich hatte dieses Problem mit Firefox und meinem Server. Ich habe mich an den GoDaddy-Kundensupport gewandt, und ich musste das Zwischen-Serverzertifikat installieren:

http://support.godaddy.com/help/article/868/what-is-an-an-intermediate-certificate

Nach einem Neustart des World Wide Web Publishing Service hat alles perfekt funktioniert.

Wenn Sie keinen vollständigen Zugriff auf Ihren Server haben, muss dies Ihr ISP für Sie tun.

2
toddb

Welche Firefox-Version auf welcher Plattform verwendet Ihr Client?

Das sind Leute, die das gleiche Problem haben wie dokumentiert hier im Support Forum für Firefox . Ich hoffe, Sie können dort eine Lösung finden. Viel Glück!

Update:

Lassen Sie Ihren Client die Einstellungen in Firefox überprüfen: Auf "Erweitert" - "Verschlüsselung" befindet sich die Schaltfläche "Zertifikate anzeigen". Suchen Sie in der Liste nach "Comodo CA Limited". Ich habe gesehen, dass Comodo der Aussteller des Domainnamens/Servers ist. Auf zwei meiner Maschinen (FF 3.0.3 unter Vista und Mac) befindet sich der Eintrag in der Liste (standardmäßig/Mozilla).

 alt text

2
splattne

Wenn Sie Ihr Zertifikat von COMODO erhalten haben, müssen Sie diese Zeile mit Hinzufügen. Die Datei befindet sich in der ZIP-Datei, die Sie erhalten haben.

SSLCertificateChainFile /path/COMODORSADomainValidationSecureServerCA.crt
1
Steven Lizarazo

Juni 2014:

Dies ist die Konfiguration, die ich verwendet habe und sie funktioniert gut, nachdem ich den Kopf einige Tage an die Wand geschlagen habe. Ich verwende Express 3.4 (ich denke, das gleiche gilt für Express 4.0)

var privateKey  = fs.readFileSync('helpers/sslcert/key.pem', 'utf8');
var certificate = fs.readFileSync('helpers/sslcert/csr.pem', 'utf8');

files = ["COMODORSADomainValidationSecureServerCA.crt",
         "COMODORSAAddTrustCA.crt",
         "AddTrustExternalCARoot.crt"
        ];

ca = (function() {
  var _i, _len, _results;

  _results = [];
  for (_i = 0, _len = files.length; _i < _len; _i++) {
    file = files[_i];
    _results.Push(fs.readFileSync("helpers/sslcert/" + file));
  }
  return _results;
})();

var credentials = {ca:ca, key: privateKey, cert: certificate};

// process.env.PORT : Heroku Config environment
var port = process.env.PORT || 4000;

var app = express();
var server = http.createServer(app).listen(port, function() {
        console.log('Express HTTP server listening on port ' + server.address().port);
});
https.createServer(credentials, app).listen(3000, function() {
        console.log('Express HTTPS server listening on port ' + server.address().port);
});

// redirect all http requests to https
app.use(function(req, res, next) {
  if(!req.secure) {
    return res.redirect(['https://mydomain.com', req.url].join(''));
  }
  next();
});

Dann habe ich die Ports 80 und 443 umgeleitet:

Sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 4000
Sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 3000

Wie Sie nach Prüfung meiner Zertifizierungen sehen können, habe ich 4 [0,1,2,3]:

openssl s_client -connect mydomain.com:443 -showcerts | grep "^"

[email protected]:~$ openssl s_client -connect mydomain.com:443 -showcerts | grep "^ "
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mydomain.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
    Protocol  : TLSv1.1
    Cipher    : AES256-SHA
    Session-ID: 8FDEAEE92ED20742.....3E7D80F93226142DD
    Session-ID-ctx:
    Master-Key: C9E4AB966E41A85EEB7....4D73C67088E1503C52A9353C8584E94
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 7c c8 36 80 95 4d 4c 47-d8 e3 ca 2e 70 a5 8f ac   |.6..MLG....p...
    0010 - 90 bd 4a 26 ef f7 d6 bc-4a b3 dd 8f f6 13 53 e9   ..J&..........S.
    0020 - f7 49 c6 48 44 26 8d ab-a8 72 29 c8 15 73 f5 79   .I.HD&.......s.y
    0030 - ca 79 6a ed f6 b1 7f 8a-d2 68 0a 52 03 c5 84 32   .yj........R...2
    0040 - be c5 c8 12 d8 f4 36 fa-28 4f 0e 00 eb d1 04 ce   ........(.......
    0050 - a7 2b d2 73 df a1 8b 83-23 a6 f7 ef 6e 9e c4 4c   .+.s...........L
    0060 - 50 22 60 e8 93 cc d8 ee-42 22 56 a7 10 7b db 1e   P"`.....B.V..{..
    0070 - 0a ad 4a 91 a4 68 7a b0-9e 34 01 ec b8 7b b2 2f   ..J......4...{./
    0080 - e8 33 f5 a9 48 11 36 f8-69 a6 7a a6 22 52 b1 da   .3..H...i....R..
    0090 - 51 18 ed c4 d9 3d c4 cc-5b d7 ff 92 4e 91 02 9e   .....=......N...
    Start Time: 140...549
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

Viel Glück! PD: Wenn Sie mehr Antworten wünschen, überprüfen Sie bitte: http://www.benjiegillam.com/2012/06/node-dot-js-ssl-certificate-chain/

1
lito

Wie @ user126810 sagte, kann das Problem mit einer richtigen SSLCertificateChainFile-Direktive in der Konfigurationsdatei behoben werden.

Aber nachdem ich die Konfiguration korrigiert und den Webserver neu gestartet hatte, musste ich auch Firefox neu starten. Ohne das hat Firefox sich weiterhin über ein fehlerhaftes Zertifikat beschwert (es scheint, als hätte es ein zwischengespeichertes Zertifikat verwendet).

1
vadipp

Ich habe im Kreis mit Firefox 43, El Capitan und WHM/cPanel SSL-Installation herumgelaufen und ständig den Fehler "Nicht vertrauenswürdige Site" erhalten. Ich habe das Zertifikat nicht gekauft, das mir zur Installation übergeben wurde, als der letzte Typ zur Tür hinausging . Es stellte sich heraus, dass ich unter der falschen Domäne installiert habe, weil ich das www verpasst habe - aber das Zertifikat wurde immer noch in der Domäne installiert. Als ich das Zertifikat in WHM mit www.domain.com.au installierte, macht es sich jetzt Sorgen und der FF-Fehler ist verschwunden - Das Zertifikat funktioniert sowohl für WWW als auch für Nicht-WWW.

0
Rob

Wenn jemand anderes dieses Problem mit einer Ubuntu-LAMP und "COMODO Positive SSL" hat, versuchen Sie, aus den Zertifikaten in der komprimierten Datei ein eigenes Paket zu erstellen.

cat AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt > YOURDOMAIN.ca-bundle

0
chmoder

Um den nicht reproduzierbaren Aspekt der Frage zu beantworten, importiert Firefox automatisch Zwischenzertifikate in seinen Zertifikatsspeicher. Wenn Sie also zuvor eine Site besucht haben, die dasselbe Zwischenzertifikat mit einer korrekt konfigurierten Zertifikatskette verwendet hat, speichert Firefox dieses Zertifikat. Das Problem wird also nicht angezeigt, wenn Sie eine Site besuchen, die eine falsch konfigurierte Kette mit derselben Zwischenproduktgruppe hat Zertifikat.

Sie können dies im Firefox-Zertifikats-Manager (Optionen -> Datenschutz & Sicherheit -> Zertifikate anzeigen ...) anzeigen, wo Sie alle gespeicherten Zertifikate sehen können. In der Spalte "Sicherheitsgerät" können Sie überprüfen, woher ein Zertifikat stammt. Automatisch/manuell importierte Zertifikate werden als "Software-Sicherheitsgerät" angezeigt, im Gegensatz zum "Builtin Object Token", dem standardmäßig mit Firefox installierten Satz. Sie können beliebige Zertifikate löschen/misstrauen und erneut testen.

0
Pierz