Resumen

  • La compra de la actividad de certificación por DigiCert creó una ruta comercial y técnica de migración, pero Google, Mozilla y Apple mantuvieron la facultad de decidir qué cadenas aceptaban sus propios clientes, con calendarios y excepciones diferentes.
  • Una empresa que dependa de PKI pública debe gestionar la confianza como una relación revocable y ejecutada por terceros: ni la vigencia del certificado, ni la firma criptográfica, ni el contrato de compraventa garantizan que el siguiente cliente vaya a aceptar la cadena.

La compraventa no modificó el navegador

En 2017, Symantec podía vender su negocio de seguridad web y PKI a DigiCert. La transacción permitía mover personal, relaciones comerciales, capacidad operativa y obligaciones. También podía financiar la construcción de una infraestructura de emisión administrada de forma independiente. Sin embargo, una raíz pública solo conserva valor operativo mientras el software de la parte que confía la trate como ancla.

Mozilla convirtió esa diferencia en una regla explícita. Su programa de raíces sostuvo que la confianza no se transfiere automáticamente entre organizaciones. La adquisición no anulaba el plan para retirar las raíces de Symantec. De lo contrario, una autoridad sometida a medidas por parte del programa podría eludirlas mediante una venta o reorganización y continuar bajo otro nombre con una infraestructura sustancialmente igual.

Google documentó el problema que había erosionado la confianza. Una publicación pública de enero de 2017 llamó la atención sobre certificados de autenticación web cuestionables. La investigación posterior encontró que varias organizaciones habían recibido capacidad de emisión sin la supervisión necesaria y situó el episodio dentro de un patrón más amplio. El equipo de Chrome dejó de confiar en la infraestructura heredada.

Eso no equivalía a afirmar que todos sus certificados fueran fraudulentos. Era una conclusión sobre la capacidad de la jerarquía para sostener una presunción general. Por eso la respuesta no consistió en revocar una sola hoja, sino en separar la emisión nueva, fijar periodos de sustitución y alterar lo que sucesivas versiones de los clientes aceptarían.

Cuatro relojes para una misma cadena

El primer reloj era la fecha de emisión. El plan de Chrome utilizó el 1 de junio de 2016 para delimitar los certificados antiguos afectados por Chrome 66. El 1 de diciembre de 2017 señalaba la transición a la infraestructura administrada por DigiCert: la infraestructura antigua no podía seguir emitiendo certificados que Chrome aceptara. Chrome 70 retiraría de manera más amplia la confianza en aquella PKI heredada, salvo excepciones estrechas.

El segundo reloj era el ciclo de lanzamiento del cliente. Canary, Beta y Stable convertían la política en comportamiento de forma gradual. La nota de Google de marzo de 2018 publicó hitos separados para Chrome 66 y Chrome 70. Las empresas podían aplicar temporalmente una política que deshabilitaba la desconfianza, pero esa posibilidad terminaba el 1 de enero de 2019. La excepción compraba tiempo dentro de una organización; no restauraba el reconocimiento público.

Mozilla siguió su propio recorrido. Firefox 58 mostraba avisos en consola. Firefox 60 rechazaba los certificados afectados emitidos antes del 1 de junio de 2016. Una fase posterior retiraría las raíces antiguas con algunas excepciones para subordinadas concretas. Cuando numerosos sitios todavía no habían migrado, Mozilla retrasó esa última fase de Firefox 63 a Firefox 64. La decisión revelaba dos costes: mantener más tiempo una jerarquía considerada riesgosa o cortar el acceso a servicios que no habían sustituido sus cadenas.

El tercer reloj pertenecía a cada sitio. Un certificado podía conservar meses de validez formal y, aun así, dejar de funcionar antes. Mozilla estimó que aproximadamente el 1 % del millón de sitios más visitados seguía afectado a comienzos de marzo de 2018; justo antes de Firefox 60, la cifra había bajado por debajo del 0,15 %. Para la siguiente fase midió otro conjunto, todavía del 3,5 %. No son denominadores globales comparables, sino fotografías de telemetría, pero muestran cómo una decisión de confianza se transforma en miles de tareas de inventario, sustitución y prueba.

El cuarto reloj era el parque instalado. Apple empezó la desconfianza parcial el 1 de agosto de 2018. Mantuvo una ventana acotada para certificados publicados en un registro CT aceptado y fija el 25 de febrero de 2020 como fecha de desconfianza completa de las autoridades listadas. Chrome, Firefox y las plataformas de Apple no actuaron mediante un interruptor mundial sincronizado.

Así, dos usuarios podían recibir respuestas opuestas del mismo servidor. El certificado no había cambiado entre las dos conexiones. Había cambiado el conjunto local de reglas y actualizaciones del cliente.

Un registro demuestra existencia, no legitimidad

RFC 6962 diseñó Certificate Transparency como registros de crecimiento acumulativo con marcas de tiempo firmadas y pruebas de consistencia. El titular de un dominio puede detectar una emisión desconocida; un auditor puede probar que un registro presentó historias incompatibles; un investigador puede atribuir una aserción al emisor.

El propio RFC limita la interpretación: una marca de tiempo firmada no garantiza que el certificado no se haya emitido indebidamente. CT convierte una acción en observable y difícil de negar. No demuestra que el solicitante controlaba legítimamente el nombre, que la validación fue suficiente o que el navegador deba aceptar el emisor.

La regla provisional de Apple utilizó el registro como una condición de aceptación para una ventana concreta. No convirtió a CT en una amnistía permanente. Para un equipo de seguridad, una entrada inesperada debe abrir preguntas sobre solicitante, método de validación, despliegue y revocación; no cerrarlas.

La autoridad efectiva estaba distribuida

Las autoridades raíz parecían ocupar el centro, pero su poder dependía de software que otras organizaciones distribuían y ejecutaban. Google controlaba Chrome; Mozilla, Firefox; Apple, sus plataformas; una empresa podía mantener durante un tiempo una excepción local; el sitio podía desplegar una cadena distinta.

La lectura de Heng Lu sobre la primacía del código en ejecución sirve aquí como marco declarado, no como prueba del incidente. Una institución obtiene fuerza práctica cuando los participantes aplican sus reglas, y una dependencia técnica no debería transformarse sin límites en soberanía. La venta de Symantec no reescribió los almacenes de confianza. DigiCert y los sitios tuvieron que ofrecer cadenas que cada población de clientes decidiera aceptar.

La distribución no eliminó la concentración. Pocos proveedores de clientes podían imponer costes globales de migración. Esa facultad exige criterios publicados, evidencia, una transición proporcionada, excepciones temporales y explicaciones que permitan comparar casos. La eficacia técnica de una retirada no prueba por sí sola que el proceso fuera justo.

El inventario que sí sirve

Un inventario ordenado solo por vencimiento no detecta esta clase de interrupción. Debe registrar la cadena completa, las familias de raíces, los programas relevantes para cada población de usuarios, los canales de versiones, las fechas de emisión, las obligaciones CT, las excepciones y una prueba del reemplazo desde el cliente real.

También debe distinguir compromiso de clave, emisión indebida, fallo de auditoría, revocación de una hoja, desconfianza de una raíz y despliegue de software. Pueden formar una secuencia, pero cada uno tiene un dueño y un efecto distintos.

En una adquisición, la diligencia tiene que separar contratos, sistemas de emisión, raíces antiguas, raíces nuevas, subordinadas, auditorías, participación en CT y coste de reemplazar certificados ya desplegados. Los ingresos ligados a una cadena con fecha de retirada no valen lo mismo que los ingresos ya migrados a una infraestructura aceptada.

Límites de la evidencia

Los documentos oficiales prueban los calendarios y la posición de que la confianza no se cedía automáticamente. No prueban que cada certificado de Symantec estuviera mal emitido. Las cifras de Mozilla son mediciones parciales y temporales. Las fechas de Apple no deben atribuirse a Chrome o Firefox. Una decisión de un programa de raíces tiene autoridad efectiva sobre sus clientes, pero no constituye soberanía universal sobre la Web.

Fuentes