¿LaLiga bloquea GlobalSign y deja a España sin HTTPS?

El bloqueo ligado a LaLiga alcanzó servicios de GlobalSign y provocó fallos HTTPS en España: OCSP, Cloudflare y cortes por IP, con contexto.

La mañana del miércoles 18 de febrero de 2026 se coló un fallo raro —de esos que no avisan con sirenas, pero te desordenan la red por dentro— en el ecosistema de seguridad web: varias conexiones HTTPS empezaron a dar problemas porque algunos navegadores y clientes no podían completar la verificación del estado de certificados vinculados a GlobalSign. El detonante, según lo que se fue compartiendo en tiempo real en un foro técnico español, fue un bloqueo asociado a LaLiga que alcanzó infraestructura relacionada con el dominio globalsign.com, justo donde se atienden comprobaciones clave para validar certificados. La sensación, para quien lo sufrió en un servicio corporativo o en una administración remota, fue la de un candado perfecto… al que le han quitado la llave sin tocar la puerta.

El caso no es “se ha caído una web” y ya: lo que se vio fue una interrupción en una pieza que trabaja en segundo plano, silenciosa, con nombre poco glamuroso, pero central: la validación de revocación. En el hilo que encendió la alarma, firmado por Claustronegro y publicado a las 12:50 tras movimientos detectados ya hacia las 10:03, se apuntaba un detalle con mucha miga: algunas direcciones IP ligadas a globalsign.com parecían estar sirviéndose mediante un CDN de Cloudflare, lo que encaja con el patrón de “bloqueo por IP” que, cuando se aplica con brocha gorda, termina rozando cosas que no iban en el paquete. En una frase que sonó a ironía amarga, se decía también que “menos mal que no es crítico”… y acto seguido, el aviso: algún día esto puede acabar mal de verdad, con consecuencias que no sean solo pantallas de error.

El bloqueo que saltó del fútbol a la seguridad web

Lo que se atribuye a LaLiga no es que haya “apagado Internet” a propósito, sino que un mecanismo de bloqueo asociado a su batalla contra la piratería —y ejecutado a nivel de red por quienes aplican esos cortes— habría terminado afectando a un servicio ajeno al fútbol: el que permite a muchos sistemas comprobar si un certificado está vigente o ha sido revocado. Esta distinción importa porque cambia el enfoque: no es un fallo interno de GlobalSign ni un ataque directo contra una autoridad certificadora, sino el tipo de daño colateral que aparece cuando se corta tráfico por IP en un Internet donde muchas cosas comparten autopista.

El contexto ayuda a entender por qué esta clase de episodios se repite con un aire de déjà vu. La lucha antipiratería en eventos deportivos suele concentrarse en ventanas temporales muy concretas, con cortes que buscan impedir que determinadas señales o servicios se mantengan accesibles durante los partidos. El problema es que el tráfico moderno no va “dominio por dominio” con etiquetas grandes, como si cada web tuviera su carril exclusivo: va comprimido, distribuido, mezclado. Y cuando un bloqueo se hace por dirección IP o por rangos amplios, lo que se corta no es “la web mala”, sino todo lo que viva —aunque sea legítimo— en esa misma dirección o en esa misma red compartida.

En ese punto entra la sospecha técnica que se mencionó desde el primer momento: la presencia de un CDN de Cloudflare detrás de algunas IP asociadas a globalsign.com. Un CDN, por diseño, concentra muchísimo tráfico de sitios distintos para mejorar rendimiento y resiliencia. Eso es precisamente lo que lo hace útil… y a la vez peligroso en un escenario de bloqueos por IP: se puede acertar el objetivo y, sin querer, tumbar a una fila entera de vecinos. La expresión “falsos positivos” se queda corta cuando lo que cae no es un blog cualquiera, sino parte de la mecánica que mantiene la confianza del candado HTTPS.

GlobalSign y esa comprobación que casi nadie ve

GlobalSign es una autoridad de certificación con peso real en el mercado: emite certificados digitales que permiten a miles de servicios operar bajo TLS/HTTPS con identidad validada. Pero lo importante aquí no es la marca en sí, sino el engranaje que acompaña a cualquier certificado: la posibilidad de saber, en el momento de usarlo, si ese certificado sigue siendo válido o si ha sido retirado por algún motivo. La retirada —la revocación— existe para cuando un certificado se comprometió, se emitió mal, se detectó abuso o se necesita invalidarlo antes de su fecha de caducidad. Y si la revocación existe, alguien tiene que responder a la pregunta incómoda: “¿sigue bien este certificado?”.

Ahí aparecen dos mecanismos clásicos, con nombres que suenan a manual de laboratorio pero son rutina diaria: las CRL (listas de revocación) y el OCSP (Online Certificate Status Protocol). En la práctica moderna, OCSP suele ser el camino rápido: el cliente pregunta a un servidor OCSP y recibe una respuesta corta del tipo “good”, “revoked” o “unknown”. No siempre se ve, no siempre se entiende, pero ocurre miles de veces por segundo en el planeta. Y cuando esa consulta falla por un bloqueo de red, la reacción depende de algo decisivo: si el cliente aplica un modelo soft-fail (si no puedo comprobarlo, sigo) o hard-fail (si no puedo comprobarlo, corto).

El dominio globalsign.com y subdominios asociados a OCSP son relevantes porque ahí viven, en muchos casos, los endpoints que responden esas consultas. En el caso que estalló hoy, lo que se comentó es que el bloqueo alcanzó precisamente ese tipo de recursos, dejando a ciertos sistemas sin la posibilidad de hacer la comprobación. En un navegador doméstico puede pasar desapercibido porque muchos navegadores tienden a no romper navegación por un fallo puntual de OCSP. Pero en otros contextos —clientes más estrictos, configuraciones corporativas, librerías TLS usadas por aplicaciones críticas— la historia cambia: si la verificación no se puede completar, la conexión no prospera, aunque el servidor esté bien y el certificado sea legítimo.

OCSP: el semáforo de la revocación

La metáfora del semáforo funciona porque OCSP no es el motor del coche, pero sí la señal que evita que se crucen en rojo. La consulta OCSP permite a un cliente verificar el estado de un certificado sin descargarse listas enormes y sin esperar demasiado. El problema es que, si el camino hacia el servidor OCSP está bloqueado, el semáforo deja de funcionar. Y entonces cada conductor —cada navegador o cada cliente— decide a su manera: hay quien avanza con precaución, hay quien frena en seco.

En la conversación técnica que se fue extendiendo alrededor del bloqueo, se mencionó además un elemento que complica el asunto, porque hace que el fallo se note justo donde duele: el OCSP stapling. El stapling es una mejora: en vez de que el cliente vaya a preguntar por su cuenta, el servidor web entrega “pegada” (stapled) una respuesta OCSP reciente dentro del propio saludo TLS. Eso acelera, reduce consultas y mejora privacidad. Pero obliga al servidor a poder renovar esa respuesta regularmente. Si el servidor no puede llegar al OCSP para refrescarla, se queda sin “prueba fresca” y algunos clientes, al verla caducada o ausente, aplican hard-fail y rompen la conexión.

El stapling y el efecto dominó silencioso

Este detalle explica por qué el impacto puede ser desigual y confuso: no todas las webs usan stapling, no todos los servidores lo mantienen igual, no todos los clientes lo exigen. El mismo servicio puede ir bien desde una red y fallar desde otra; puede ir bien en un navegador y fallar en una aplicación que usa una librería TLS concreta; puede ir bien un rato y luego caer cuando la respuesta stapled caduca y el servidor no consigue renovarla. Es el tipo de fallo que desespera a un equipo técnico porque no deja un patrón “limpio”; deja un patrón vivo, intermitente, con mala leche.

Si el bloqueo afectó a IPs que servían contenido de globalsign.com a través de Cloudflare, el síntoma puede ser aún más caprichoso: depende de la ruta, del resolvedor DNS, de si se está usando IPv4 o IPv6, de qué nodo del CDN responde en ese momento, de qué operadora aplica el bloqueo y cómo. Eso convierte algo que, en teoría, es un corte puntual, en un puzle de comportamientos. Y en seguridad, los puzles no son amigos: cuando algo parece aleatorio, la confianza se desgasta.

El atajo del bloqueo por IP y el problema de las direcciones compartidas

La historia técnica aquí no es solo “se bloqueó un dominio”, sino el método: bloquear por IP en un entorno donde IP ya no significa “un sitio”, sino “un edificio con cien puertas”. El viejo Internet permitía imaginar cada web como una dirección clara; el Internet de CDNs y cloud convierte direcciones en hubs. Una única IP puede servir cientos o miles de dominios, y un único dominio puede resolverse en diferentes IPs según geografía y carga. En ese escenario, cortar por IP es rápido, sí; también es arriesgado. Y la palabra “arriesgado” se queda corta cuando lo que queda atrapado es parte de la infraestructura de certificados digitales.

En el caso de hoy, el hilo original apuntaba que “efectivamente, como sospechábamos” algunas IPs del dominio estaban usando Cloudflare. Esa frase tiene doble lectura: por un lado, sugiere que ya se venía observando un patrón de bloqueos durante eventos deportivos; por otro, deja claro que el impacto no fue teórico, sino medible en la práctica, con trazas de conectividad y resoluciones que mostraban el salto hacia un CDN. Que una autoridad certificadora use un CDN no es raro: busca disponibilidad y latencia baja. Lo raro es que esa capa, diseñada para proteger, termine siendo la vía por la que un bloqueo antipiratería rompe validaciones de seguridad.

Hay además un componente incómodo: cuando se toca el sistema de confianza, el daño no es solo “no entra la web”, sino que se altera el comportamiento de seguridad de los usuarios y de las máquinas. Si un usuario ve avisos de certificado en servicios legítimos, puede empezar a ignorarlos. Si un administrador necesita restablecer servicio rápido, puede desactivar verificaciones, relajar políticas o cambiar configuraciones a la carrera. El resultado final puede ser peor que el problema original: seguridad degradada por un corte que, en teoría, era “contra la piratería”.

Una intrusión involuntaria en la cadena de confianza

La cadena de confianza de HTTPS no está hecha para soportar que alguien corte, sin coordinación, un servicio de revocación. Está hecha para resistir caídas puntuales —y de ahí el comportamiento tolerante de algunos navegadores—, pero también para funcionar con reglas claras. Cuando se introduce un actor externo que bloquea tráfico por criterios ajenos a la seguridad web, se crea una tensión: o se rompe el acceso a servicios legítimos, o se normaliza la idea de que la revocación “da igual”. Y ambas opciones son malas. Una porque deja servicios fuera; la otra porque deja puertas abiertas cuando deberían cerrarse.

En términos prácticos, este tipo de bloqueos erosiona una de las promesas básicas de HTTPS: “si ves el candado, puedes confiar”. Porque la confianza no es solo el icono; es todo el proceso de verificación. Si el proceso se interrumpe, el candado puede desaparecer o convertirse en advertencia. Y si el candado se vuelve caprichoso —aparece, desaparece, depende del partido, depende de la operadora—, el sistema deja de ser una señal fiable.

Qué falló de verdad en la práctica y cómo se notó

Los síntomas que suelen aparecer cuando hay problemas en validación TLS ligados a OCSP y revocación son bastante reconocibles para quien administra servicios, pero desconcertantes para quien solo navega. Aparecen avisos de conexión no privada, errores SSL genéricos, fallos de “handshake”, mensajes de certificado no válido, y en ciertos clientes, directamente un “no se pudo establecer conexión segura”. Lo perverso es que muchas veces no pasa en todas partes: una web puede cargar en un navegador y fallar en un script de automatización; puede funcionar en un móvil y fallar en un equipo de oficina; puede ir bien desde una red y fallar desde otra. Eso encaja con un escenario en el que parte del tráfico hacia endpoints de verificación queda bloqueado por rutas específicas.

En un caso como este, lo que se rompe no es el servidor final necesariamente. Se rompe la posibilidad de obtener una respuesta OCSP, o de renovar una respuesta stapled. Si un servidor web usa stapling y su política es estricta, puede negarse a servir sin una respuesta válida, o el cliente puede negarse a aceptar una respuesta caducada. El efecto es inmediato: aunque el certificado sea legítimo, el proceso de validación no llega a completarse con garantías. Y en seguridad, “no lo puedo comprobar” se traduce, en algunos entornos, como “no lo acepto”.

Aquí entra también un matiz que explica por qué en algunas experiencias “no pasó nada” y en otras fue un desastre: los navegadores grandes suelen aplicar mitigaciones para que OCSP no se convierta en un punto único de fallo. Algunos no hacen hard-fail salvo en situaciones concretas; otros usan técnicas propias de verificación. Pero fuera del navegador está el mundo de las aplicaciones: clientes HTTP, integraciones, bibliotecas TLS, agentes de monitorización, dispositivos, entornos corporativos endurecidos. Ahí las reglas cambian. Y basta con que un servicio crítico se apoye en un cliente estricto para que el incidente deje de ser anecdótico.

Hard-fail y soft-fail: dos maneras de entender la seguridad

El soft-fail es pragmático: si no puedo comprobar el estado OCSP porque el servidor está caído o la red no llega, sigo adelante, porque la alternativa es romper Internet. El hard-fail es riguroso: si no puedo comprobar, no conecto, porque la alternativa es aceptar un certificado potencialmente revocado. Ambos enfoques tienen lógica, y por eso coexisten. El problema aparece cuando una causa externa —un bloqueo— dispara el hard-fail en momentos y lugares donde no se esperaba. Entonces lo que se interpreta como “ataque” o “fraude” es, en realidad, una carretera cortada.

En este episodio, además, se sumó la capa emocional de la sorpresa: que el corte venga del contexto del fútbol. No porque el fútbol sea el villano —eso sería simplificar—, sino porque muestra cómo una medida diseñada para un fin concreto puede impactar en infraestructuras de uso general, sin relación directa con la señal que se intenta proteger. La idea de que un bloqueo antipiratería pueda afectar a verificaciones HTTPS suena absurda hasta que se observa cómo se comparten IPs y CDNs.

Y luego está el factor tiempo: según la conversación original, el problema se detecta en torno a media mañana y el hilo se publica al mediodía, con sensación de que el bloqueo aparece en ventanas concretas. Esa temporalidad cuadra con bloqueos “de evento”, pero también hace más difícil demostrar y reproducir el fallo cuando se intenta diagnosticar. Cuando el incidente desaparece al cabo de horas, el análisis queda incompleto, y lo que queda es un rastro de capturas, resoluciones y testimonios. Es justo el tipo de terreno donde los daños colaterales se repiten, porque no hay un aprendizaje institucional claro: el sistema vuelve a operar igual la semana siguiente.

La parte delicada: seguridad, servicios “no críticos” y responsabilidades

La frase “menos mal que no es crítico” fue un dardo con veneno: lo que es crítico depende de dónde se mire. Un endpoint OCSP puede parecer secundario hasta que una administración no puede validar una conexión interna, hasta que una pasarela de pagos corta por seguridad, hasta que una VPN corporativa con políticas estrictas deja de autenticar, hasta que una herramienta de despliegue no puede acceder al panel de control. Y cuando un fallo es intermitente, el impacto real se mide en horas perdidas, sistemas degradados, decisiones improvisadas y confianza rota. No hace falta dramatizar para entenderlo: basta con imaginar un servicio que solo falla “cuando hay partido”. Es un tipo de fragilidad muy específico, y muy dañino.

De ahí que el comentario de “algún día esto se va a llevar alguna vida por delante” haya resonado aunque sea una hipótesis. No es una acusación verificable en sí misma, es un aviso sobre riesgo sistémico. En el mundo actual, hay servicios médicos, de emergencias, de teleasistencia y de infraestructura pública que dependen de conexiones cifradas y validaciones estrictas. Cuando el candado falla, no siempre se traduce en tragedia, claro; muchas veces se traduce en “no entra el sistema”, “se retrasa una actuación”, “se vuelve al papel”, “se improvisa”. Pero el riesgo existe. Y cuando existe, la discusión deja de ser “te molesta no ver un partido pirata” y pasa a ser “qué estamos rompiendo por el camino”.

El núcleo del debate es la proporcionalidad y la precisión técnica de las medidas. Si se apunta a un objetivo concreto —un servicio ilícito— pero se ejecuta con herramientas que afectan a infraestructura compartida, el daño colateral no es una excepción: es una consecuencia esperable. En un Internet donde Cloudflare y otros grandes intermediarios sirven como capa para miles de servicios, bloquear por IP exige una cirugía fina que rara vez existe a nivel operativo cuando lo que prima es la velocidad.

Y aquí aparece la zona gris de “quién es responsable de qué”. La entidad que impulsa el bloqueo, las operadoras que lo aplican, los intermediarios que comparten infraestructura, los servicios afectados que quedan atrapados sin haber hecho nada. En un incidente como este, nadie se siente “autor” del fallo, pero el fallo sucede. El resultado es un sistema sin ventanilla clara: el afectado no sabe a quién reclamar, y el que bloquea puede decir que su objetivo era otro. Mientras tanto, el candado parpadea.

El retrato completo del incidente y lo que deja en el aire

Lo ocurrido hoy, con el dominio globalsign.com en el foco, añade un matiz nuevo al debate de los bloqueos asociados al fútbol: no se trata solo de sitios inaccesibles, sino de tocar, aunque sea por accidente, un punto sensible de la infraestructura de confianza de Internet. Que el incidente se haya verbalizado a través de un hilo técnico concreto, con autor identificado y con referencias a IPs y a un CDN, le da una textura de “esto se ha visto, no es un rumor abstracto”. A la vez, deja abiertas preguntas incómodas: si hoy fue GlobalSign, ¿mañana qué otra pieza invisible puede quedar atrapada? ¿Un proveedor de autenticación, un servicio de actualizaciones, una plataforma de identidad, un sistema de validación de firmas?

Hay algo especialmente corrosivo en que un fallo de este tipo sea intermitente: enseña a desconfiar. Un administrador no puede dar garantías si no sabe cuándo su servicio va a fallar por causas ajenas. Un servicio público no puede permitirse que su acceso dependa del calendario de partidos. Una empresa no puede aceptar que sus herramientas de seguridad fallen “a ratos”. En tecnología, la disponibilidad no es un lujo; es una condición de funcionamiento. Y cuando la indisponibilidad llega por un corte externo, se vuelve casi imposible de gestionar desde dentro.

También deja un rastro técnico que, por sí mismo, es una llamada de atención: la revocación y su comprobación siguen siendo una parte frágil del sistema de certificados. Los navegadores la han tratado históricamente con guantes porque romper navegación masiva es impopular y peligroso. Pero el mundo de las aplicaciones y de los entornos endurecidos necesita certezas, no aproximaciones. En el momento en que un bloqueo convierte OCSP en inaccesible, se fuerza a elegir entre dos males: aceptar sin comprobar o cortar por seguridad. Y esa elección, cuando la impone un tercero, se convierte en un problema de política pública y de infraestructura, no solo de TI.

Cuando el bloqueo toca el candado

La lección de este episodio no es una moraleja grandilocuente; es una constatación concreta: la guerra antipiratería, cuando se ejecuta con bloqueos por IP en un Internet de CDNs y servicios compartidos, puede golpear donde no debe, y hoy el golpe ha rozado un elemento íntimo de HTTPS: la capacidad de verificar certificados ligados a GlobalSign a través de recursos asociados a globalsign.com. En el relato que se fue armando desde media mañana y que se publicó al mediodía por Claustronegro, la sospecha de infraestructura servida mediante Cloudflare encaja como pieza clave para explicar cómo un bloqueo pensado para otra cosa termina afectando a la verificación de seguridad.

Lo más relevante, al final, es que el incidente pone nombre a una fragilidad que ya existía: si se corta una autopista compartida, no se elige quién se queda sin pasar. Hoy fueron conexiones que dependen de comprobaciones de revocación, con síntomas de errores TLS y avisos de certificado que, en ciertos entornos, no se toleran. Mañana puede ser otra pieza silenciosa. Y cuando lo silencioso falla, lo visible —servicios, empresas, administraciones, infraestructura digital— se resiente de golpe, sin aviso previo, con la peor clase de ruido: el que parece aleatorio, pero no lo es.