Github ne peut pas accéder à l'erreur de connexion SSL

Question

J'utilise git lots depuis quelques mois. git push a fonctionné il y a 12 heures maintenant toutes les tentatives génèrent des erreurs, avec verbose il produit ceci :

GIT_CURL_VERBOSE=1 git push
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
* Trying 192.30.253.112... * Connected to github.com (192.30.253.112) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
   CApath: none
* NSS error -12190
* Expire cleared
* Closing connection #0
fatal: unable to access 'https://github.com/waveney/wmff/': SSL connect error

Des idées brillantes ? Aucun changement sur le serveur entre le moment où il fonctionnait et maintenant, le redémarrage n'a fait aucune différence.

Answer 1

J'ai eu le même problème sur plusieurs machines virtuelles CentOS 6 et il s'est avéré qu'il s'agissait d'un problème de bibliothèques curl et nss périmées (merci à ce fil de discussion de m'avoir indiqué la bonne direction) : Erreur de connexion SSL cURL 35 avec erreur NSS -5961 ).

La solution qui a fonctionné pour moi est juste :

yum update -y nss curl libcurl

Answer 2

yum update -y a fonctionné pour moi afin de corriger une erreur fatale lors de l'exécution de git clone.

Answer 3

J'ai eu la même expérience que l'OP, se produisant pour les mêmes raisons (avis de suppression de crypto de Github de TlsV1, ainsi que l'utilisation d'une machine avec un très vieux linux + git).

Pour information, si vous vous trouvez sur une très vieille version de linux, mais que vous vous obstinez à ne pas vouloir passer à une version plus récente de linux (et donc obtenir instantanément un Git plus récent et toutes ses dépendances), vous pouvez essayer de construire un Git plus récent, ainsi que ses dépendances à partir des sources.

C'est un chemin qui prend du temps et qui est douloureux, et la mise à jour de votre linux est probablement plus facile que cela, mais bon, je voulais juste rester avec mon vieux linux.

J'ai pris quelques notes sur ma tentative, en espérant qu'elles aideront ceux qui braveront ce chemin :

• Git dépendait de openssl et curl, donc j'ai dû les construire aussi
• J'ai dû mettre à jour ma version de cmake afin de construire la nouvelle version de curl (la construction de cmake a pris environ 2-3 heures).
• Le nouveau cmake m'a demandé de construire un nouveau gcc (ce qui a pris environ 21 heures sur ma vieille machine !).
• Une fois que j'ai eu cmake, j'ai pu construire curl, mais il faisait référence à une ancienne version d'openssl (qui n'avait pas la nouvelle version TlsV1.2).
• J'ai donc dû construire un openssl plus récent, puis construire curl (en faisant tout mon possible pour que la construction fasse référence à ce nouvel openssl).
• Ensuite, j'ai pu construire Git, en faisant de mon mieux pour qu'il référence les nouvelles versions d'openssl et de curl.

Je me suis retrouvé à utiliser plusieurs fois "ldd" pour confirmer les bibliothèques référencées, car à de nombreuses reprises, la compilation faisait référence à la mauvaise bibliothèque, et je devais trouver un moyen de faire respecter le chemin souhaité.

En voici quelques exemples :

# ldd /opt/git-2.27.0/libexec/git-core/git-http-fetch | grep -E "libssl|libcrypto|libcurl"
        libcurl.so => /usr/local/lib/libcurl.so (0x00aed000)
        libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00e86000)
        libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00893000)

Cela m'a permis de confirmer que "git-http-fetch" utilisait mon nouveau curl (dans /usr/local/lib, et non /usr/lib), et mon nouveau openssl (dans /usr/local/ssl/lib, et non /usr/lib).

$ ldd /usr/local/bin/curl | grep -E "libssl|libcrypto"
        libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00110000)
        libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x0016f000)

Cela m'a permis de confirmer que mon nouveau 'curl' faisait référence à la nouvelle version d'openssl (dans /usr/local/ssl/lib, et non /usr/lib).

Pour faire respecter ces chemins, Git vous permet de définir ces env-vars avant la construction :

OPENSSLDIR=/usr/local/ssl/
CURLDIR=/usr/local/

Pour curl, j'ai dû passer le chemin openssl via cmake :

cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl .

Pour cmake, il fait également référence à openssl, et j'ai passé ce chemin à travers son étape 'bootstrap' :

./bootstrap --prefix=/opt/cmake-3.17.3 -- -DOPENSSL_ROOT_DIR=/usr/local/ssl

Je vous prie de m'excuser si la réponse est éparpillée. Je peux l'étoffer avec plus de détails s'il y a une demande en ce sens, mais étant donné que cela m'a pris environ une semaine pour résoudre ce problème, je pense que la plupart des gens préféreront la voie saine de la mise à niveau de votre linux.