Certificados revocados: comprueba la corrección en cada cliente

La revocación marca un certificado como no válido. Para corregir el problema en los sistemas que dependen de él, hay que comprobar si los clientes que administras realmente lo rechazan. Tu navegador, las herramientas de línea de comandos y las tareas de compilación pueden usar distintos almacenes de confianza y mecanismos de revocación. Por eso, corregir el navegador no permite dar por terminadas todas las tareas.

El incidente de los certificados de eMudhra ilustra esa diferencia. Según las indicaciones de Apple, sus bibliotecas de red bloquean los certificados afectados, mientras que algunas herramientas de línea de comandos pueden seguir aceptándolos a través de un archivo de certificados independiente. La siguiente pregunta es cómo actuar: ¿qué vía sigue cada herramienta desplegada y qué pruebas aceptarás antes de cerrar su tarea de corrección? Indicaciones de Apple sobre el incidente.

¿Qué demuestra el incidente de eMudhra?

El incidente demuestra por qué hay que seguir una corrección hasta los programas que realmente la utilizan. El proveedor puede haber completado la respuesta para un cliente mientras otro sigue pendiente de una actualización distinta.

Según Apple, se vieron comprometidas las claves de ocho certificados intermedios: seis para TLS, que protege las conexiones de red, y dos para la firma de código. Cada emisor TLS tenía un certificado de eMudhra y otro con firma cruzada de Sectigo, lo que da un total de doce certificados TLS afectados. Doce certificados no equivalen a doce claves comprometidas de forma independiente. Indicaciones de Apple sobre el incidente.

Apple indica que el bloqueo comenzó el 19 de octubre de 2026. Safari, Mail y otras aplicaciones que usan sus bibliotecas de red reciben protección automáticamente. Sus indicaciones identifican por separado las herramientas que utilizan /etc/ssl/cert.pem, incluidas algunas configuraciones de Git y curl. Esas herramientas pueden seguir aceptando los certificados afectados. En la consulta del 29 de octubre, Apple anunciaba una futura actualización de software y cambios opcionales para administradores, con limitaciones importantes. Consulta el aviso vigente antes de actuar. Indicaciones de Apple sobre el incidente.

Esta distinción es más precisa que afirmar que todos los Mac o todas las aplicaciones de Apple son vulnerables. También resulta más útil: señala una cadena de dependencias que puedes investigar.

La actualización del investigador del 28 de octubre indica que macOS 27.2 restableció un archivo de certificados modificado manualmente. Las propias indicaciones de Apple confirman el riesgo general de que una actualización de software sustituya ese archivo. Atribuye la observación sobre esa versión al investigador y toma las instrucciones de Apple como fuente de las medidas que recomienda el fabricante.

Nada de esto demuestra que tu tráfico haya sido interceptado. El proyecto sobre el incidente señala que se desconoce si hubo explotación fuera de los clientes que exigen transparencia de certificados (Certificate Transparency). Que un cliente acepte certificados que debería rechazar exige una corrección; no justifica inventar un historial de intrusiones.

¿Por qué puede seguir siendo de confianza un certificado revocado?

Un cliente necesita tanto una política de confianza como un mecanismo que aplique la invalidación correspondiente. Dos aplicaciones de una misma máquina no tienen por qué obtener esas decisiones del mismo sitio.

Un certificado raíz es un anclaje de confianza. Un certificado intermedio conecta los certificados que se emiten bajo él con ese anclaje. Un almacén de confianza es el conjunto de certificados o decisiones de confianza que consulta un cliente al validar una conexión.

La lista de raíces no describe por sí sola todo el comportamiento del cliente. En el debate del programa de certificados raíz de Mozilla, Dennis Jackson indica que Firefox recibió un bloqueo mediante OneCRL el 17 de octubre a las 22:59 UTC. Posteriormente, Mozilla eliminó una raíz de NSS el 20 de octubre para proteger a los programas dependientes que no disponían de OneCRL. El programa de certificados raíz de Chrome describe un bloqueo independiente mediante CRLSet el 17 de octubre, basado en el hash de la clave pública, que cubría tanto los certificados TLS originales como los de firma cruzada. Declaraciones originales de los programas de certificados raíz.

Son mecanismos de protección distintos que llegan a programas distintos. Una herramienta que utiliza una lista de certificados derivada del ecosistema de un navegador no recibe necesariamente las actualizaciones de la lista de bloqueo de ese navegador.

Esta tabla ayuda a gestionar la respuesta, pero no sustituye las instrucciones del proveedor. Eliminar una raíz puede afectar a cadenas legítimas ajenas a los certificados intermedios comprometidos, una consecuencia de la que Apple advierte expresamente. Sigue el procedimiento documentado para el cliente del que te responsabilizas. Indicaciones de Apple sobre el incidente.

Nuestra guía de recuperación tras el secuestro de un dominio explica por qué restablecer el DNS y solicitar la revocación de certificados resuelven cuestiones distintas. Aquí, la tarea empieza por el cliente instalado: identifica qué ejecuta, en qué confía y cómo sabes que ha recibido la corrección.

¿Qué clientes dependientes necesitan verificación?

Inventaría los clientes que tu equipo administra realmente y agrúpalos por sus ejecutables y dependencias de confianza. Una lista de activos que solo diga «portátiles macOS» o «ejecutores de CI» es demasiado genérica para determinar qué corrección corresponde.

Empieza por un flujo de trabajo real. Por ejemplo, sigue la descarga de un repositorio desde el terminal de un desarrollador y desde la tarea que compila tu versión de publicación. Identifica el programa que ejecuta cada entorno y la configuración de sus dependencias relevantes. Añade otras clases de clientes solo cuando las encuentres en tus sistemas.

Separa el navegador, la CLI del sistema y las CLI instaladas

Registra primero el navegador o la aplicación y después examina por separado las herramientas de línea de comandos (CLI). En cada entrada de CLI, conserva la ruta del ejecutable, la versión, la biblioteca TLS o el componente de validación correspondiente, la configuración de confianza activa y el entorno de ejecución. Si no has determinado algún dato, escribe «desconocido» y asigna la investigación.

No des por hecho que el nombre de un paquete determina toda la cadena de dependencias. El cambio de Homebrew «git: do not depend on macOS’s system cURL» se incorporó el 28 de octubre. Es un ejemplo concreto de una corrección que afecta a la dependencia de cURL que utiliza Git, y no solo a la presencia de un paquete actualizado de certificados de autoridades de certificación (CA).

Que se haya incorporado un cambio al paquete no indica qué binario invoca el terminal de un desarrollador. En una misma máquina puede haber varias instalaciones. Registra el ejecutable real del flujo afectado y determina su configuración antes de usar la actualización del paquete como prueba para cerrar la tarea.

Sigue los entornos de ejecución y los almacenes integrados cuando existan

Si tu aplicación establece conexiones TLS salientes mediante el entorno de ejecución de un lenguaje, inclúyelo en la investigación. Si incorpora su propio almacén de certificados, registra la versión distribuida de la aplicación y el almacén que carga realmente. Son categorías que debes investigar, no afirmaciones de que este incidente afecte a todos los entornos de ejecución o aplicaciones con almacenes integrados.

El inventario debe responder a una pregunta práctica: ¿puede otro ingeniero identificar el mismo cliente a partir de tu registro? «Python actualizado» o «paquete de certificados corregido» dejan demasiadas cosas sin aclarar. La versión del entorno de ejecución, un identificador del entorno y una referencia a la configuración permiten a la siguiente persona repetir la inspección.

Deja visibles las configuraciones que sustituyen los valores predeterminados. Si el proceso tiene un ajuste explícito para el archivo de certificados, regístralo sin exponer secretos. La configuración predeterminada del sistema aporta pocas garantías si la aplicación utiliza otra.

Trata la CI como un entorno desplegado

En la infraestructura de compilación, identifica el ejecutor o la imagen que realizó la tarea correspondiente. Registra un identificador inmutable de la imagen, como su digest, cuando exista, junto con la versión del cliente y la configuración de confianza dentro de ese entorno. Probar tu portátil no equivale a probar la tarea que obtiene el código fuente o las dependencias antes de publicar una versión.

Averigua quién puede sustituir esa imagen o ejecutable y cómo llega la sustitución a las tareas activas. Reconstruir una imagen en un registro es solo un paso. El registro de verificación debe identificar la imagen o el ejecutable que utilizó realmente una tarea posterior.

Un inventario útil puede ser breve:

Utiliza las funciones que existan en tu equipo. Un fundador puede asumir varias filas; aun así, cada una necesita una decisión explícita y un resultado.

¿Qué pruebas permiten cerrar una tarea de corrección?

Cierra una tarea para un ámbito de clientes definido cuando puedas relacionar el aviso, el cambio desplegado y un resultado de verificación que demuestre lo que necesitas comprobar. Mantén visiblemente abierto todo lo que no hayas comprobado.

Este método operativo es una propuesta, no un requisito de Apple ni de Mozilla. Su objetivo es que la afirmación con la que cierras la tarea sea lo bastante precisa para que otra persona pueda revisarla.

1. Delimita el ámbito afectado. Indica qué flujo, máquinas o tareas de compilación cubre la tarea. Identifica las exclusiones y los clientes pendientes.
2. Enlaza el aviso aplicable. Registra por qué su mecanismo corresponde a este cliente. No sustituyas las instrucciones vigentes del proveedor por un comentario de un debate.
3. Identifica lo desplegado. Conserva la versión del ejecutable, la referencia a la configuración o el digest de la imagen que has inspeccionado.
4. Describe la corrección. Indica qué cambió, quién lo desplegó y si se trata de una medida provisional o de la solución duradera documentada.
5. Registra la verificación. Incluye el método, el entorno, la hora, el comportamiento esperado y el resultado observado.
6. Define cuándo volver a comprobarlo. Asigna el evento de mantenimiento o la nueva actualización del proveedor que debe dar lugar a otra inspección.

Distingue el rechazo del certificado de una petición fallida

Una conexión fallida no demuestra automáticamente que el cliente haya rechazado la cadena comprometida. Un fallo de DNS, un servidor no disponible o un proxy también pueden impedir que una petición se complete.

Utiliza un método de verificación aprobado y adecuado para el cliente y tu entorno. Conserva suficiente información de la salida para demostrar el resultado de la validación del certificado, en lugar de registrar solo «petición fallida». Excluye las cabeceras sensibles, los tokens y las direcciones internas de las pruebas que se compartan de forma amplia.

No debilites la validación de certificados para conseguir que una prueba se ejecute. Si el resultado es ambiguo, márcalo como no concluyente e investiga la causa. Un «todavía no verificado» claro resulta más útil que una tarea marcada en verde cuya prueba nunca llegó a comprobar la vía prevista.

Escribe un registro de cierre que otra persona pueda cuestionar

Considera este ejemplo hipotético, que no es una medición del incidente de eMudhra:

Ámbito: el paso de descarga del repositorio en un pipeline de publicación. Responsable: responsable de infraestructura de compilación. Aviso: las indicaciones del proveedor correspondiente. Instalación: el digest exacto de la imagen del ejecutor utilizado por la tarea de verificación. Cambio: dependencia del cliente actualizada y su configuración de confianza activa. Verificación: una prueba aprobada a través de ese cliente desplegado produjo el rechazo esperado en la validación del certificado; se adjuntan el método, la fecha y hora y la salida sin datos sensibles. Nueva comprobación: la siguiente reconstrucción de la imagen del ejecutor. Exclusión: los equipos de los desarrolladores siguen en una tarea independiente.

Este registro evita deliberadamente declarar que toda la empresa está protegida. Identifica un ámbito comprobado y deja otro pendiente. Si el equipo aún no puede identificar la imagen que se ejecutó, ese dato sigue como desconocido y la tarea permanece abierta.

Puede que tu proceso de divulgación coordinada ya haga seguimiento de varios proveedores. Aplica el mismo rigor dentro de tus sistemas: la respuesta de un proveedor y las pruebas de tu despliegue son registros separados, aunque pertenezcan al mismo incidente.

¿Cómo evitas que una medida provisional deje de funcionar?

Vincula las medidas temporales con los eventos de mantenimiento que puedan deshacerlas. Una comprobación satisfactoria hoy no demuestra el estado de un archivo tras una actualización del sistema operativo.

Apple advierte de que las actualizaciones de macOS pueden sustituir /etc/ssl/cert.pem. Por eso, «modificamos el archivo una vez» no basta como procedimiento de trabajo. Si utilizas los cambios opcionales documentados, registra quién se responsabiliza, el estado resultante esperado y el evento de actualización que exige una nueva comprobación. Da preferencia a la solución duradera del proveedor cuando esté disponible y sea aplicable a tu entorno. Indicaciones de Apple sobre el incidente.

Para cada medida provisional, responde a tres preguntas:

• ¿Qué acción habitual podría eliminar o eludir este cambio?
• ¿Quién comprueba el cliente afectado después de esa acción?
• ¿Qué resultado obligaría a reabrir la tarea de corrección?

Las mismas preguntas sirven para una aplicación reconstruida o una nueva imagen del ejecutor. Vuelve a inspeccionar el cliente real cuando la sustitución llegue al flujo de trabajo. Tener una configuración de imagen aprobada y una tarea que sigue ejecutando una imagen antigua son situaciones distintas.

Ajusta el esfuerzo de comprobación a lo que necesitas verificar. No necesitas un nuevo sistema de gestión de equipos para registrar el digest de una imagen, la configuración de un cliente y un resultado de verificación. Sí necesitas un responsable identificado para el siguiente evento, sobre todo cuando la solución actual es expresamente temporal.

Un parche sin un registro claro de divulgación puede dejar a los usuarios sin saber qué ha cambiado. Tu registro interno de cierre debe despejar la misma incertidumbre: qué se corrigió, dónde se desplegó, qué se verificó y qué queda por hacer.

Cómo distingue Kit entre la resolución y la verificación de la corrección

Un sistema de informes puede mantener claras las responsabilidades mientras tus herramientas operativas determinan el comportamiento del cliente. Deja explícitas esas funciones al registrar el resultado.

El flujo CSIRT de Kit asigna un responsable al informe y distingue resolved de fix_verified. El paso de verificación registra al usuario que ha iniciado sesión y un comentario opcional. Los cambios de estado conservan el usuario y el comentario, y un informe resuelto puede volver a in_progress cuando haga falta más trabajo.

Esos estados no realizan una prueba de certificados. Kit no elabora un inventario de tus almacenes de confianza, ni determina qué binarios ejecutan tus equipos, ni corrige los dispositivos, ni detecta automáticamente que una medida provisional se ha sobrescrito. Su etiqueta de verificación tampoco exige adjuntar pruebas. Tu equipo debe definir el ámbito y conservar las pruebas operativas que respaldan la decisión registrada.

Utiliza el informe para que esa decisión se entienda: identifica los clientes comprobados, remite al registro de verificación y nombra al responsable del trabajo pendiente. Evita que un ejecutor o entorno de ejecución sin comprobar desaparezca tras una etiqueta de «corregido» para todo el incidente.

En este tipo de incidente, cerrar una tarea exige poder relacionar la actuación del proveedor con un cliente desplegado y un resultado observado. Empieza por un flujo importante, registra sus dependencias y cierra solo lo que hayas verificado. Si necesitas un espacio compartido para gestionar los responsables de los informes y registrar ese seguimiento, prueba Kit.