SSL: 'no se puede get el certificate de emisor local'

Estoy usando OSX: 10.12.4

Originalmente pude usar git, homebrew y curl sin ningún problema. No recuerdo lo que hice para causarlo, pero de repente estos errores SSL comenzaron a aparecer en mis commands de git.

No puedo get errores de unable to get local issuer certificate al ejecutar cualquier command de git. Además, aparece el error al intentar reinstalar git usando brew install git .

La parte relevante de la producción de cerveza:

 Downloading https://www.kernel.org/pub/software/scm/git/git-2.12.2.tar.xz curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html 

Yo he tratado:

  • Reiniciando
  • Mover la carpeta ~ / Library / Keychains a ~ / Desktop y luego reiniciar
  • Navegando a https://www.kernel.org/pub/software/scm/git en safari, y viendo el certificate . De acuerdo con [estas instrucciones] (no se pueden publicar más de 2 enlaces, lo siento), debe haber una checkbox para "Confiar siempre" en el sitio. No veo esta checkbox.
  • Iba a probar los primeros auxilios con el llavero, sin embargo, esta característica se eliminó en el sistema operativo Mac más reciente.
  • Traté de mirar a través de muchas otras preguntas similares, sin embargo, con muchas, tuve problemas para entender o seguir las instrucciones en las respuestas.

Por ejemplo, quizás la respuesta de squid808 a una pregunta similar podría ayudarme. Él dice: "En cambio, es el certificate de CA raíz de nuestro dominio que debería haber estado exportando y decirle a Git que confíe". Tengo poco conocimiento de lo que esto significa o si es relevante para mí, o cómo voy a hacer esto. Según mi investigación, parece que esto es más para las personas que ejecutan serveres. También parece ser para Windows, y estoy en Mac.

Entiendo que como solución temporal puedo usar git config --global http.sslVerify false además de la opción -k en curl. Estas soluciones temporales son inseguras, por lo que me gustaría que mi security SSL vuelva a funcionar lo antes posible.

Salida de curl -L https://homebrew.bintray.com/bottles/libpng-1.6.29.sierra.bottle.tar.gz | bash -s stable curl -L https://homebrew.bintray.com/bottles/libpng-1.6.29.sierra.bottle.tar.gz | bash -s stable (parte de un bash de preparación que también falla)

  % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expinetworking, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. 

Disculpas

  • Si los siguientes bashs que he hecho para resolver esto parecen dispersos y desorganizados, es porque estoy confundido si este es un problema más relevante para git, curl o quizás ninguno de los certificates SSL en general. Por favor, avíseme si las tags para esta pregunta deberían ser corregidas.
  • Podría haber publicado enlaces e imágenes más relevantes, pero estoy limitado por la reputación.

Tengo otra count en la que no pude mantener una reputación positiva. Estoy tratando de identificar y arreglar todo lo que estaba haciendo mal antes. Cualquier comentario sobre cómo puedo mejorar la calidad de esta pregunta sería muy apreciado. Gracias.

Esto es similar a lo que se informó en Homebrew / brew issue 1625 , y documentado por Eduard Rozenberg ( edrozenberg ) :

Problemas similares también informados por John Siracusa de ATP Podcast en el podcast del 7 de diciembre.

Lo más probable es que desencadene el problema: habilitar iCloud Keychain en la configuration de iCloud

Uno o más síntomas observables cuando ocurre un problema:

  • Un post emergente de MacOS que keychain tiene que ser reparado / reseteado
  • Al mirar la herramienta de acceso a Llaveros, los llaveros parecen estar vacíos y configurados en modo de solo lectura
  • Cuando se mira la herramienta Acceso a Llaveros, faltan icons de llavero en la barra lateral (bordes punteados)
  • Intentando navegar a https://google.com en Google Chrome falla con un error CERT SSL Ejecutando brew search pip por ejemplo, muestra el post de error de certificate curl (35)

El problema se puede resolver temporalmente al cerrar la session y volver a iniciarla y / o reiniciar. Una vez resuelto, la herramienta de Acceso a Llaveros mostrará todos los llaveros y su contenido como debería. Es probable que el problema se repita en un momento posterior.

Esperando (dedos X) que un parche de Mac OS (quizás 10.12.2) resuelva la causa raíz.

De lo contrario, una idea es desactivar la opción iCloud Keychain en iCloud prefs (aún no lo hemos probado).

Desde que estás en Mac Sierra 10.12.4 … sospecho que ningún parche resuelve esto todavía.

Este otro tema menciona (por jamver ):

Me encontré con este problema específicamente después de actualizar a macOS Sierra (10.12), con la resolución proveniente de la solución alternativa de este ticket henetworkingado-homebrew:

 cd ~ sudo wget http://curl.haxx.se/ca/cacert.pem export CURL_CA_BUNDLE=~/cacert.pem 

FWIW, esto resolvió la mayoría, pero no todos los problemas. Los otros los resolví descargando manualmente los packages usando wget y colocándolos en la Dir de caching de Homebrew.

Me interesaría saber la solución correcta. por ejemplo, actualizar el package de sistema ca? ¿Se requiere un parche de Apple para el package del sistema?

Necesitaba ejecutar el brew doctor y solucionar un problema. Entonces necesité reiniciar mi caparazón. Finalmente, después de esos 2 pasos, la installation de preparación funcionó de nuevo.

Lamentablemente, no pude identificar qué advertencia apuntaba al autor. La primera vez que funcionó brew doctor , probablemente hubo alnetworkingedor de 10 advertencias. Limpié muchos de ellos antes de darme count de que necesitaba reiniciar mi caparazón, y después de reiniciarlo funcionó.


Creo que encontré la raíz del problema:

 Warning: Setting DYLD_* vars can break dynamic linking. Set variables: DYLD_LIBRARY_PATH: /Applications/MATLAB/MATLAB_Runtime/v92/runtime/maci64:/Applications/MATLAB/MATLAB_Runtime/v92/sys/os/maci64:/Applications/MATLAB/MATLAB_Runtime/v92/bin/maci64 

Comentando la línea

 set -x DYLD_LIBRARY_PATH /Applications/MATLAB/MATLAB_Runtime/v92/runtime/maci64:/Applications/MATLAB/MATLAB_Runtime/v92/sys/os/maci64:/Applications/MATLAB/MATLAB_Runtime/v92/bin/maci64 

en ~/.config/fish/config.fish y luego reiniciar mi caparazón parece solucionar el problema hasta ahora.


Gracias @VonC por hacer reference al problema que me llevó a intentar brew doctor .