SSL CERTIFICATE_VERIFY_FAILED vía proxy

¿Qué significa SSL: CERTIFICATE_VERIFY_FAILED?

Durante el apretón de manos TLS, el sitio envía una cadena de certificados. Tu cliente la verifica contra una lista de autoridades confiables, el almacén de confianza, y comprueba nombres y fechas. Si alguna verificación falla, se detiene.

Con un túnel CONNECT, el proxy pasa el apretón de manos sin tocarlo, así que el certificado que ves es el del propio sitio. Algo que inserte su propio certificado, como software de inspección, o un almacén de confianza obsoleto en tu máquina, es la causa habitual.

¿Cómo se ve CERTIFICATE_VERIFY_FAILED en Python, curl, Node.js y navegadores?

El mismo fallo se muestra de forma diferente en cada herramienta. Estos son los mensajes que debes buscar en tus registros:

• Python: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate
• Node.js: UNABLE_TO_GET_ISSUER_CERT_LOCALLY o SELF_SIGNED_CERT_IN_CHAIN
• curl: curl: (60) SSL certificate problem: unable to get local issuer certificate
• Navegadores: NET::ERR_CERT_AUTHORITY_INVALID

¿Qué causa CERTIFICATE_VERIFY_FAILED?

Lo más probable al principio:

• Un bundle CA desactualizado, por ejemplo un paquete certifi antiguo en Python.
• Inspección HTTPS por antivirus, un cortafuegos corporativo o un proxy de depuración, que presenta su propio certificado.
• Un reloj del sistema incorrecto que hace que certificados válidos parezcan expirados o no válidos aún.
• Un sitio con una cadena rota, con certificado intermedio faltante.
• Una imagen de contenedor sin el paquete de certificados CA del sistema.

¿Cómo diagnostico CERTIFICATE_VERIFY_FAILED paso a paso?

1. Ejecuta la misma solicitud sin el proxy. Si también falla, el proxy no está involucrado.
2. Imprime el emisor del certificado con openssl s_client o curl -v: un emisor con nombre de tu antivirus o cortafuegos indica intercepción.
3. Revisa la fecha y hora del sistema.
4. Actualiza el bundle CA y prueba otra vez.

# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:[email protected]:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL

¿Cómo soluciono CERTIFICATE_VERIFY_FAILED?

• Actualiza certifi (pip install -U certifi) o el paquete CA de tu sistema.
• Añade el certificado de inspección de tu empresa al almacén de confianza si tu red requiere inspección, o ejecuta el scraper fuera de esa red.
• Corrige el reloj con sincronización de tiempo en red.
• Instala certificados CA en imágenes de contenedor slim, por ejemplo el paquete ca-certificates.
• No desactives la verificación en código que envía credenciales o recoge datos que usas.

¿Debo reintentar después de CERTIFICATE_VERIFY_FAILED?

No reintentes: el mismo almacén de confianza falla igual. Arregla el almacén, el reloj o la ruta de red, y vuelve a ejecutar.

¿Cómo se aplica SSL: CERTIFICATE_VERIFY_FAILED a CrawlRelay?

El puerto HTTP de CrawlRelay encapsula HTTPS con CONNECT, así que el certificado que tu cliente comprueba es el que envía el sitio. Si el error aparece solo a través de la pasarela y nunca sin ella, contacta con soporte con el hostname objetivo y el error completo para que revisemos el lado de salida.

Gateway: gw.crawlrelay.com, puerto 7777 (HTTP, HTTPS a través de CONNECT) y puerto 7778 (SOCKS5). Formato de usuario: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. Relacionado: SSL: WRONG_VERSION_NUMBER · Conexión restablecida · Guía Python.