Question Comment puis-je faire accepter à git 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'essaye de créer le repo pour la première fois:

git push origin master -f

J'ai l'erreur:

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

fatal: git-http-push failed

470
2017-07-23 23:00


origine


Réponses:


Pour accepter définitivement un certificat spécifique

Essayer http.sslCAPath ou http.sslCAInfo. La réponse d'Adam Spiers donne quelques bons exemples. C'est la solution la plus sûre à la question.

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

essayer de passer -c à git avec la variable de configuration appropriée, ou utiliser 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 entièrement 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ûre. Ne fais pas ça. N'émettez pas la commande ci-dessus avec un --global modificateur.


Il y a pas mal d'options de configuration SSL dans git. De 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.

835
2017-07-23 23:28



Vous pouvez définir GIT_SSL_NO_VERIFY à 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 vulnérable aux attaques MitM.


143
2017-10-14 15:11



Je ne suis pas un grand fan du [EDIT: versions originales de la] les réponses 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 au premier reçu sans méthode de vérification supplémentaire, utilisez le certificat git opérations au moins rend la vie beaucoup plus difficile pour les attaques qui se produisent uniquement après vous avez téléchargé le certificat. En d'autres termes, si le certificat que vous avez téléchargé est authentique, alors vous êtes bon à partir de là. En revanche, si vous désactivez simplement la vérification, vous êtes ouvert à tout type d'attaque de l'homme du milieu. à tout moment.

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

# 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 locale git config ici (c'est-à-dire sans --global) signifie que ce certificat auto-signé est approuvé uniquement pour ce référentiel particulier, ce qui est agréable. C'est aussi plus agréable que d'utiliser GIT_SSL_CAPATH puisqu'il élimine le risque de git effectuer la vérification via une autre autorité de certification susceptible d’être compromise.


107
2017-11-06 17:44



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

Pour ma part et pour mes collègues, voici comment nous avons réussi à faire fonctionner les certificats auto-signés sans désactiver sslVerify. Modifier votre .gitconfig à utiliser git config --global -e ajoutez-les:

# 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

Les références:

Spécifiez la configuration quand git clone-ing

Si vous devez l'appliquer sur une base de repo, la documentation vous dit de simplement l'exécuter git config --local dans votre répertoire repo. Eh bien, ce n'est pas utile quand vous n'avez pas le repo cloné localement, mais maintenant est-ce?

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 repo locale une fois qu'il clone ...

OU ce que vous pouvez faire est spécifier les commandes de configuration à git clone qui sont appliqués au repo 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 VonCde répondre cela indique une mise en garde sur les chemins absolus et relatifs pour les versions spécifiques de git de 2.14.x / 2.15 à cette seule 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 votre .pem le fichier vous donne

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

Alors vous voudrez cette réponse StackOverflow à propos de comment curl utilise NSS au lieu d'Open SSL.

Et vous aimerez vouloir reconstruire curl de la 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émarrer l'ordinateur car libcurl est toujours en mémoire en tant que bibliothèque partagée


17
2017-12-21 01:22



Je continue à rencontrer ce problème, donc j'ai écrit un script pour télécharger le certificat auto-signé du serveur et l'installer sur ~ / .gitcerts, puis mettre à jour git-config pour pointer vers ces certificats. Il est stocké dans la configuration globale, vous n'avez donc besoin de l'exécuter qu'une fois par télécommande.

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


13
2017-12-19 22:40



Soyez prudent lorsque vous utilisez un liner en utilisant sslKey ou sslCert, comme dans Josh Peakde répondre:

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) pourrait interpréter un chemin comme ~username/mykey correctement (alors qu'il peut encore interpréter un chemin absolu comme /path/to/privatekey).

Voir commettre 8d15496 (20 juil. 2017) par Junio ​​C Hamano (gitster).
Aidé par: Charles Bailey (hashpling).
(Fusionné par Junio ​​C Hamano - gitster - dans commettre 17b1e1d11 août 2017) 

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

Retour lorsque le chemin de code moderne http_options () a été créé pour analyser   diverses options http. * à 29508e1 ("Isoler la requête HTTP partagée   fonctionnalité ", 2005-11-18, Git 0.99.9k), et plus tard a été corrigé pour   l'interaction entre les fichiers de configuration multiples dans 7059cd9   ("http_init(): Correction de l'analyse du fichier de configuration ", 2009-03-09, Git 1.6.3-rc0), nous avons analysé   les variables de configuration comme http.sslkey, http.sslcert comme clair   cordes vanille, car git_config_pathname() qui comprend   "~[username]/"le préfixe n'existait pas.

Plus tard, nous avons converti certains d'entre eux (à savoir, http.sslCAPath et http.sslCAInfo) pour utiliser la fonction, et ajouté des variables comme http.cookeyFile  http.pinnedpubkey utiliser la fonction depuis le début. A cause de cela, toutes ces variables comprennent "~[username]/" préfixe.

Faire les deux variables restantes, http.sslcert et http.sslkey, aussi   au courant de la convention, car ils sont tous deux clairement des chemins vers   des dossiers.


2
2017-08-13 18:25



Cette réponse est extraite de Cet article auteur de Michael Kauffman.

Utiliser Git pour Windows avec un certificat SSL d'entreprise

Problème:

Si vous possédez un certificat SSL d'entreprise et que vous souhaitez cloner votre dépôt depuis la console ou VSCode, vous obtenez l'erreur suivante:

fatal: impossible d'accéder 'https: // myserver / tfs / DefaultCollection / _git / Proj /': Problème de certificat SSL: impossible d'obtenir le certificat d'émetteur local

Solution:

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

  2. Recherchez le fichier "ca-bundle.crt" dans votre dossier git (version actuelle C: \ Program Files \ Git \ usr \ ssl \ certs, mais il a été modifié par le passé). Copiez le fichier dans votre profil utilisateur. Ouvrez-le avec un éditeur de texte comme VSCode et ajoutez le contenu de votre certificat exporté à la fin du fichier.

Maintenant, nous devons 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


2
2018-03-27 14:30



Vérifiez les paramètres de votre antivirus et de votre pare-feu.

D'un jour à l'autre, git ne travaillait plus. Avec ce qui est décrit ci-dessus, j'ai trouvé que Kaspersky mettait 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 renoncé à ça. Ce qui fonctionne pour moi est de désactiver la fonctionnalité pour analyser les connexions cryptées.

  1. Ouvrir Kaspersky
  2. Paramètres> Supplémentaire> Réseau> Ne pas analyser les connexions crypté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 Anti-Virus soit active. 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 quelques sujets, par exemple https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211


2
2018-05-19 12:03



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

sslCAInfo = /home/XXXX/abc.crt


1
2017-11-09 15:53



En utilisant la version 64 bits de Git sous Windows, ajoutez simplement le certificat CA auto-signé dans ces fichiers:

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

Si c'est juste un certificat auto-signé par le serveur, ajoutez-le

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

1
2018-03-05 12:52



Exécutez la commande suivante:

git config --global http.sslVerify false

-2
2017-10-10 12:26