Después de la última actualización (de hecho, hice una nueva instalación) de git para Windows ya no puedo conectarme a un repositorio remoto específico a través de https. Está en un servidor interno que utiliza una certificado autofirmado que también ha expirado por un tiempo (no preguntes).

olía funcionar con git para Windows 2.16.x (iirc) y continúa trabajando con instalaciones paralelas en cygwin y mysys2 (que informan las versiones 2.17.0 y 2.20.1, respectivamente).

Esto es lo que probé (no todos al mismo tiempo):

He configurado la opción de configuraciónhttp.sslverify=false en todas las ubicaciones informadas porgit config -l --show-origin y verificó que sslverify no es cierto en ninguna parte. En particular, en el repositorio local .git / config que debe anular cualquier configuración predeterminada o explícita del sistema o global, es falso.

He cambiado lahttp.sslbackend opción parasChannel y luego de vuelta aopenssl; el mensaje de error cambia, lo que indica que la configuración fue efectiva, pero sigue siendo un mensaje de error. Hay publicaciones que indican que la nuevasChannelo se puede evitar por completo que el mecanismo @ verifique los certificados, por lo que quería asegurarme de que todavía no lo estoy usando accidentalmente. (Aparentemente, es el mecanismo predeterminado en una nueva instalación).

También descargué el certificado y dirigí openssl para usarlo editando~/.ssl/config; desafortunadamente, esto solo lleva a git (o más bien, openssl) a rechazar el certificado porque está vencido.

Establecí la variable de entorno GIT_SSL_NO_VERIFY en "true", que debería anular todas las configuracione

Usé las variables de entornoGIT_TRACE_CURL=path, GIT_TRACE yGIT_CURL_VERBOSE para obtener resultados de depuración que no mostraron nada sorprendente más allá del hecho de que openssl intentó verificar el certificado y falló, lo cual es correcto siempre que intente verificarlo en absoluto. P.ej. el archivo de rastreo contendría la líneaInfo: SSL certificate problem: self signed certificate, que es todo correcto.

Las otras instalaciones de git (resp. Openssl) parecen omitir la verificación completa del certificado, aunque eso es lo que necesitamos bajo las circunstancias.

¿Es esto un error? ¿Algunas ideas

Edit: El problema tiene que ver con la configuración del proxy https. En mi entorno, estoy detrás de un proxy HTTPS pero se debe acceder directamente al servidor de repositorios. Tengo las variables https_proxy y no_proxy establecidas para eso. Para excluir todas las demás configuraciones de entorno, utilicéenv -i (que inicia un programa sin conjunto de variables de entorno eny) con dos configuraciones diferentes. Tenga en cuenta que mantuve mi ruta original que tiene los directorios de instalación de git primero. La única diferencia es que en el calll que falla, que viene primero, https_proxy se establece en una cadena que comienza con "https: //" (lagarbage parte es literal para dejar en claro que no es un host válido):

La configuración de SSL es

git config -l |grep -i ssl
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslverify=false
http.sslbackend=openssl

env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" <strong>https_proxy="https://garbage"</strong> git fetch 16:41:53.953829 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin 16:41:53.955829 git.c:418 trace: built-in: git fetch 16:41:53.980831 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a> 16:41:54.001834 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core 16:41:54.003834 git.c:675 trace: exec: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a> 16:41:54.003834 run-command.c:643 trace: run_command: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a> 16:41:54.028836 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core * Couldn't find host [repo host FQDN] in the _netrc file; using defaults * Trying [repo host IP address]... * TCP_NODELAY set * Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt CApath: none * SSL certificate problem: self signed certificate * Closing connection 0 fatal: unable to access '<a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a>': SSL certificate problem: self signed certificate

El comando funciona si elhttps_proxy variable no comienza conhttps://. Los registros son casi idénticos hasta la líneaCApath: none, excepto que hay una línea donde curl reconoce lano_proxy ajuste

env -i PATH="$PATH" GIT_CURL_VERBOSE=1 GIT_TRACE=2 no_proxy="[repo host FQDN]" <strong>https_proxy=""</strong> git fetch 17:04:56.884616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/bin 17:04:56.886616 git.c:418 trace: built-in: git fetch 17:04:56.911616 run-command.c:643 trace: run_command: GIT_DIR=.git git remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a> 17:04:56.931616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core 17:04:56.932616 git.c:675 trace: exec: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a> 17:04:56.932616 run-command.c:643 trace: run_command: git-remote-https origin <a href="https://[FQDN/path-to-git]" rel="nofollow">https://[FQDN/path-to-git]</a> 17:04:56.957616 exec-cmd.c:236 trace: resolved executable dir: D:/Programs/Git/mingw64/libexec/git-core * <strong>Uses proxy env variable no_proxy == '[repo host FQDN]'</strong> * Couldn't find host [repo host FQDN] in the _netrc file; using defaults * Trying [repo host IP address]... * TCP_NODELAY set * Connected to [repo host FQDN] ([repo host IP address]) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: D:/Programs/Git/mingw64/ssl/certs/ca-bundle.crt CApath: none * <strong>SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384</strong> * ALPN, server accepted to use http/1.1 * Server certificate: [... certificate details incl. past expiration date; successful communication]