Resumen

  • Un SCT demuestra que un registro asumió una promesa de inclusión; no demuestra por sí solo que Chrome, Apple u otro cliente aceptarán la conexión.
  • La liberación debe depender de pruebas externas por población de clientes, guardando la política y la lista CT efectivas junto con el resultado.

Hay tres SCT dentro del certificado. El sistema de emisión valida sus firmas y el despliegue llega a todos los bordes previstos. Aun así, una parte de los navegadores corta el enlace TLS. Contar recibos no explica el fallo porque el navegador no decide únicamente por cantidad.

RFC 9162 define el SCT como una promesa firmada de que el registro incorporará la entrada aceptada a su árbol de Merkle dentro del Maximum Merge Delay. Después pueden auditarse la inclusión y la coherencia del árbol. La misma norma aclara que validar el SCT no sustituye la validación ordinaria del certificado servidor y su cadena.

Chrome calcula el cumplimiento CT con más dimensiones. Importa si los SCT están embebidos o se entregan por TLS, cuántos registros distintos participaron, cuántos operadores independientes representan y qué estado tenía cada registro cuando emitió el SCT y cuando el cliente hace la comprobación. Para SCT embebidos en certificados de hasta 180 días, la política actual exige al menos dos registros distintos y dos operadores distintos, además de un registro que siga en un estado admisible al comprobar.

Por eso «tres SCT correctos» es un dato, no un veredicto. Puede ocultar concentración en un operador, un registro que ya no contribuye o un modo de entrega que cae bajo otra regla.

La lista que ve el cliente forma parte de la evidencia

Chrome publica una lista nueva cada día. La lista identifica registros, operadores y estados del ciclo de vida. También existe un límite de frescura: si la lista más reciente almacenada por el cliente tiene 70 días o más, Chrome desactiva la aplicación de CT. Una prueba que pasa en un cliente abandonado no demuestra que el certificado cumpliría en uno actualizado; quizá ese cliente ya no está aplicando CT.

Google advierte además que su lista no debe convertirse en una política universal para otros agentes. Está destinada a la compatibilidad y auditoría del ecosistema Chrome. Apple publica sus propios requisitos: distingue registros aprobados actualmente de los aprobados en el pasado, fija combinaciones específicas de SCT y limita cuántos recibos de un mismo operador cuentan. Un mismo certificado puede encontrarse con decisiones diferentes sin que ninguna política sea una simple copia de la otra.

Los fragmentos temporales convierten la elegibilidad en estado

La política de registros de Chrome exige que los nuevos registros se dividan por intervalos temporales. Cada fragmento acepta certificados cuya fecha notAfter cae en su rango. Así, el registro adecuado depende también de la caducidad del certificado. Los operadores deben cubrir intervalos contiguos, pero el emisor sigue necesitando seleccionar el fragmento correcto y vigilar su estado.

La guía para operadores de sitios hace visible el riesgo: la información CT de un certificado existente puede perder validez antes de que caduque el propio certificado. La recuperación puede requerir SCT nuevos entregados por TLS o un certificado de reemplazo. Vigilar solo la fecha de expiración deja fuera ese reloj.

Los hechos verificables son las definiciones de RFC y las políticas publicadas por Chrome y Apple. La recomendación de conciliar el recibo con clientes reales es una inferencia operativa. Las fuentes no muestran la mezcla de navegadores, excepciones, terminaciones, contratos ni historial de incidentes de una organización concreta. Tampoco prueban un fallo actual de una autoridad, un registro o un proveedor. Esos elementos siguen siendo desconocidos hasta medirlos.

El registro de aceptación debe unir huella del certificado, SCT y vía de entrega, identificadores y horas de los registros, política y lista efectivas, cliente y versión probados, resultado externo, excepción, responsable y margen de sustitución. El éxito no es que el emisor entregue la prueba; es que los clientes previstos acepten el servicio por las razones esperadas.

Fuentes