GitHub Enterprise Cloud con residencia de datos dejará de aceptar el 7 de octubre de 2026 conexiones HTTPS de clientes que ofrezcan únicamente X25519 para el intercambio de claves TLS. Los sistemas afectados deberán habilitar al menos P-256 (secp256r1); P-384 seguirá también soportado, según el aviso oficial publicado por GitHub el 30 de septiembre.
Quién puede quedar sin conexión
GitHub indica que la mayoría de clientes actuales no necesita hacer nada. Navegadores modernos, sistemas operativos recientes, GitHub CLI y las librerías TLS habituales ya soportan P-256.
El riesgo está en aplicaciones, proxies, appliances de seguridad o runtimes configurados expresamente para ofrecer solo X25519. Después del 7 de octubre, esos clientes no podrán establecer conexiones HTTPS con los endpoints afectados de GHE.com.
Qué debe comprobar una empresa antes de la fecha
GitHub recomienda actualizar sistema operativo, runtime, GitHub CLI, proxy y librerías TLS a versiones soportadas. Además, hay que retirar cualquier configuración “X25519 only” y comprobar que secp256r1 esté habilitado. P-384 puede mantenerse como alternativa adicional.
Una empresa debería revisar especialmente proxies corporativos, herramientas antiguas de CI/CD, appliances de inspección TLS y software integrado que conecte automáticamente con GitHub.
El cambio no afecta a SSH
La retirada se aplica a HTTPS en GitHub Enterprise Cloud con data residency. GitHub aclara que las conexiones SSH no se ven afectadas y que el cambio no se extiende de forma general a todas las modalidades de GitHub Enterprise.
Por tanto, antes de abrir una incidencia de conectividad conviene identificar si el fallo se produce en HTTPS y si la organización utiliza específicamente GHE.com con residencia de datos.
Cómo probarlo sin esperar al 7 de octubre
Los responsables de infraestructura pueden inventariar los clientes que salen hacia GitHub y validar los grupos de curva elíptica ofrecidos durante el handshake. La prioridad debería ponerse en procesos automáticos: pipelines, sincronizadores, herramientas de seguridad y servicios que podrían dejar de funcionar sin que un usuario vea inmediatamente el error.
Después de actualizar, conviene ejecutar operaciones reales —clone, fetch, push y llamadas API— desde los entornos críticos para confirmar que la negociación TLS funciona con P-256.
Para reforzar la misma cadena de desarrollo pueden revisarse también la actualización de GitHub CodeQL, el proof of presence, las métricas de revisión, las propiedades externas de repositorios, el parche crítico de GitLab y la adopción de passkeys empresariales.
El plazo deja menos de una semana para revisar sistemas heredados. Si una organización utiliza appliances o runtimes mantenidos por terceros, debería pedir al proveedor confirmación explícita de soporte para P-256 y no limitarse a validar un navegador de escritorio, porque las conexiones que suelen fallar tras este tipo de cambios son precisamente las automatizadas.
Fotografía: Lukas Blazek / Pexels.
