Firefox "ssl_error_no_cypher_overlap" erreur
Mes collègues et moi avons un problème à l'aide de Firefox 3.0.6 pour accéder à un Java 1.6.0___11 application web que nous développons. Tout fonctionne bien n'importe où de 1 à 30 minutes dans la séance...mais finalement, la connexion échoue et le message d'erreur suivant apparaît:
Secure Connection Failed
An error occurred during a connection to 10.x.x.x.
Cannot communicate securely with peer: no common encryption algorithm(s).
(Error code: ssl_error_no_cypher_overlap)
IE fonctionne très bien. Firefox lance l'erreur dans Windows et Fedora, donc le problème ne semble pas être liée à un OS. L'application Java EE s'exécute sur un serveur Tomcat 6.0.16 serveur. Toutes les pages sont cryptées à l'aide de TLS 1.0 par l'intermédiaire d'un Apache 2.2.8 serveur HTTP avec mod_nss.
Notre serveur Apache est configuré pour rejeter le protocole SSL 3.0 connexions. Une hypothèse que nous avons, c'est que Firefox peut être essayer d'établir un protocole SSL 3.0 connexion...mais pourquoi?
Basée quelques recherches sur Google, nous avons essayé les choses suivantes, mais sans succès:
-
à l'aide de Firefox 2.x (certaines personnes ont signalé des cas où les 2.x travaillé mais 3.x n'a pas):
-
permettant SSL2
-
la désactivation du protocole SSL3
-
la désactivation du protocole OCSP (Outils > Options > Avancé > le Chiffrement > Validation)
-
veiller à ce que les anti-virus/pare-feu de l'ordinateur client n'est pas de blocage ou de scanner le port 443 (https)
Des idées?
source d'informationauteur Michael
Vous devez vous connecter pour publier un commentaire.
J'ai eu le même problème lors du renouvellement du certificat pour notre serveur http://www.tpsynergy.com . Après l'importation du nouveau certificat de serveur et le redémarrage de tomcat, l'erreur nous étions était ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Après beaucoup de recherche, j'ai utilisé ce lien https://www.sslshopper.com/certificate-key-matcher.html de comparer le csr (demande de signature de certificat de le certificat réel). Ils ne correspondent pas. J'ai donc créé un nouveau rse et obtenu un nouveau certificat et installé le même. Il a travaillé.
Donc l'intégralité des étapes du processus sont
keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -keystore tpsynergy.fichier de clés
(changer le nom de domaine en tant que de besoin)
Créer cette, il vous sera demander de nom et de prénom. Ne donnez pas votre nom, mais le nom de domaine. Par exemple, je lui ai donné comme http://www.tpsynergy.com
2.keytool -certreq -keyalg RSA -alias tomcat -fichier csr.rse -keystore tpsynergy.fichier de clés
Cela va créer un csr.la rse fichier dans le même dossier. copier le contenu de la godaddy site et de créer le nouveau certificat.
Le certificat téléchargé le fichier zip aura trois fichiers
gd_bundle-g2-g1.crt
gdig2.crt
youractualcert.crt
Vous aurez besoin de télécharger la racine cert gdroot-g2.crt auprès de godaddy référentiel.
Copier tous ces fichiers dans le même répertoire où vous avez créé le fichier CSR et où le fichier de magasin de clés est situé.
Maintenant, exécutez les commandes ci-dessous, un par un pour importer le certificat dans le keystore
keytool-import -trustcacerts -alias la racine du fichier gd_bundle-g2-g1.crt -keystore tpsynergy.fichier de clés
keytool-import -trustcacerts -alias root2 -fichier gdroot-g2.crt -keystore tpsynergy.fichier de clés
keytool-import -trustcacerts -alias intermédiaire fichier gdig2.crt -keystore tpsynergy.fichier de clés
keytool-import -trustcacerts -alias tomcat -fichier yourdomainfile.crt -keystore tpsynergy.fichier de clés
De s'assurer que server.xml fichier dans le dossier conf a cette entrée
Redémarrer tomcat
Compte tenu de ce que vous avez essayé et les messages d'erreur, je dirais que c'était plus à voir avec l'exacte algorithme de chiffrement utilisé plutôt que le TLS/SSL version. Êtes-vous à l'aide d'un non-JRE Sun-ce que par hasard, ou un autre fournisseur de l'application de la sécurité? Essayez un autre JRE/OS pour tester votre serveur si vous le pouvez. À défaut, vous pourriez être en mesure de voir ce qui se passe avec Wireshark (avec un filtre de 'tcp.port == 443').
Si vous passez en revue le processus de négociation SSL sur Wikipédia, vous savez que le début ClientHello et ServerHello les messages sont envoyés entre le navigateur et le serveur.
Seulement si la méthode de chiffrement fournie dans le ClientHello avoir des éléments qui se chevauchent sur le serveur, ServerHello message doit contenir un chiffre que les deux côtés de soutien. Sinon, la connexion SSL ne sera pas lancé en tant que n'est pas la même monogramme.
Pour résoudre le problème, vous devez installer méthode de chiffrement (généralement au niveau de l'OS), au lieu de tenter difficile sur le navigateur (généralement le navigateur s'appuie sur l'OS). Je suis familier avec Windows et IE, mais je sais peu de choses sur Linux et Firefox, je ne peux que souligner quel est le problème, mais ne peut pas vous livrer une solution.
Sous paramètres avancés de firefox, vous devriez être en mesure de régler le chiffrement. Par défaut, SSL3.0 et TLS1.0 devrait être vérifié, donc si firefox est d'essayer de créer ssl 3.0 connectons essayer de décocher l'option ssl 3.0 s réglage.
si cela ne fonctionne pas, essayez une recherche dans le about:config "ssl2"
Mon Firefox a des paramètres avec ssl2 à false par défaut...
La première chose que je tiens à vérifier est la config pour mod_nss. C'est le plus étrange, c'est le vôtre et il n'est personne dans le monde l'aime 🙂 alors que s'il y avait un énorme bug dans Firefox ou mod_nss lui-même, je crois que vous pourriez avoir trouvé maintenant dans votre google quête. Le fait que vous avez trafiqué avec le fichier de configuration (par exemple, la désactivation du protocole SSL3, et de divers autres aléatoire tweaks), est aussi suspecte.
Je serais de retour en piste pour un très vanille mod_nss config et voir si cela fonctionne. Puis changer les choses de façon systématique à votre config actuelle jusqu'à ce que vous pouvez reproduire le problème. Par le son de la source de l'erreur est quelque part dans le cipher spec config de mod_nss et le protocole de négociation des trucs. Alors peut-être vous avez, par inadvertance changé quelque chose lorsque vous essayez de désactiver SSLv3 (d'ailleurs, pourquoi désactiver le protocole SSL3? Normalement, les gens désactiver la V2?).
Une autre chose à vérifier est que vous êtes sur la dernière mod_nss et ce n'est pas un bogue connu dans qui. Le fait qu'il gère pour le début de la séance et ne parvient pas plus tard est intéressant - il suggère que c'est peut-être d'essayer de renégocier la session et de ne pas négocier les algorithmes à ce point. Donc, il pourrait être le chiffrement symétrique. Ou il pourrait simplement être une mise en œuvre bug dans votre version de mod_nss que d'une certaine façon garbles le protocole.
Une autre idée, et c'est une je devine, est le navigateur tente de reprendre une session qui a été négocié avec SSLv3 avant vous l'avez désactivée, et quelque chose se brise lors de la tentative de reprise de la session lors de la V3 est éteint, ou peut-être mod_nss juste ne pas la mettre en œuvre.
Java/tomcat genre de choses semble comme un hareng rouge comme à moins que j'ai mal compris votre description, aucun de qui est impliqué dans la négociation SSL/protocole.
J'ai eu des problèmes similaires de navigation pour les sites sécurisés (https://) lors de l'utilisation de Rot (ou au moins un problème qu'apporteriez-vous à cette page lors d'une recherche Google):
ssl_error_no_cypher_overlap
dans FirefoxERR_SSL_VERSION_OR_CIPHER_MISMATCH
en ChromeIl s'est avéré être un problème avec à l'aide de Java 8. Quand je suis passé à Java 7, le problème arrêté.
Si vous obtenir le chiffrement de chevauchement erreur sur firefox, et vous avez laissé les paramètres par défaut, vous utilisez ce que doit être une très précaire site essayez d'utiliser une très faible "à l'exportation grade" cipher. L'utilisation de ces algorithmes est découragé ces jours et personnellement, je l'arrêter à l'aide d'un site en essayant d'utiliser une telle faiblesse de l'algorithme de chiffrement.
J'ai eu le même problème; à résoudre était suffisant pour permettre à tous les SSL schémas dans "about:config". J'ai été trouver par filtrage à l'aide de ssl. J'ai d'abord anabled toutes les options pour afret la désactivation de l'inutile.
"Code d'erreur: ssl_error_no_cypher_overlap" message d'erreur après la connexion, lorsque l'écran de Bienvenue prévu--d'utiliser le navigateur Firefox
Solution
Activer la prise en charge de 40 bits de cryptage RSA dans le Navigateur Firefox:
1: saisissez "about:config" dans la barre d'Adresse du Navigateur
2: rechercher/sélectionner "sécurité.ssl3.rsa_rc4_40_md5"
3: jeu booléen à VRAI
Ce qui a fonctionné pour moi est que je:
Remarque sur le redémarrage de Firefox: Quand je fais démarrer très rapidement après la fermeture,
elle a souvent un fichier de problème d'accès, ce qui m'oblige à supprimer lieux.sqlite
et lieux.sqlite-journal dans C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\n18091xv.par défaut. Cela me fait perdre mon histoire, plus signets doivent être
restauré à partir d'une sauvegarde chaque fois que cela se produit. - Je attendre de cinq à dix minutes ou
de plus pour éviter ce tracas.
Lancement de Firefox v3.5.1 sur WinMe
"Code d'erreur: ssl_error_no_cypher_overlap" message d'erreur après la connexion, lorsque l'écran de Bienvenue prévu--d'utiliser le navigateur Firefox
Solution
1: saisissez "about:config" dans la barre d'Adresse du Navigateur
2: rechercher/sélectionner "sécurité.ssl3.rsa_rc4_40_md5"
3: jeu booléen à VRAI