Retraso en registros de Certificate Transparency: lo que revelan 1.3M de certificados
Respuesta corta: Analizamos el historial público de Certificate Transparency (CT) de aproximadamente 700 dominios de alto tráfico y comparamos el inicio de validez declarado de cada certificado (NotBefore) con el momento en que realmente apareció en un registro de CT. Entre 1.29 millones de certificados registrados desde 2013 hasta mediados de 2026, el 19.6% tardó más de dos días completos en aparecer en CT, y el 15.0% tardó más de una semana. Luego dividimos los datos al 15 de junio de 2026, fecha en que el Root Program de Chrome comenzó a exigir que el certificado final emitido, y no solo el precertificado, incluyera un registro de log de CT válido. Tras esa fecha, la proporción que supera las 48 horas cae a 1.7% y la proporción que supera una semana cae a 0.8%, en la misma población y medida de la misma forma. La mediana de los certificados ya era rápida antes del mandato; lo que cambió fue la cola, aquellos certificados que solían permanecer sin registrar durante días, semanas o meses. Cada cifra proviene de una lectura pasiva de un registro público. No se contactó a ningún host ni se escaneó nada. A continuación detallamos cómo lo medimos, qué emisores redujeron la brecha más rápido y qué demuestra y qué no demuestra esto.
Dos cifras, un cambio de política
Certificate Transparency se diseñó para convertir la emisión de certificados en un registro público y de solo anexado: cada CA públicamente confiable registra los certificados que emite, de modo que cualquiera, el propietario de un dominio, un navegador o un investigador, pueda ver qué se emitió para un nombre determinado. El problema siempre radicó en la palabra "eventualmente". A las CA se les ha exigido registrar un precertificado e incorporar sus marcas de tiempo firmadas antes de emitir el certificado final desde 2018, y un Maximum Merge Delay estándar en la industria limita el tiempo que tiene un registro para incorporar un precertificado enviado, normalmente alrededor de 24 horas. Sin embargo, hasta este año, no existía un plazo equivalente para registrar el certificado final en sí. Un certificado podía estar firmado, fechado y en uso en producción mientras que su entrada en el registro se retrasaba días, semanas o, en al menos un caso reportado de forma independiente, meses.
Analice la mediana con atención: apenas varió, pasando de 1.0 hora antes del mandato a 0.975 horas después. No se trata de un error en los datos, es la distribución real. La mayoría de los certificados, de la mayoría de los emisores, ya se registraban en menos de una hora mucho antes de que existiera mandato alguno. Lo que el mandato redujo visiblemente fue la cola: la minoría de certificados que solían quedar durante días o semanas sin un registro público. El retraso medio muestra esa realidad con mayor crudeza, cayendo de unos 64 días antes del corte a 6.7 horas después, ya que la media se ve fuertemente afectada por los valores atípicos que la mediana oculta.
El mecanismo: un plazo para el precertificado y ninguno para el resto
El diseño original de Certificate Transparency registra un precertificado, un marcador de posición con extensión poison que permite a una CA recopilar Signed Certificate Timestamps antes de firmar el certificado real. Múltiples registros públicos de CT deben aceptar e incorporar ese precertificado dentro de un Maximum Merge Delay acotado, del orden de un día, y los navegadores han exigido su cumplimiento desde 2018. Esa parte del proceso siempre fue puntual, razón por la cual la industria podía afirmar que "CT es obligatorio" como una verdad general.
La brecha residía en la otra mitad: nada obligaba a la CA a enviar el certificado final emitido a un registro dentro de un plazo concreto. Una CA podía obtener sus SCT a partir del precertificado, incrustarlos, emitir el certificado y ponerlo en producción, todo de forma correcta, mientras la entrada en el registro de CT del certificado final permanecía en espera. Un caso documentado de forma independiente describe un certificado wildcard emitido por DigiCert para una plataforma importante que presentó una diferencia de aproximadamente tres meses entre su emisión declarada y su aparición en CT (no hemos verificado ese caso específico de forma independiente; considérelo una anécdota ilustrativa, no categórica). Nuestros propios datos muestran el mismo patrón a escala global: antes del mandato, una fracción considerable de certificados de varias CA importantes permanecía más de una semana sin registro público, que es exactamente la deficiencia que corrige la política de junio de 2026 de Chrome al exigir que el propio certificado final cuente con un registro válido.
Qué emisores cerraron la brecha y en qué medida
Aquí nombramos a las autoridades de certificación, no a los dominios cuyos certificados contabilizamos. La práctica de registro de una CA es información de interés público sobre dicha entidad, del mismo modo que un estudio anterior nuestro analizó qué CA autorizan los dominios para emitir en su nombre. Para cada emisor con una muestra representativa a ambos lados de la fecha límite, esta es la proporción de sus certificados registrados más de 48 horas después de NotBefore, antes y después del 15 de junio de 2026:
| Emisor | Antes (n) | Antes | Después (n) | Después |
|---|---|---|---|---|
| DigiCert Inc | 160,949 | 27.9% | 290 | 6.2% |
| Amazon | 95,508 | 20.0% | 863 | 2.9% |
| Google Trust Services | 66,473 | 10.3% | 2,249 | 3.1% |
| Sectigo Limited | 24,430 | 0.02% | 60 | 0.0% |
| Let’s Encrypt | 532,280 | 0.06% | 5,523 | 0.0% |
Destacan dos aspectos. Primero, Let’s Encrypt y Sectigo ya estaban cerca de cero antes del mandato, lo que coincide con que ambos gestionan canales de emisión automatizados a gran escala donde "emitir y registrar" es prácticamente un único paso atómico. Segundo, las CA con mayor margen de mejora (DigiCert, Amazon y Google Trust Services) mejoraron sustancialmente, reduciendo su porcentaje de registros tardíos entre cuatro y siete veces. No pudimos generar una comparación antes/después fiable para todos los emisores: GlobalSign, la marca heredada de COMODO y ZeroSSL contaban con muy pocos certificados posteriores al mandato en nuestra muestra (menos de unas cuantas decenas) o ninguno de los dominios monitorizados renovó con ellos desde el 15 de junio de 2026. Es una limitación de nuestra muestra de dominios, no una conclusión sobre dichos emisores.
Cómo lo medimos
Cualquier escéptico debería poder replicar esto desde cero, por lo que exponemos el método completo sin omitir nada.
- La población. Aproximadamente 700 dominios de la lista top 1,000 de Tranco, recopilados a lo largo de varios de nuestros estudios recientes de DNS pasivo. Para cada dominio consultamos su historial completo de Certificate Transparency en crt.sh, que devuelve cada certificado registrado para ese dominio y sus subdominios, desde 2013.
- La métrica. Para cada certificado registrado, comparamos su campo
not_before(el inicio de validez declarado del certificado) conentry_timestamp(cuándo crt.sh registró esa entrada). La diferencia es el retraso que reportamos. Descartamos duplicados mediante el ID interno de crt.sh y eliminamos un pequeño grupo de entradas con desfases inverosímiles (más de cinco años), que interpretamos como errores de reloj o de procesamiento y no como comportamientos reales de emisión. - La división. Clasificamos cada certificado según si su NotBefore era anterior o igual/posterior al 15 de junio de 2026, la fecha efectiva del requisito del Root Program de Chrome que exige que el certificado final emitido cuente con un registro válido en CT. Nuestros datos en caché cubren hasta el 24 de julio de 2026, por lo que el periodo posterior al mandato corresponde aproximadamente a las primeras seis semanas de la nueva norma, no a un año completo; considere las cifras posteriores al mandato como una lectura preliminar que esperamos consolidar, no como una tendencia definitiva.
- Lo que no hicimos. Nunca solicitamos un certificado, no nos conectamos a ningún servidor web ni escaneamos nada. Consultar un registro público de CT es una búsqueda pasiva, no un sondeo, el mismo criterio que rige cada auditoría que realizamos.
- Lo que conservamos. Conteos agregados, medianas y percentiles, por emisor y por periodo. Ningún nombre de dominio o subdominio se incluye en los resultados, y no recopilamos datos personales; los nombres de dominio y los metadatos públicos de certificados no constituyen datos personales.
Lo que esto no demuestra
Límites objetivos, porque una cifra sin su contexto es simple marketing.
- El periodo posterior al mandato es breve. Seis semanas de datos bastan para mostrar la tendencia del cambio, pero no para certificarlo como definitivo. Parte de la mejora podría reflejar un cumplimiento inicial riguroso que se relaje con el tiempo; planeamos verificarlo de nuevo.
- No todos los emisores tienen una muestra posterior fiable. Unas pocas CA grandes simplemente tenían muy pocos certificados posteriores al mandato en nuestra muestra de 700 dominios para generar un reporte fiable. Una muestra de dominios más amplia resolvería esto.
- NotBefore no es un indicador perfecto de cuándo se firmó realmente el certificado. Una CA puede fijar NotBefore ligeramente en el pasado para tolerar desviaciones de reloj. Esa práctica incrementaría levemente nuestra cifra de retraso incluso para una CA con registros inmediatos; no obstante, no justifica brechas de días o semanas.
- Esta es una medición de retrasos, no un hallazgo de emisiones indebidas. Un certificado registrado con retraso no es prueba de que se haya emitido incorrectamente, solo de que el registro público de auditoría no fue inmediato a su uso. El riesgo radica en la brecha de auditoría en sí: durante el tiempo que un certificado permanece sin registrar, nadie que monitorice CT para su propio dominio podrá detectarlo.
- La muestra se inclina hacia dominios de alto tráfico. El top 1,000 de Tranco se concentra en organizaciones con abundantes recursos y grandes CDN; el comportamiento de emisión en la cola de sitios más pequeños, que a menudo usan las mismas CA pero mediante otros sistemas de automatización, podría ser diferente.
Por qué es importante
El valor principal de Certificate Transparency para el propietario de un dominio radica en poder monitorizar los registros públicos para su propio nombre y detectar un certificado inesperado antes de que se use en su contra. Esto solo es útil si el registro se realiza de manera inmediata a la emisión. Un certificado que permanece sin registrar durante un mes es un certificado activo, validado por todos los navegadores e invisible para cualquiera que revise CT durante ese periodo. La brecha que cierra este mandato no es compleja; es la simple diferencia entre "cumplimos técnicamente con Certificate Transparency" y "es posible ver de inmediato lo que emitimos, en todo momento". Los datos indican que los emisores más rápidos del sector, entre ellos Let’s Encrypt y Sectigo, ya trataban esto como un proceso atómico mucho antes de que una política lo exigiera. El resto se está adaptando visiblemente ahora que el Root Program de Chrome lo convirtió en un requisito y no en una simple recomendación, el mismo patrón que observamos al analizar quién valida realmente los logs de CT en producción: las partes de este ecosistema que son obligatorias avanzan rápido, y las que solo son recomendadas se quedan atrás.
Retraso en registros de Certificate Transparency: respuestas rápidas
¿Qué es el retraso en registros de Certificate Transparency?
La diferencia de tiempo entre el inicio de validez declarado de un certificado TLS (NotBefore) y el momento en que realmente aparece en un registro público de CT. Un desfase corto implica que el registro público de auditoría avanza a la par de la emisión; un desfase largo implica la existencia de un certificado válido y funcional durante un tiempo sin constancia pública.
¿Exige Chrome que todos los certificados se registren en CT?
La política del Root Program de Chrome exige que el certificado final emitido, y no solo el precertificado, incluya un registro válido en logs de CT para certificados emitidos a partir del 15 de junio de 2026; Chrome no confía en los certificados emitidos tras esa fecha que carezcan de él. El registro de precertificados ya era obligatorio desde 2018.
¿Por qué un certificado podía ser válido antes de estar registrado?
CT exige registrar un precertificado e incluir sus marcas de tiempo firmadas antes de emitir el certificado final, y las normas de Maximum Merge Delay (alrededor de 24 horas) limitan cuánto tarda ese paso. Hasta la política de junio de 2026 de Chrome, no había un plazo equivalente para registrar el propio certificado final, por lo que podía estar firmado, fechado y en uso mientras su registro individual se retrasaba, en ocasiones por meses.
¿Cómo se midió esto?
De forma pasiva. Analizamos el historial público de CT, mediante crt.sh, de aproximadamente 700 dominios del top 1,000 de Tranco, comparando el NotBefore de cada certificado con la marca de tiempo de su entrada en el registro. No se contactó, resolvió ni escaneó ningún host. El resultado abarca 1.29 millones de entradas de registro entre 2013 y mediados de 2026, divididas a partir del mandato del 15 de junio de 2026.