Erreur de protocole SSL inconnue lors de la connexion
Je veux envoyer mes commits dans un référentiel Bitbucket mais cette erreur s'est produite:
Fatal: unable to access
'https://[email protected]/myUsername/myRepository.git/':
Unknown SSL protocol error in connection to bitbucket.org:443
Selon bitbucket Knowledgebase , cela peut également être dû au fait que le propriétaire du référentiel dépasse la limite du plan.
Si vous regardez plus bas dans la page, il semble également possible de déclencher cette erreur en utilisant une version trop ancienne de Git (une version 1.7 est nécessaire pour le moment).
Vous pouvez obtenir plus d'informations avec
# Windows
set GIT_CURL_VERBOSE=1
set GIT_TRACE_PACKET=2
# Unix
export GIT_CURL_VERBOSE=1
export GIT_TRACE_PACKET=2
Et puis essayez un git Push.
Vérifiez vos paramètres de proxy si vous en avez un.
Remarque: git 2.8 (mars 2016) ajoute des informations supplémentaires sur une erreur 35:
Voir commit 0054045 (14 février 2016) par Shawn Pearce (spearce) .
(Fusion par Junio C Hamano - gitster - dans commit 97c49af , 24 février 2016)
remote-curl: inclurecurl_errorstrsur les échecs de configuration SSLPour
curlerreur 35 (CURLE_SSL_CONNECT_ERROR), les utilisateurs ont besoin du texte supplémentaire stocké dansCURLOPT_ERRORBUFFERpour expliquer pourquoi la connexion n’a pas démarré.
Ceci estcurl_errorstrà l'intérieur dehttp.c, alors incluez-le dans le message s'il n'est pas vide.
Consultez également le causes communes de ce message :
Si cela fonctionnait auparavant et ne fonctionnait pas aujourd'hui, il est possible que la clé privée SSL ait expiré du côté de BitBucket (voir ci-dessous, motif n ° 3), mais cela ne semble pas être le cas ici (le certificat est valide jusqu'au 12/03/2014).
Le site de destination n'aime pas le protocole
L'exécution d'une requête semblable à celle-ci entraîne l'erreur de protocole SSL inconnu:
curl --sslv2 https://techstacks-tools.appspot.com/
Pourquoi? Eh bien, dans ce cas, c’est que le site des outils techstacks ne prend pas en charge SSLv2, ce qui génère l’erreur curl (35).
Le site de destination n'aime pas le chiffre
Vous essayez peut-être de vous connecter au site à l'aide d'un chiffrement SSL que le site est configuré pour rejeter.
Par exemple, les chiffrements anonymes sont généralement désactivés sur les sites chiffrés avec SSL. (Nous sommes nombreux à définir une politique générale de rejet sur tout site Web chiffré avec SSL, quel que soit son objectif.)
La chaîne de commande suivante "can" peut également générer l'erreur curl (35):
curl --ciphers ADH-RC4-MD5 https://some_web_site.some_domain.com/
Malheureusement, le type de réponse d'erreur que vous pouvez obtenir de curl dépend en grande partie du serveur SSL. Sur certains sites, vous recevez l'erreur de protocole SSL inconnu, mais sur mon site techstacks-tools, je reçois:
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Félicitations à Google, car cette erreur particulière est un peu plus descriptive que celle générée par mes sites Web au travail, car elle vous indique au moins qu’un socket a été démarré, mais qu’en raison de l’échec de la négociation, le socket n’a jamais pu se terminer.
Essayez de vous connecter au site avec un chiffre que le site prend en charge. Vous ne savez pas quel chiffrement utiliser? Eh bien, laissez-moi vous présenter mon testeur de chiffrement ssl cryptonark ...
La clé privée SSL a expiré
Je suis tombé sur celui-ci plus tôt aujourd'hui en travaillant avec un ancien site WebSeAL.
Dans IBM GSKit, vous pouvez spécifier la durée de validité du mot de passe de la clé privée. Après avoir atteint une certaine date, vous pourrez toujours démarrer Webseal et écouter sur le port 443 (ou tout autre paramètre défini pour votre valeur de port https), mais vous ne pourrez pas négocier correctement une session SSL.
Dans le cas présent, l'ancienne instance de WebSEAL utilisait un fichier kdb expiré depuis longtemps avec un mot de passe de clé privée expiré depuis longtemps. Une fois remplacée par la version correcte et plus récente, tout a fonctionné à nouveau.
Redirection incorrecte
Certains fournisseurs de services Internet et fournisseurs de DNS aiment intercepter vos requêtes DNS ayant échoué afin de vous rediriger vers une page de style résultats du moteur de recherche vous proposant d'autres URL ou "Voulez-vous dire ...?" résultats de contre-requête.
Si vous voyez une erreur comme celle-ci:
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol,
cela peut être dû au fait que vous avez mal saisi le nom d’hôte ou que le nom d’hôte n’est pas encore inscrit dans votre DNS Vous pouvez vérifier cela avec un simple "
Host" ou "nslookup".
Note (août 2015): Git 2.6+ (T3 2015) permettra de spécifier explicitement la version de SSL:
http: ajout du support pour spécifier la version SSL
Voir commit 01861cb (14 août 2015) par Elia Pinto (devzero2000) .
Aidé par: Eric Sunshine (sunshineco) .
(Fusion par Junio C Hamano - gitster - dans commit ed070a4 , 26 août 2015)
http.sslVersion
La version SSL à utiliser lors de la négociation d'une connexion SSL, si vous souhaitez forcer la valeur par défaut.
La version disponible et la version par défaut varient selon que libcurl a été construit avec NSS ou OpenSSL et selon la configuration particulière de la bibliothèque de chiffrement utilisée. En interne, cela définit l'option 'CURLOPT_SSL_VERSION'; Consultez la documentation de libcurl pour plus de détails sur le format de cette option et sur la version SSL prise en charge.
En réalité, les valeurs possibles de cette option sont les suivantes:
- sslv2
- sslv3
- tlsv1
- tlsv1.0
- tlsv1.1
- tlsv1.2
Peut être remplacé par la variable d'environnement '
GIT_SSL_VERSION'.
Pour forcer git à utiliser la version ssl par défaut de libcurl et à ignorer toute option explicitehttp.sslversion, définissez 'GIT_SSL_VERSION' sur la chaîne vide.
La définition du paramètre git suivant a résolu ce problème pour moi.
git config --global --add http.sslVersion tlsv1.0
Je devine que le serveur proxy d'entreprise n'a pas aimé le protocole de cryptage par défaut.
Dans de nombreux cas, cela est lié à des problèmes de proxy. Si oui, configurez simplement votre proxy git
git config --global http.proxy Host:PORT
Cette erreur vient aussi avec le serveur est en panne. Email du support technique sur la question:
"Nous avons rencontré une panne qui affectait le trafic sur le site Web, ainsi que le trafic de Mercurial et Git sur HTTPS. SSH n’a toutefois pas été affecté. N'hésitez pas à consulter cette page pour plus d’informations:
Alors réessayez plus tard et ça pourrait s'arranger. A fait pour moi
J'avais ça derrière un proxy d'entreprise.
Résolu par:
git config http.sslVerify "false"
J'ai rencontré ce problème alors que j'utilisais le contrôle de version dans Android Studio 2.1.3, le scénario auquel je fais face était le suivant:
1- J'ai ouvert le IDE et cliqué sur l'icône "update/pull" (Ctrl + T)
2- il n'a pas demandé le mot de passe principal et il a échoué, m'a donné cette erreur:
Unknown SSL protocol error in connection to bitbucket.org:443
3- J'ai essayé de récupérer le référentiel (clic droit> git> référentiel> chercher)
4- il m'a demandé le mot de passe principal et je l'ai entré
5- il a essayé d'aller chercher mais il a échoué encore et encore et encore
6- i redémarré Android studio
7- j'ai essayé de récupérer le référentiel (clic droit> git> référentiel> chercher)
8- il m'a demandé le mot de passe principal et je l'ai entré
9- maintenant les choses sont D'accordtout va bien
Conclusion :
peut-être que Android Studio a besoin du mot de passe principal avant toute action git, sinon il continuera d'échouer même s'il a demandé plus tard un mot de passe principal, je ne sais pas, c'est le scénario qui m'est arrivé
J'ai le même problème. Avec la dernière version de git et pas de proxy.
Je l'ai corrigé:
- signer dans le GitHub
- entrez l'interface: "Paramètres personnels", puis cliquez sur "Clés SSH", veuillez confirmer si vous avez mis le "id_rsa.pub" généré par la commande
- 'ssh-keygen -t rsa' sous windows dans github -> GIT BASH
- "Ajouter une clé SSH" et insérez-y le "id_rsa.pub".
Plus d'infos: créer la clé
Si vous rencontrez "Erreur de protocole SSL inconnue liée à bitbucket.org:443" et que vous vous trouvez en Chine, github est peut-être bloqué temporairement par le pare-feu. Vous pouvez essayer d'utiliser un réseau privé virtuel, ce qui fonctionnerait. Bonne chance!
J'ai eu le même problème, j'ai essayé de changer tous les paramètres SSL fournis ici. Si vous êtes dans le réseau d'entreprise et les clés SSH utilisées dans des outils tels que Gerrit. 1. Obtenez votre clé ssh, 2. Visitez Bitbucket et accédez à Profil >> Paramètres >> Clés SSH >> Ajouter une clé.
Après l’ajout de la clé ssh, essayez d’appuyer à nouveau.
J'utilise tortoiseGit. J'ai eu le même problème. Puis, dans les paramètres Push, j'ai décoché " la clé PuTTY à chargement automatique ", j'ai essayé de Push, puis je l'ai vérifié à nouveau, puis j'ai poussé, et cela a fonctionné. Mais sérieusement, je ne sais pas pourquoi.
j'ai pu le résoudre en courant
git config --list --show-Origin
et puis voyant que j'avais une ligne:
fichier: c: /Users/user/.gitconfig http.sslversion = sslv3
J'ai édité le fichier, c: /Users/user/.gitconfig, et supprimé la ligne [http] et la ligne sslversion = sslv3 et cela a été corrigé pour moi.
execute
nc -v -z <git-repository> <port>
votre sortie devrait ressembler
"Connection to <git-repository> <port> port [tcp/*] succeeded!"
si vous obtenez
connect to <git-repository> <port> (tcp) failed: Connection timed out
Vous devez éditer votre fichier ~/.ssh/config. Ajouter quelque chose comme ce qui suit:
Host example.com
Port 1234
avoir 2 ordinateurs,
le numéro un est mon laboratoire laboratoire connecté via VPN à notre réseau d'entreprise. C’est comme si je me trouvais à l’intérieur de la société derrière de gros pare-feu et un ensemble de routeurs, avec du personnel, tant interne qu’externe (même les télécoms) bidouillant sur le réseau et le pare-feu, et pour tendre la main, je dois fournir des identifiants tels que l’utilisateur proxy et mot de passe et même alors, parfois cela fonctionne et parfois pas.
c’est-à-dire que je peux atteindre le pare-feu en utilisant les téléchargements SVN JSVN MAVEN SVN, les téléchargements ANT et utiliser le clone git http: // git ... repos.
Mais je ne peux pas faire de git clone https: // git ... repo. J'ai ce dernier cas j'ai cette erreur.
L’ordinateur numéro deux sur place avec moi est mon petit labo de la maison, rien de spécial, connecté via WAN au www et obtenant des informations avec tous les outils mentionnés ci-dessus plus git clone https: // git ... repo fonctionne comme un reniflement sans faire quelque chose de spécial.
Conclusion: Le fait d'être assis derrière un "pare-feu géré d'une manière ou d'une autre" est souvent la cause des problèmes. Pour résoudre ce problème, prenez votre petit laboratoire sans protection et installez-vous en ligne sur votre ordinateur. S'il fonctionne, ne perdez pas de temps avec vos agents de sécurité, ils travailleront pendant des semaines, à moins de savoir pourquoi cela ne fonctionne pas dans votre système. cas, et peut-être que vous pouvez partager avec un lecteur portable le repo git cloné.
Josef - vieillir avec perdre son temps dans de telles situations ;-)
Le proxy HTTP d'entreprise derrière lequel je suis actuellement donne cette erreur de façon sporadique. Je peux y remédier simplement en visitant bitbucket.org dans un navigateur, puis en retyridisant la commande. Je ne sais pas pourquoi cela fonctionne, mais cela me règle le problème (du moins temporairement).
Cette erreur m’arrive lorsque Push grand nombre de sources (près de 700 Mo), puis j’essaie de le pousser partiellement et il a été poussé avec succès.