web-dev-qa-db-fra.com

Comment faire en sorte que git accepte un certificat auto-signé?

En utilisant Git, y a-t-il un moyen de lui dire d'accepter un certificat auto-signé?

J'utilise un serveur https pour héberger un serveur git mais pour l'instant le certificat est auto-signé.

Lorsque j'essaie de créer le référentiel pour la première fois:

git Push Origin master -f

Je reçois l'erreur:

error: Cannot access URL     
https://the server/git.aspx/PocketReferences/, return code 22

fatal: git-http-Push failed
gitversion-controlhttpsself-signed
528
BahaiResearch.com

Accepter définitivement un certificat spécifique

Essayez http.sslCAPath ou http.sslCAInfo. La réponse d'Adam Spiers donne de bons exemples. C'est la solution la plus sécurisée à la question.

Pour désactiver la vérification TLS/SSL pour une seule commande git

essayez de passer -c à git avec la variable de configuration appropriée ou utilisez La réponse de Flow :

git -c http.sslVerify=false clone https://example.com/path/to/git

Pour désactiver la vérification SSL pour un référentiel spécifique

Si le référentiel est complètement sous votre contrôle, vous pouvez essayer:

git config http.sslVerify false

Désactiver globalement la vérification de certificat TLS (/ SSL) est une pratique terriblement peu sécurisée. Ne le fais pas. N'exécutez pas la commande ci-dessus avec un modificateur --global.

Il y a pas mal d'options de configuration SSL dans git. Depuis la page de manuel de git config:

http.sslVerify
    Whether to verify the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_NO_VERIFY environment variable.

http.sslCAInfo
    File containing the certificates to verify the peer with when fetching or pushing
    over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable.

http.sslCAPath
    Path containing files with the CA certificates to verify the peer with when
    fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CAPATH environment variable.

Quelques autres options de configuration SSL utiles:

http.sslCert
    File containing the SSL certificate when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_CERT environment variable.

http.sslKey
    File containing the SSL private key when fetching or pushing over HTTPS.
    Can be overridden by the GIT_SSL_KEY environment variable.

http.sslCertPasswordProtected
    Enable git's password Prompt for the SSL certificate. Otherwise OpenSSL will
    Prompt the user, possibly many times, if the certificate or private key is encrypted.
    Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment variable.
941
Christopher

Vous pouvez définir GIT_SSL_NO_VERIFY sur true:

GIT_SSL_NO_VERIFY=true git clone https://example.com/path/to/git

ou bien configurez Git pour ne pas vérifier la connexion sur la ligne de commande:

git -c http.sslVerify=false clone https://example.com/path/to/git

Notez que si vous ne vérifiez pas les certificats SSL/TLS, alors vous êtes sujet aux attaques MitM.

149
Flow

Je ne suis pas un grand fan des réponses (EDIT: versions originales du]} existantes, car la désactivation des contrôles de sécurité devrait être un dernier recours et non la première solution proposée. Même si vous ne pouvez pas faire confiance aux certificats auto-signés lors de la première réception sans une méthode de vérification supplémentaire, utiliser le certificat pour les opérations git suivantes rend au moins la vie beaucoup plus difficile pour les attaques qui ne se produisent que après vous avez téléchargé le certificat. . En d’autres termes, si le certificat que vous avez téléchargé est authentique, vous vous en tirerez bien. En revanche, si vous désactivez simplement la vérification, vous êtes ouvert à tout type d’attaque par man-in-the-middle à n’importe quel moment.

Pour donner un exemple spécifique: le célèbre repo.or.cz repository fournit un certificat auto-signé . Je peux télécharger ce fichier, le placer quelque part comme /etc/ssl/certs, puis faire:

# Initial clone
GIT_SSL_CAINFO=/etc/ssl/certs/rorcz_root_cert.pem \
    git clone https://repo.or.cz/org-mode.git

# Ensure all future interactions with Origin remote also work
cd org-mode
git config http.sslCAInfo /etc/ssl/certs/rorcz_root_cert.pem

Notez que l’utilisation de git config local ici (c’est-à-dire sans --global) signifie que ce certificat auto-signé n’est approuvé que pour ce référentiel particulier, qui est Nice. Cela vaut également mieux que d'utiliser GIT_SSL_CAPATH, car cela élimine le risque que git effectue la vérification via une autre autorité de certification, ce qui pourrait éventuellement être compromis.

120
Adam Spiers

Global .gitconfig pour les autorités de certification auto-signées

Voici comment nous avons réussi à faire en sorte que les certificats auto-signés fonctionnent sans désactiver sslVerify. Modifiez votre .gitconfig en utilisant git config --global -e ajoutez ces éléments: 

# Specify the scheme and Host as a 'context' that only these settings apply
# Must use Git v1.8.5+ for these contexts to work
[credential "https://your.domain.com"]
  username = user.name

  # Uncomment the credential helper that applies to your platform
  # Windows
  # helper = manager

  # OSX
  # helper = osxkeychain

  # Linux (in-memory credential helper)
  # helper = cache

  # Linux (permanent storage credential helper)
  # https://askubuntu.com/a/776335/491772

# Specify the scheme and Host as a 'context' that only these settings apply 
# Must use Git v1.8.5+ for these contexts to work
[http "https://your.domain.com"]
  ##################################
  # Self Signed Server Certificate #
  ##################################

  # MUST be PEM format
  # Some situations require both the CAPath AND CAInfo 
  sslCAInfo = /path/to/selfCA/self-signed-certificate.crt
  sslCAPath = /path/to/selfCA/
  sslVerify = true

  ###########################################
  # Private Key and Certificate information #
  ###########################################

  # Must be PEM format and include BEGIN CERTIFICATE / END CERTIFICATE, 
  # not just the BEGIN PRIVATE KEY / END PRIVATE KEY for Git to recognise it.
  sslCert = /path/to/privatekey/myprivatecert.pem

  # Even if your PEM file is password protected, set this to false.
  # Setting this to true always asks for a password even if you don't have one.
  # When you do have a password, even with this set to false it will Prompt anyhow. 
  sslCertPasswordProtected = 0

Références:

Spécifiez la configuration quand git clone-

Si vous devez l'appliquer au cas par cas, la documentation vous indique d'exécuter simplement git config --local dans votre répertoire de dépôt. Eh bien, ce n’est pas utile quand le référentiel n’a pas encore été cloné localement, n’est-ce pas?

Vous pouvez faire le global -> local hokey-pokey en définissant votre configuration globale comme ci-dessus, puis copiez ces paramètres dans votre configuration locale du référentiel une fois qu'elle est clonée ... 

OU ce que vous pouvez faire est spécifiez les commandes de configuration à git clone qui sont appliquées au référentiel cible une fois qu'il est cloné.

# Declare variables to make clone command less verbose     
OUR_CA_PATH=/path/to/selfCA/
OUR_CA_FILE=$OUR_CA_PATH/self-signed-certificate.crt
MY_PEM_FILE=/path/to/privatekey/myprivatecert.pem
SELF_SIGN_CONFIG="-c http.sslCAPath=$OUR_CA_PATH -c http.sslCAInfo=$OUR_CA_FILE -c http.sslVerify=1 -c http.sslCert=$MY_PEM_FILE -c http.sslCertPasswordProtected=0"

# With this environment variable defined it makes subsequent clones easier if you need to pull down multiple repos.
git clone $SELF_SIGN_CONFIG https://mygit.server.com/projects/myproject.git myproject/

Bon mot

EDIT: Voir VonC 's answer qui signale une mise en garde concernant les chemins absolus et relatifs pour des versions de git spécifiques allant de 2.14.x/2.15 à cette ligne

git clone -c http.sslCAPath="/path/to/selfCA" -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" -c http.sslVerify=1 -c http.sslCert="/path/to/privatekey/myprivatecert.pem" -c http.sslCertPasswordProtected=0 https://mygit.server.com/projects/myproject.git myproject/

CentOS unable to load client key

Si vous essayez ceci sur CentOS et que votre fichier .pem vous donne 

unable to load client key: "-8178 (SEC_ERROR_BAD_KEY)"

Ensuite, vous voudrez cette réponse StackOverflow sur la manière dont curl utilise NSS au lieu de Open SSL.

Et vous aimerez vouloir reconstruire curl à partir du source :

git clone http://github.com/curl/curl.git curl/
cd curl/
# Need these for ./buildconf
yum install autoconf automake libtool m4 nroff Perl -y
#Need these for ./configure
yum install openssl-devel openldap-devel libssh2-devel -y

./buildconf
su # Switch to super user to install into /usr/bin/curl
./configure --with-openssl --with-ldap --with-libssh2 --prefix=/usr/
make
make install

redémarre l'ordinateur car libcurl est toujours en mémoire en tant que bibliothèque partagée

Python, pip et conda

Connexes: Comment ajouter un certificat personnalisé CA Root au magasin CA Store utilisé par Python sous Windows?

23
Josh Peak

Je n'arrête pas de rencontrer ce problème, alors j'ai écrit un script pour télécharger le certificat auto-signé depuis le serveur et l'installer dans ~/.gitcerts, puis mettez à jour git-config pour qu'il pointe vers ces certificats. Il est stocké dans la configuration globale, vous ne devez donc l'exécuter qu'une fois par télécommande.

https://github.com/iwonbigbro/tools/blob/master/bin/git-remote-install-cert.sh

14
Craig

Cette réponse est extraite de cet article écrit par Michael Kauffman.

Utiliser Git pour Windows avec un certificat SSL d'entreprise

Problème: 

Si vous disposez d'un certificat SSL d'entreprise et souhaitez cloner votre référentiel à partir de la console ou du VSCode, vous obtenez le message d'erreur suivant:

fatal: impossible d’accéder à ‘ https: // myserver/tfs/DefaultCollection/_git/Proj/ ': problème de certificat SSL: impossible d’obtenir un certificat d’émetteur local}

Solution:

  1. Exportez le certificat auto-signé racine dans un fichier. Vous pouvez le faire depuis votre navigateur.

  2. Localisez le fichier “ca-bundle.crt” dans votre dossier git (version actuelle C:\Program Files\Git\usr\ssl\certs mais elle a été modifiée dans le passé). Copiez le fichier dans votre profil utilisateur. Ouvrez-le avec un éditeur de texte tel que VSCode et ajoutez le contenu de votre certificat exporté à la fin du fichier.

Nous devons maintenant configurer git pour utiliser le nouveau fichier:

git config --global http.sslCAInfo C:/Users/<yourname>/ca-bundle.crt

Cela ajoutera l'entrée suivante à votre fichier .gitconfig à la racine de votre profil utilisateur.

[http] sslCAInfo = C:/Users/<yourname>/ca-bundle.crt

6
AperioOculus

Vérifiez vos paramètres antivirus et pare-feu.

D'un jour à l'autre, git ne fonctionnait plus. Avec ce qui est décrit ci-dessus, j'ai constaté que Kaspersky plaçait un certificat racine personnel anti-virus auto-signé au milieu. Je n'ai pas réussi à laisser Git accepter ce certificat en suivant les instructions ci-dessus. J'ai abandonné ça. Ce qui fonctionne pour moi, c’est de désactiver la fonctionnalité d’analyse des connexions chiffrées.

  1. Ouvrir Kaspersky
  2. Paramètres> Autres> Réseau> Ne pas analyser les connexions chiffrées

Après cela, git fonctionne à nouveau avec sslVerify activé.

Remarque. Ce n'est toujours pas satisfaisant pour moi, car j'aimerais que cette fonctionnalité de mon antivirus soit activée. Dans les paramètres avancés, Kaspersky affiche une liste de sites Web qui ne fonctionneront pas avec cette fonctionnalité. Github n'est pas répertorié comme l'un d'entre eux. Je vais le vérifier sur le forum Kaspersky. Il semble y avoir certains sujets, par exemple https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211

3
Henk

Soyez prudent lorsque vous utilisez une doublure avec sslKey ou sslCert, comme dans Josh Peak 's answer :

git clone -c http.sslCAPath="/path/to/selfCA" \
  -c http.sslCAInfo="/path/to/selfCA/self-signed-certificate.crt" \
  -c http.sslVerify=1 \
  -c http.sslCert="/path/to/privatekey/myprivatecert.pem" \
  -c http.sslCertPasswordProtected=0 \
https://mygit.server.com/projects/myproject.git myproject

Seul Git 2.14.x/2.15 (T3 2015) serait capable d'interpréter correctement un chemin tel que ~username/mykey (alors qu'il peut toujours interpréter un chemin absolu tel que /path/to/privatekey).

Voir commit 8d15496 (20 juil. 2017) de Junio ​​C Hamano (gitster) .
Aidé de: Charles Bailey (hashpling) .
(Fusion par Junio ​​C Hamano - gitster - in commit 17b1e1d , 11 août 2017)

http.c: http.sslcert et http.sslkey sont les deux chemins d'accès

À l'époque où le codepath moderne http_options () a été créé pour analyser diverses options http. * sur 29508e1 ("Fonctionnalité isolée de la requête HTTP partagée", 2005-11-18, Git 0.99.9k), puis corrigée ultérieurement pour l'interaction entre les multiples fichiers de configuration dans 7059cd9 ("http_init(): Analyse du fichier de configuration des correctifs", 2009-03-09, Git 1.6.3-rc0), analysé variables de configuration comme http.sslkey, http.sslcert en clair Cordes à la vanille, parce que git_config_pathname() qui comprend Le préfixe "~[username]/" n'existait pas. 

Plus tard, nous avons converti certaines d’entre elles (à savoir, http.sslCAPath et http.sslCAInfo) pour utiliser la fonction, et avons ajouté des variables telles que http.cookeyFilehttp.pinnedpubkey pour utiliser la fonction depuis le début. Pour cette raison, ces variables comprennent toutes le préfixe "~[username]/".

Faites les deux variables restantes, http.sslcert et http.sslkey, également conscients de la convention, car ils sont tous deux clairement des noms de chemins pour des dossiers.

2
VonC

Dans le fichier .gitconfig , vous pouvez ajouter la valeur donnée ci-dessous pour que le certificat auto-signé soit acceptable

sslCAInfo = /home/XXXX/abc.crt

1
RahulMohan Kolakandy

Sous Windows, cela a fonctionné pour moi:

Ajoutez le contenu de votre certificat auto-signé à la fin du fichier ca-bundle. Y compris les lignes ----- BEGIN CERTIFICATE ----- et ----- END CERTIFICATE -----

L'emplacement du fichier ca-bundle est généralement C:\Program Files\Git\mingw64\ssl\certs

Ensuite, ajoutez le chemin du fichier ca-bundle à la configuration globale git. La commande suivante fait l'affaire: git config --global http.sslCAInfo "C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt"

Remarque: Le chemin d'accès dépend de votre chemin local du fichier ca-bundle!

1
rw026

À l'aide de la version 64 bits de Git sous Windows, ajoutez simplement le certificat d'auto-signature auto-signé dans ces fichiers:

  • C:\Program Files\Git\mingw64\ssl\certs\ca-bundle.crt 
  • C:\Program Files\Git\mingw64\ssl\certs\ca-bundle.trust.crt

S'il ne s'agit que d'un certificat auto-signé de serveur, ajoutez-le à

  • C:\Program Files\Git\mingw64\ssl\cert.pem
1
Flaviu

Ma réponse est peut-être en retard mais cela a fonctionné pour moi. Cela peut aider quelqu'un.

J'ai essayé les étapes mentionnées ci-dessus et cela n'a pas résolu le problème.

essayez ce git config --global http.sslVerify false

0
Manjuboyz

J'utilise une machine Windows et cet article m'a aidé. En gros, j'ai ouvert ca-bundle.crt dans le bloc-notes et y ai ajouté des certificats de chaîne (tous). Ce problème se pose généralement pour les réseaux d’entreprises où nous avons des intermédiaires assis entre le système et le dépôt Git. Nous devons exporter tous les certificats de la chaîne cert sauf le certificat feuille au format base 64 et les ajouter tous à ca-bundle.crt, puis configurer git pour ce fichier CRT modifié.

0
love gupta

Je le fais comme ça:

git init
git config --global http.sslVerify false
git clone https://myurl/myrepo.git
0
JedatKinports