¿Ha entrado ya en vigor la regla de certificados de 200 días?
Respuesta corta: sí, pero solo exactamente lo requerido. El límite del CA/Browser Forum para la validez de los certificados TLS públicos se redujo de 398 días a 200 días el 15 de marzo de 2026, hace siete meses. Analizamos el historial público de Certificate Transparency de 702 dominios principales, 1,359,618 certificados registrados deduplicados desde 2013 hasta hoy, y comparamos el periodo de validez de cada certificado antes y después de esa fecha. En los dos años previos a la transición, 75.3% de los certificados ya tenían 200 días o menos. En los siete meses transcurridos desde entonces, esa cifra es del 99.91%, lo que representa un cumplimiento prácticamente total. Pero la verdadera historia radica en dónde se sitúa cada autoridad de certificación bajo ese nuevo techo. Los emisores gratuitos y automatizados, entre ellos Let’s Encrypt y Google Trust Services, se sitúan en una mediana de 90 días, completamente inalterada por la regla, porque ya estaban años por delante de ella. Las grandes CA comerciales, como DigiCert, Amazon, Microsoft y GlobalSign, cayeron de una mediana de 324 a 397 días directamente a 198 o 199 días: el límite de lo que la regla permite ahora, ni un solo día menos. Una de ellas, Sectigo, rompió ese patrón. Aquí están los datos completos, cómo los medimos y qué cambiará nuevamente en marzo de 2027.
El cronograma y en qué punto nos encontramos
La votación SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods,” fue aprobada por el CA/Browser Forum el 11 de abril de 2025: los emisores de certificados votaron 25-0-5 (cinco abstenciones) y el grupo de navegadores (Apple, Google, Microsoft y Mozilla) votó 4-0-0 a favor. Apple la propuso. Establece una reducción escalonada en el periodo máximo de validez para certificados TLS públicos, y una reducción paralela, más pronunciada, en el tiempo durante el cual una CA puede reutilizar una validación previa del control del dominio:
- Hasta el 14 de marzo de 2026: validez máxima de 398 días, reutilización de validación de 398 días.
- 15 de marzo de 2026: validez máxima de 200 días, reutilización de validación de 200 días. Esta etapa ya se ha cumplido.
- 15 de marzo de 2027: validez máxima de 100 días, reutilización de validación de 100 días.
- 15 de marzo de 2029: validez máxima de 47 días, reutilización de validación de 10 días.
A día de hoy, han pasado siete meses del hito de los 200 días, faltan unos cinco meses para el de los 100 días y aproximadamente dos años y medio para el de los 47 días. Este artículo trata sobre lo que realmente cambió con el primer paso, no sobre el cronograma en sí: la base de conocimiento de cada registrador y CA ya explica las fechas. Queríamos saber si la emisión en el mundo real cambió cuando la regla lo exigió, y teníamos a mano trece años de nuestros propios datos pasivos de CT para comprobarlo.
Dos niveles, una fecha límite
Veamos primero la imagen general. Tomando todos los emisores en conjunto, la proporción de certificados recién emitidos de 200 días o menos pasó del 75.3% en los dos años previos al límite al 99.91% en los siete meses posteriores. Se trata de una transición casi unánime hacia el cumplimiento, que es exactamente lo que debe generar una fecha límite estricta de los Baseline Requirements: si no se cumple, los navegadores dejan de confiar en el certificado. Esa parte funcionó según lo previsto.
Al mirar en detalle, el ecosistema se divide en dos grupos que no se movieron de la misma forma, o que ni siquiera se movieron:
- Ya estaban allí. Let’s Encrypt y Google Trust Services, los dos emisores de mayor volumen en nuestra muestra por un amplio margen, han operado con un valor predeterminado de 90 días desde mucho antes de que existiera esta regla, ya que su emisión es gratuita, automatizada y pensada para renovaciones frecuentes desde el primer día. Su mediana posterior al mandato es de 90 días. Su mediana previa al mandato era de 90 días. Los certificados emitidos mediante ACME por la propia Apple y por la CA orientada a la automatización Certainly muestran el mismo patrón, con 86 y 30 días respectivamente, manteniéndose sin variaciones tras la transición. Para este grupo, el 15 de marzo de 2026 no cambió nada, porque la norma finalmente alcanzó la posición en la que ellos ya estaban.
- Aterrizaron exactamente en el límite. DigiCert, Amazon, Microsoft y GlobalSign cayeron de forma pronunciada, pero todas ellas se situaron en 198 o 199 días, un día por debajo del nuevo techo de 200 días, no significativamente por debajo. Antes del límite, sus certificados habituales duraban entre 180 y 397 días. Después, las cuatro convergen a tan solo un día del máximo legal. Eso es cumplir con la letra de una norma diseñada explícitamente para empujar a la industria hacia certificados de menor duración, sin adoptar su espíritu.
Sectigo es el único emisor en nuestra muestra que no encaja claramente en ninguno de los dos patrones. Su mediana previa al mandato era de 366 días, claramente en el bando tradicional, pero su mediana posterior al mandato cayó a 90.4 días, con el 55.6% de sus certificados posteriores al mandato ya en 90 días o menos. Ese es un cambio real hacia el comportamiento del grupo automatizado, no un simple deslizamiento hasta el nuevo techo. No sabemos la causa solo con los metadatos de CT; es coherente con un cambio en el pipeline de emisión o la integración de ACME que los clientes de Sectigo en nuestra muestra están utilizando ahora, pero no podemos confirmar el mecanismo.
Microsoft merece una mención aparte porque su cifra se movió en la dirección contraria sobre el papel: una mediana previa al mandato de 180 días subió a 198 días tras el mandato. Interpretamos esto como que Microsoft ya operaba con periodos algo más cortos de lo que permitía el antiguo techo de 398 días, y luego se reubicó justo por debajo del nuevo límite de 200 días, el mismo comportamiento de ajustarse al límite que las demás CA corporativas, solo que partiendo de una base ligeramente más corta. Esto no es evidencia de que los certificados de Microsoft se hayan vuelto menos seguros; el periodo de validez y la postura de seguridad no están en el mismo eje, lo cual es también el tema de nuestra siguiente sección.
Quién es quién, en números
| Emisor | Antes (n) | Mediana antes | Después (n) | Mediana después |
|---|---|---|---|---|
| Let’s Encrypt | 98,928 | 90d | 16,676 | 90d |
| Google Trust Services | 39,845 | 90d | 7,927 | 90d |
| Apple Inc. | 1,915 | 86.8d | 357 | 85.9d |
| Sectigo Limited | 7,378 | 366d | 478 | 90.4d |
| Microsoft Corporation | 13,208 | 180d | 2,715 | 198d |
| DigiCert Inc | 11,916 | 324d | 1,438 | 198d |
| Amazon | 15,637 | 395d | 2,957 | 198d |
| GlobalSign nv-sa | 2,687 | 397d | 243 | 199d |
| GoDaddy.com | 827 | 384d | 41 | 198d |
Cada uno de los emisores anteriores respetó el límite de 200 días en prácticamente el 100% de sus certificados posteriores al mandato en nuestra muestra; no encontramos violaciones a los Baseline Requirements, que es lo que esperaríamos de programas raíz que auditan esto activamente. El hallazgo no es la falta de cumplimiento. Es que el cumplimiento adopta dos formas distintas, y la brecha entre “automatizado, ya corto” y “corporativo, ahora en el límite” sigue siendo de aproximadamente el doble en días reales, de 90 a 198, dentro de una misma regla que ambos grupos satisfacen por igual.
Cómo medimos esto
Cualquier escéptico debería ser capaz de reproducir esto desde cero.
- La población. Los historiales de Certificate Transparency de aproximadamente los mismos 700 dominios principales de Tranco, leídos mediante crt.sh, que reutilizamos para nuestro censo de demoras de registro en CT y nuestro censo de filtraciones de hostnames internos. No realizamos ninguna solicitud de red nueva para este artículo; el conjunto de datos completo ya estaba en caché a partir de trabajos anteriores.
- La métrica. Para cada certificado registrado deduplicado, el periodo de validez es
not_aftermenosnot_before, redondeado al día entero más cercano antes de clasificarlo, ya que un certificado nominal de “90 días” suele tener 90 días más unas pocas horas de desfase temporal asociadas a la hora de emisión del día. - La división. Clasificamos los certificados según si
not_beforecaía antes o a partir del 15 de marzo de 2026. Para la comparación por emisor, utilizamos una ventana emparejada de dos años inmediatamente anterior a la transición (del 15 de marzo de 2024 al 14 de marzo de 2026) en lugar de todo el historial, para que los certificados antiguos de hace una década de una CA no reduzcan injustamente su cifra de “antes”. - Lo que no hicimos. Nunca solicitamos un certificado, no nos conectamos a ningún servidor web ni escaneamos nada. Leer un registro público de CT es una consulta, no un sondeo.
- Lo que conservamos. Conteos agregados, medianas y percentiles por emisor y por periodo. En los resultados no aparece ningún nombre de dominio o subdominio.
Lo que esto no demuestra
Límites sinceros, porque un número sin sus salvedades es solo marketing.
- Una menor validez del certificado no equivale a una vida útil más corta de la clave privada. Una CA o un suscriptor pueden renovar un certificado con el mismo par de claves cada 90 o 200 días de forma indefinida; los metadatos básicos de entrada de crt.sh no exponen la huella de la clave pública del sujeto, por lo que no podemos determinar a partir de estos datos si el material de clave realmente se está rotando junto con el certificado. El beneficio de seguridad de una validez más corta depende de que se realice esa rotación; no medimos eso aquí.
- Siete meses de datos posteriores al mandato constituyen una lectura preliminar. Es suficiente para mostrar la forma de la respuesta inicial de cumplimiento, pero no para certificarla como el equilibrio permanente de la industria bajo un límite de 200 días. Planeamos volver a verificar esto en la siguiente etapa, en marzo de 2027.
- No todos los emisores tienen una imagen fiable del antes y el después. Varias CA en nuestra caché, incluidas GoDaddy y varios emisores más pequeños o regionales, tuvieron una muestra posterior al mandato demasiado reducida en nuestro panel específico de 700 dominios como para informar con confianza; solo tabulamos emisores con una muestra real en ambos lados.
- La muestra se inclina hacia dominios de alto tráfico. El grupo superior de Tranco se compone de organizaciones con amplios recursos y grandes CDN. El comportamiento de emisión para la larga cola de sitios más pequeños, a menudo detrás de las mismas grandes CA mediante otras formas de automatización, puede diferir.
- Esto mide a las autoridades de certificación, no el riesgo del atacante de forma directa. Un límite más corto reduce la ventana máxima durante la cual un certificado permanece válido si algo sale mal con él, pero solo como un factor dentro de una cadena más amplia que incluye revocación, higiene de claves y monitorización.
Por qué importa esto
Todo el argumento a favor de reducir el ciclo de vida de los certificados es la ventana de exposición: un certificado filtrado o emitido erróneamente que habría sido válido durante 398 días bajo la regla anterior ahora es válido, como máximo, durante 200, y lo será como máximo durante 100, y luego 47, a medida que avance el cronograma. Ese argumento solo rinde frutos si el ecosistema realmente avanza hacia el extremo más corto, y no solo ubicándose justo bajo cualquier techo legal en ese momento. A siete meses de distancia, los datos muestran que ambas cosas son ciertas al mismo tiempo. La norma cumplió su función como límite estricto: el cumplimiento pasó de tres cuartas partes a prácticamente la totalidad, de la noche a la mañana según los estándares de la industria. Pero la mayor parte del volumen que se movió solo lo hizo hasta donde exigía el nuevo límite, quedando a un día de los 200 en lugar de acercarse a 90. Los emisores que ya operaban con periodos cortos, aquellos cuyo modelo de negocio depende de renovaciones automatizadas, económicas y frecuentes, no se vieron afectados, porque se prepararon para esto años antes de que una votación del Forum lo hiciera obligatorio. Es el mismo patrón que encontramos cuando analizamos la rapidez con la que los certificados se registran en CT: las partes de este ecosistema sujetas a un cumplimiento normativo real avanzan exactamente tan rápido como este lo exige, ni un poco más rápido.
¿Ha entrado en vigor la regla de certificados de 200 días? Respuestas rápidas
¿Cuándo comenzó la regla de certificados de 200 días?
El 15 de marzo de 2026, bajo la votación SC-081v3 del CA/Browser Forum, aprobada el 11 de abril de 2025. Redujo la validez máxima de los certificados TLS públicos de 398 a 200 días. La próxima reducción, a 100 días, entrará en vigor el 15 de marzo de 2027; una reducción final a 47 días entrará en vigor el 15 de marzo de 2029.
¿Es necesario reemitir los certificados existentes bajo el nuevo límite?
No. El límite se aplica únicamente a los certificados emitidos en la fecha de entrada en vigor o después. Un certificado emitido bajo la antigua regla de 398 días sigue funcionando según su cronograma original.
¿Se reducirá también el periodo de reutilización de la validación del dominio?
Sí, en el mismo cronograma: de 398 a 200 días junto con la etapa de marzo de 2026, luego a 100 días en marzo de 2027 y a 10 días para marzo de 2029, obligando a una reverificación más frecuente del control del dominio de forma independiente a la validez del certificado.
¿Cuándo entra en vigor la regla de certificados de 47 días?
El 15 de marzo de 2029, la etapa final del cronograma SC-081v3: 398 días hasta el 14 de marzo de 2026, 200 días a partir del 15 de marzo de 2026, 100 días a partir del 15 de marzo de 2027, 47 días a partir del 15 de marzo de 2029.
¿Cómo se midió esto?
De forma pasiva. Leímos el historial público de CT, mediante crt.sh, de aproximadamente 700 dominios del top-1,000 de Tranco, calculando el periodo de validez de cada certificado como NotAfter menos NotBefore. No se contactó, resolvió ni escaneó ningún host. El resultado son 1,359,618 entradas de registro deduplicadas desde 2013 hasta octubre de 2026.