Tecnología · GUÍA PRÁCTICA
¿curl error 60? Audita la cadena y el almacén de confianza antes de --insecure
“Unable to get local issuer certificate” no tiene una solución universal. Registra backend TLS, CAfile, CApath y proxy; después corrige la cadena del servidor, la confianza del cliente o el proxy de inspección.
curl error 60 es un fallo de verificación, no una orden para desactivarla. El eslabón puede estar en la cadena del servidor, la entrada de confianza de curl, un paquete propio de la aplicación o un proxy TLS.
Audita en orden: destino, cadena, backend, confianza y reparación. La evidencia decide si corregir el servidor, instalar una CA privada verificada, elegir el almacén previsto o reparar la confianza del proxy.
Congelar el destino y la compilación de curl
Antes de cambiar confianza, registra URL, host, puerto, usuario, variables de proxy y error completo. Usa curl -V para el backend TLS y curl -v para CAfile, CApath, destino y proxy CONNECT. Un navegador correcto solo demuestra su propia ruta de confianza.
Reproduce desde el shell, contenedor o cuenta de servicio que falla. root, PHP, Git y Composer pueden leer ajustes distintos. Si -k funciona solo prueba el límite de verificación; quítalo de inmediato.
Inspeccionar la cadena realmente presentada
Examina host y puerto exactos con SNI; registra subject, issuer e intermedios enviados. Si un sitio público omite un intermedio, corrige la cadena del servidor y prueba desde un cliente limpio. No conviertas la hoja en raíz.
Si un dispositivo de seguridad termina TLS, el issuer puede ser corporativo. Demuestra la ruta con curl -v y variables. La confianza del proxy HTTPS está separada de la del origen.
Probar qué confianza usa esta compilación
Schannel suele usar el almacén nativo de Windows; otros backends suelen usar archivos. Revisa CURL_CA_BUNDLE, SSL_CERT_FILE, SSL_CERT_DIR, la aplicación y montajes del contenedor antes de reemplazar paquetes.
Usa --cacert solo con una CA PEM verificada y --capath con un directorio preparado. Usa --ca-native si la compilación y la política lo requieren. En Apple se puede combinar confianza nativa y archivo propio.
Aplicar la reparación mínima verificada
Corrige el servidor si falta un intermedio. Para una CA privada o corporativa, verifica huella y propietario por un canal autenticado y confía en el ámbito mínimo. Ubuntu y Red Hat documentan ubicaciones y comandos diferentes.
Si falla una aplicación, repara su ruta CA; si falla el proxy HTTPS, usa controles CA del proxy. Si el issuer es inesperado, detente y escala: no lo importes.
Reprobar verificación, alcance y reversión
Prueba sin -k ni sobrescrituras; confirma host, issuer, backend y CA en salida detallada, luego prueba la aplicación y un entorno limpio. Un --cacert puntual no demuestra que otros runtimes lean el archivo.
Documenta evidencia, cambio de confianza, dueño, caducidad y reversión. Prueba una cadena del servidor desde varios clientes y una CA privada también en su eliminación.
