Come posso far accettare un certificato autofirmato?

Usando Git, c’è un modo per dirgli di accettare un certificato autofirmato?

Sto usando un server https per ospitare un server git ma per ora il certificato è autofirmato.

Quando provo a creare il repository per la prima volta:

git push origin master -f 

Ottengo l’errore:

 error: Cannot access URL https://the server/git.aspx/PocketReferences/, return code 22 fatal: git-http-push failed 

Per accettare in modo permanente un certificato specifico

Prova http.sslCAPath o http.sslCAInfo . La risposta di Adam Spiers offre alcuni grandi esempi. Questa è la soluzione più sicura alla domanda.

Per disabilitare la verifica TLS / SSL per un singolo comando git

prova a passare -c a git con la variabile di configurazione appropriata, oppure usa la risposta di Flow :

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

Per disabilitare la verifica SSL per un repository specifico

Se il repository è completamente sotto il tuo controllo, puoi provare:

 git config http.sslVerify false 

Disabilitare la verifica dei certificati TLS (/ SSL) a livello globale è una pratica terribilmente insicura. Non farlo Non --global comando precedente con un modificatore --global .


Ci sono alcune opzioni di configurazione SSL in git . Dalla pagina man di 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. 

Alcune altre utili opzioni di configurazione SSL:

 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. 

È ansible impostare GIT_SSL_NO_VERIFY su true :

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

o in alternativa configurare Git per non verificare la connessione sulla riga di comando:

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

Notare che se non si verificano i certificati SSL / TLS, si è soggetti a attacchi MitM .

Non sono un grande fan delle [EDIT: versioni originali delle] risposte esistenti, perché disabilitare i controlli di sicurezza dovrebbe essere l’ultima risorsa, non la prima soluzione offerta. Anche se non è ansible fidarsi dei certificati autofirmati al primo ricevimento senza alcun metodo aggiuntivo di verifica, l’utilizzo del certificato per le successive operazioni git rende la vita molto più difficile per gli attacchi che si verificano solo dopo aver scaricato il certificato. In altre parole, se il certificato che hai scaricato è autentico, allora da allora in poi sei a posto. Al contrario, se si disabilita semplicemente la verifica, si è aperti a qualsiasi tipo di attacco man-in-the-middle in qualsiasi momento .

Per dare un esempio specifico: il famoso repository repo.or.cz fornisce un certificato autofirmato . Posso scaricare quel file, metterlo da qualche parte come /etc/ssl/certs , e poi fare:

 # 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 

Si noti che l’uso di git config --global locale qui (cioè senza --global ) significa che questo certificato autofirmato è affidabile solo per questo particolare repository, che è bello. È anche più bello dell’utilizzo di GIT_SSL_CAPATH poiché elimina il rischio che git GIT_SSL_CAPATH la verifica tramite un’Autorità di certificazione diversa che potrebbe potenzialmente essere compromise.

Global .gitconfig per le autorità di certificazione autofirmate

Per l’amor mio e dei miei colleghi, ecco come siamo riusciti a far funzionare i certificati autofirmati senza disabilitare sslVerify . Modifica il tuo .gitconfig per usare git config --global -e aggiungi questi:

 # 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 

Riferimenti:

  • Git Credentials
  • Git Credential Store
  • Utilizzo di Gnome Keyring come archivio di credenziali
  • Git Config http. . * Supportato da Git v1.8.5

Specificare config quando git clone -ing

Se è necessario applicarlo su base repo, la documentazione ti dice di eseguire git config --local nella tua directory repo. Beh, questo non è utile quando non hai il repository clonato localmente, ma ora è così?

Puoi fare il global -> local hokey-pokey global -> local impostando la tua configurazione globale come sopra e poi copiare quelle impostazioni nella tua configurazione di repo locale una volta clonata …

OPPURE quello che puoi fare è specificare i comandi di configurazione di git clone che vengono applicati al repository di destinazione una volta clonato.

 # 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/ 

Una fodera

EDIT: vedi la risposta di VonC che indica un avvertimento sui percorsi assoluti e relativi per specifiche versioni git da 2.14.x / 2.15 a questa unica fodera

 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

Se stai provando questo su CentOS e il tuo file .pem ti sta dando

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

Quindi vorrai questa risposta StackOverflow su come curl usa NSS invece di Open SSL.

E ti piacerà ribuild il curl dalla fonte :

 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 

riavvia computer poiché libcurl è ancora in memoria come libreria condivisa

Continuo a riscontrare questo problema, quindi ho scritto uno script per scaricare il certificato autofirmato dal server e installarlo su ~ / .gitcerts, quindi aggiornare git-config in modo che punti a questi certificati. È memorizzato nella configurazione globale, quindi è sufficiente eseguirlo una volta per remoto.

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

Fai attenzione quando stai usando una fodera usando sslKey o sslCert, come nella risposta di Josh Peak :

 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 

Solo Git 2.14.x / 2.15 (3 ° trim. 2015) sarebbe in grado di interpretare correttamente un percorso come ~username/mykey (mentre può ancora interpretare un percorso assoluto come /path/to/privatekey ).

Vedi commit 8d15496 (20 lug 2017) di Junio ​​C Hamano ( gitster ) .
Helped-by: Charles Bailey ( hashpling ) .
(Unita da Junio ​​C Hamano – gitster – in commit 17b1e1d , 11 ago 2017)

http.c : http.sslcert e http.sslkey sono entrambi i percorsi

Indietro quando il moderno codepath http_options () è stato creato per analizzare varie opzioni http. * Su 29508e1 (“Isolate funzionalità di richiesta HTTP condivisa”, 18-11-2005, Git 0.99.9k), e successivamente è stato corretto per l’interation tra il multiplo file di configurazione in 7059cd9 (” http_init() : analisi del file config di correzione”, 2009-03-09, Git 1.6.3-rc0), abbiamo analizzato le variabili di configurazione come http.sslkey , http.sslcert come semplici stringhe di vaniglia, perché git_config_pathname() che capisce che il prefisso ” ~[username]/ ” non esiste.

Successivamente, abbiamo convertito alcuni di essi (ovvero http.sslCAPath e http.sslCAInfo ) per utilizzare la funzione e aggiunto variabili come http.cookeyFile http.pinnedpubkey per utilizzare la funzione dall’inizio. Per questo motivo, tutte queste variabili comprendono il prefisso ” ~[username]/ “.

Rendi anche le restanti due variabili, http.sslcert e http.sslkey , consapevoli della convenzione, poiché sono entrambi chiaramente i nomi dei percorsi dei file.

Questa risposta è tratta da questo articolo scritto da Michael Kauffman.

Usa Git per Windows con un certificato SSL aziendale

Problema :

Se si dispone di un certificato SSL aziendale e si desidera clonare il repository dalla console o dal VSCode si ottiene il seguente errore:

fatale: imansible accedere a ‘ https: // myserver / tfs / DefaultCollection / _git / Proj / ‘: problema del certificato SSL: imansible ottenere il certificato emittente locale

Soluzione :

  1. Esportare il certificato autofirmato di root in un file. Puoi farlo dal tuo browser.

  2. Individua il file “ca-bundle.crt” nella tua cartella git (versione corrente C: \ Programmi \ Git \ usr \ ssl \ certs ma è cambiato in passato). Copia il file sul tuo profilo utente. Aprilo con un editor di testo come VSCode e aggiungi il contenuto del tuo certificato esportato alla fine del file.

Ora dobbiamo configurare git per usare il nuovo file:

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

Questo aggiungerà la seguente voce al tuo file .gitconfig nella root del tuo profilo utente.

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

Controlla le tue impostazioni antivirus e firewall.

Da un giorno all’altro, git non ha funzionato più. Con quanto descritto sopra, ho scoperto che Kaspersky inserisce nel mezzo un certificato di autenticazione personale antivirus autofirmato. Non sono riuscito a far accettare a Git quel certificato seguendo le istruzioni di cui sopra. Ho rinunciato a questo. Ciò che funziona per me è disabilitare la funzionalità per Scansionare connessioni criptate.

  1. Apri Kaspersky
  2. Impostazioni> Ulteriori> Rete> Non eseguire la scansione delle connessioni crittografate

Dopo questo, git funziona di nuovo con sslVerify abilitato.

Nota. Questo non è ancora soddisfacente per me, perché mi piacerebbe avere quella caratteristica del mio Anti-Virus attivo. Nelle impostazioni avanzate, Kaspersky mostra un elenco di siti Web che non funzionano con quella funzione. Github non è elencato come uno di loro. Lo controllerò nel forum di Kaspersky. Sembrano esserci alcuni argomenti, ad esempio https://forum.kaspersky.com/index.php?/topic/395220-kis-interfering-with-git/&tab=comments#comment-2801211

Nel file .gitconfig è ansible aggiungere il valore indicato sotto per rendere accettabile il certificato autofirmato

sslCAInfo = /home/XXXX/abc.crt

Usando la versione a 64 bit di Git su Windows, basta aggiungere il certificato CA autofirmato in questi file:

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

Se è solo un certificato autofirmato del server, aggiungilo a

  • C: \ Programmi \ Git \ mingw64 \ ssl \ cert.pem

Esegui il seguente comando:

 git config --global http.sslVerify false