Firefox et SSL: sec_error_unknown_issuer

Mon client reçoit un message d’erreur sec_error_unknown_issuer lorsqu’il visite https://mediant.ipmail.nl avec Firefox. Je ne peux pas reproduire l’erreur moi-même. J’ai installé FF sur une machine Vista et XP et je n’ai eu aucun problème. FF sur Ubuntu fonctionne également très bien.

Est-ce que quelqu’un a la même erreur et est-ce que quelqu’un a des indices pour que je puisse dire à mon FAI de changer certains parameters? Le certificate est un soi-disant certificate SSL de type joker qui fonctionne pour tous les sous-domaines (* .ipmail.nl). Ai-je eu tort de choisir le moins cher?

Je viens d’avoir le même problème avec un certificate SSL Comodo Wildcard. Après avoir lu les documents, la solution est de vous assurer d’inclure le fichier de la chaîne de certificates qu’ils vous envoient dans votre configuration, c’est-à-dire

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

Tous les détails sur le site Comodo

Nous avons eu ce problème et il était très spécifique à Firefox – ne pouvait que reproduire dans ce navigateur, Safari, IE8, Chrome, etc.

Pour le réparer, il fallait obtenir un certificate mis à jour de Comodo et l’installer.

Aucune idée de ce que la magie a changé, mais c’était certainement quelque chose dans le cert que Firefox n’aimait pas.

Firefox est plus ssortingct que les autres navigateurs et nécessitera l’installation correcte d’un certificate de serveur intermédiaire. Cela peut être fourni par l’autorité de certificateion à laquelle le certificate a été acheté. Le certificate intermédiaire est généralement installé au même emplacement que le certificate du serveur et requirejs l’entrée appropriée dans le fichier httpd.conf.

Bien que beaucoup reprochent à Firefox de «signaler» (en général) cela de manière exclusive, cela démontre en réalité un niveau de sécurité supérieur.

Pour nginx, faites ceci Générer un fichier crt chaîné en utilisant

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

Le fichier résultant doit être utilisé dans la directive ssl_certificatee:

 server { listen 443 ssl; server_name www.example.com; ssl_certificatee www.example.com.chained.crt; ssl_certificatee_key www.example.com.key; ... } 

Je sais que ce sujet est un peu ancien, mais nous avons également rencontré ce problème et archiverons notre solution éventuelle pour les autres.

Nous avons eu le même problème avec un certificate Comodo “ssl positif”. Nous exploitons notre site Web en utilisant un proxy SSL Squid-Reverse et Firefox continuerait à se plaindre “sec_error_unknown_issuer” comme vous l’avez dit, mais tous les autres navigateurs étaient OK.

J’ai constaté que c’est un problème de chaîne de certificate incomplète. Firefox n’a apparemment pas l’un des certificates intermédiaires intégrés, même si Firefox fait confiance à l’autorité de certificateion racine. Par conséquent, vous devez fournir toute la chaîne de certificates à Firefox. Le support de Comodo indique:

Un certificate intermédiaire est le ou les certificates entre votre certificate de site (serveur) et un certificate racine. Le ou les certificates intermédiaires complètent la chaîne en un certificate racine approuvé par le navigateur.

L’utilisation d’un certificate intermédiaire signifie que vous devez effectuer une étape supplémentaire dans le processus d’installation pour permettre le chaînage de votre certificate de site à la racine approuvée et ne pas afficher d’erreurs dans le navigateur lorsque quelqu’un visite votre site Web.

Cela a déjà été abordé plus haut dans ce fil mais cela n’a pas changé votre façon de faire.

Vous devez d’abord créer un ensemble de certificates chaînés en utilisant votre éditeur de texte préféré et en les collant simplement dans l’ordre correct (inversé), c.-à-d.

  • Intermédiaire CA Certificate 2 – IntermediateCA2.crt – en haut du fichier
  • Certificat CA intermédiaire 1 – IntermediateCA1.crt
  • Certificat d’autorité de certificateion racine – root.crt – à la fin du fichier

L’ordre exact que vous pouvez obtenir de votre fournisseur de services SSL si ce n’est pas évident d’après les noms.

Ensuite, enregistrez le fichier comme vous le souhaitez. Par exemple votredomaine-chain-bundle.crt

Dans cet exemple, je n’ai pas inclus le certificate de domaine réel et tant que votre serveur peut être configuré pour prendre un ensemble de certificates chaîné distinct, c’est ce que vous utilisez.

Plus de données peuvent être trouvées ici:

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

Si, pour une raison quelconque, vous ne pouvez pas configurer votre serveur pour utiliser un ensemble chaîné distinct, il vous suffit de coller votre certificate de serveur au début (en haut) de l’ensemble et d’utiliser le fichier résultant comme certificate de serveur. C’est ce qui doit être fait dans le cas de l’affaire Squid. Voir ci-dessous la liste de diffusion de calmar à ce sujet.

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

Cela l’a résolu pour nous.

Quelle version de Firefox sur quelle plate-forme votre client utilise-t-il?

Les personnes ayant le même problème que celui décrit dans le forum de support pour Firefox . J’espère que vous pourrez y trouver une solution. Bonne chance!

Mettre à jour:

Laissez votre client vérifier les parameters dans Firefox: Sur “Avancé” – “Cryptage”, il y a un bouton “Afficher les certificates”. Recherchez “Comodo CA Limited” dans la liste. J’ai vu que Comodo est l’émetteur du certificate de ce nom de domaine / serveur. Sur deux de mes machines (FF 3.0.3 sur Vista et Mac), l’entrée est dans la liste (par défaut / Mozilla).

alt text http://soffr.miximages.com/firefox/Portable-Firefox_8.png

J’ai eu ce problème avec Firefox et mon serveur. J’ai contacté le support technique de GoDaddy et ils m’ont demandé d’installer le certificate de serveur intermédiaire:

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

Après un redémarrage du service de publication World Wide Web, tout fonctionnait parfaitement.

Si vous n’avez pas un access complet à votre serveur, votre FAI devra le faire pour vous.

Comme @ user126810 l’a dit, le problème peut être résolu avec une directive SSLCertificateChainFile appropriée dans le fichier de configuration.

Mais après avoir corrigé la configuration et redémarré le serveur Web, j’ai également dû redémarrer Firefox . Sans cela, Firefox a continué à se plaindre d’un mauvais certificate (on dirait qu’il a utilisé un cache).

Si vous avez obtenu votre certificate de COMODO, vous devez append cette ligne, le fichier se trouve sur le fichier zip que vous avez reçu.

 SSLCertificateChainFile /path/COMODORSADomainValidationSecureServerCA.crt 

Juin 2014:

C’est la configuration que j’ai utilisée et qui a bien fonctionné après avoir frappé ma tête contre le mur pendant quelques jours. J’utilise Express 3.4 (je pense que c’est la même chose pour Express 4.0)

 var privateKey = fs.readFileSync('helpers/sslcert/key.pem', 'utf8'); var certificatee = 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(); }); 

Puis j'ai redirigé les ports 80 et 443:

 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 

Comme vous pouvez le voir après avoir vérifié mes certificateions, j'ai 4 [0,1,2,3]:

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

 ubuntu@ip-172-31-5-134:~$ 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 certificatee in certificatee 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&.......sy 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"`.....BV.{.. 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 certificatee in certificatee chain) 

Bonne chance! PD: si vous voulez plus de réponses s'il vous plaît vérifier: http://www.benjiegillam.com/2012/06/node-dot-js-ssl-certificatee-chain/

Si quelqu’un d’autre rencontre ce problème avec une LAMP Ubuntu et “COMODO Positive SSL”, essayez de créer votre propre bundle à partir des certificates du fichier compressé.

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

J’ai tourné en rond avec Firefox 43, El Capitan et l’installation SSL WHM / cPanel continuant à recevoir l’erreur du site Untrusted – je n’ai pas acheté le certificate qui m’a été remis à installer lorsque le dernier gars est sorti . Il s’avère que j’installais sous le mauvais domaine parce que j’ai raté le www – mais le certificate toujours installé sur le domaine, lorsque j’ai installé le certificate dans WHM en utilisant http://www.domain.com.au il a installé maintenant s’inquiète et l’erreur FF a disparu – le certificate fonctionne correctement pour www et non-www.

Pour répondre à l’aspect de non-reproductibilité de la question – Firefox importe automatiquement les certificates intermédiaires dans son magasin de certificates. Donc, si vous avez déjà visité un site qui a utilisé le même certificate intermédiaire en utilisant une chaîne de certificates correctement configurée, Firefox stocke ce certificate pour que vous ne renconsortingez pas le problème lorsque vous visitez un site dont la chaîne est mal configurée. certificate.

Vous pouvez le vérifier dans le Gestionnaire de certificates de Firefox (Options-> Confidentialité et sécurité-> Afficher les certificates …) où vous pouvez voir tous les certificates stockés. Sous la colonne ‘Security Device’, vous pouvez vérifier la provenance d’un certificate – les certificates importés automatiquement / manuellement apparaîtront à partir de ‘Software Security Device’ par opposition au ‘Builtin Object Token’, qui est l’ensemble par défaut installé avec Firefox. Vous pouvez supprimer / méfier des certificates spécifiques et tester à nouveau.