Resumen

  • Renovar o rotar un certificado cambia la clave que firmará las versiones futuras, pero no invalida por sí solo los binarios firmados y sellados correctamente antes de la caducidad.
  • La transición debe seguirse por artefacto: hash, certificado, token RFC 3161, hora efectiva de revocación, ubicación de distribución y decisión observada del verificador.

Al mediodía, un editor traslada su canal de publicación a un certificado nuevo. La primera compilación se firma bien y el panel aparece en verde. Sin embargo, un ejecutable de la noche anterior sigue en un espejo regional, conserva una marca de tiempo válida y continúa verificándose en los equipos de los clientes.

La secuencia no implica necesariamente un fallo. El fallo de control sería declarar terminada la transición de confianza porque la rotación técnica concluyó.

La firma vincula unos bytes con una identidad. El sellado de tiempo añade una afirmación distinta: una autoridad acredita que una huella existía en un momento concreto. Esa combinación puede mantener una firma aceptable tras la caducidad normal del certificado. También puede separar el software firmado antes y después de la fecha efectiva de revocación de una clave comprometida.

Por eso el certificado tiene dos finales operativos. El primero es su caducidad, después de la cual no debería producir firmas nuevas válidas. El segundo es el instante a partir del cual el verificador deja de reconocer su autoridad. Pueden coincidir, pero el sistema no garantiza que lo hagan.

Qué demuestra realmente la marca de tiempo

RFC 3161 define un MessageImprint: el identificador del algoritmo de hash y la huella de los datos. La autoridad comprueba el algoritmo y la longitud, pero no examina el programa. El token incluye una política, un número de serie único y genTime, y se firma con una clave dedicada al sellado temporal.

El token no dice que el programa sea seguro. Acredita que una huella concreta fue presentada bajo una política. No prueba que el editor controlara todos los caminos de firma ni que los espejos hayan retirado la versión anterior.

La verificación sigue siendo trabajo activo. RFC 3161 exige comprobar la respuesta, el certificado de la autoridad, la huella, el algoritmo, la firma y la oportunidad temporal. Microsoft refleja esta separación en SignTool: sign, timestamp y verify son operaciones distintas. La ruta RFC 3161 usa /tr para el servidor y /td para el algoritmo de resumen del sello.

La documentación de ClickOnce muestra el efecto práctico. Con una marca válida, una aplicación puede seguir aceptándose después de que expire su certificado. Es una propiedad útil: el editor no debería volver a firmar cada paquete histórico sano. Pero esa durabilidad impide medir la transición solo por la siguiente compilación.

La revocación crea una frontera temporal

Los requisitos de firma de código del CA/Browser Forum cubren certificados públicos y autoridades de sellado asociadas. Exigen a las autoridades que emiten esos certificados operar un servicio conforme con RFC 3161, recomendar su uso y rechazar MessageImprint con SHA-1.

También explican por qué revocar no equivale a borrar. Un certificado puede haber firmado un objeto o miles; su revocación puede invalidar código sano además de código sospechoso. La autoridad debe empezar a investigar un informe plausible en veinticuatro horas. Si existe compromiso de clave, la fecha efectiva debería ser el primer momento sospechoso respaldado por evidencia.

Esa fecha delimita la población afectada. Los requisitos indican que los objetos con marca anterior a la fecha de revocación deberían seguir tratándose como válidos. Es una regla del programa, no una prueba de que todas las plataformas produzcan el mismo resultado.

La autoridad de tiempo tiene otra frontera. RFC 3161 distingue el retiro ordinario de la pérdida de la clave. Si la autoridad cesa sin compromiso y la razón se expresa correctamente, los tokens anteriores pueden conservar validez. Si la clave del sellado fue comprometida, esos tokens no merecen confianza automática; los registros de auditoría o un segundo sello independiente pueden ser necesarios.

El denominador correcto son todos los artefactos distribuidos

Un inventario de certificados no basta. El editor debe conocer qué artefacto fue firmado, qué token lleva, dónde sigue disponible y cómo lo trata cada verificador objetivo.

El perímetro incluye descargas, repositorios, cachés, tiendas empresariales, canales de actualización, instaladores sin conexión y medios de recuperación. Retirar un binario de la portada no lo elimina de esas superficies. Revocar sin localizar los paquetes históricos sanos puede convertir una respuesta de seguridad en una interrupción evitable.

El control mínimo es un registro de transición de autoridad. Para cada hash, asocia compilación y versión, huella y serie del certificado, algoritmos, token y autoridad temporal, genTime, caducidad, estado y hora de revocación. Une esos datos con cada ubicación, su estado de retirada o sustitución, la política del verificador y el resultado observado.

Así, el cierre se puede refutar. La transición solo termina cuando la producción futura usa el firmante previsto, cada artefacto antiguo retenido tiene una decisión explícita, lo retirado ha desaparecido de las superficies controladas y los verificadores representativos entregan el resultado esperado.

Límite de la evidencia

RFC 3161 especifica el token, no certifica a una autoridad concreta. Los requisitos del CA/Browser Forum no uniforman todos los sistemas operativos. La documentación de Microsoft establece el comportamiento documentado de SignTool, Authenticode y ClickOnce, no el de cada ecosistema.

Aquí no se acusa a nadie de compromiso. Caducidad, rotación, revocación y fallo de la autoridad temporal son eventos diferentes. Una transición defendible mantiene esa diferencia en la evidencia y en la decisión.

Fuentes