Lagunas en la revocación de certificados de macOS en herramientas de línea de comandos

El 19 de octubre de 2026, Apple bloqueó automáticamente doce certificados comprometidos, seguido del bloqueo del decimotercero, el emSign ECC Root CA - G3, el 23 de octubre. Mientras que Safari y la mayoría de las aplicaciones nativas actualizaron sus configuraciones de confianza inmediatamente, las herramientas de línea de comandos que dependen de almacenes de certificados estáticos permanecieron vulnerables. Esta discrepancia creó una realidad dividida donde la misma máquina podía rechazar un certificado en un navegador mientras lo aceptaba en una sesión de terminal.

Qué ocurrió

El problema central radica en cómo diferentes componentes de software en macOS verifican los certificados digitales. Los marcos de seguridad de Apple, que impulsan Safari, Mail y muchas otras aplicaciones, utilizan un sistema dinámico que consulta la lista de bloqueo de Apple y realiza comprobaciones de revocación en línea. Sin embargo, ciertas herramientas incluidas con macOS y las Xcode Command Line Tools no usan este sistema dinámico. En su lugar, leen un archivo plano estático ubicado en /etc/ssl/cert.pem. A la semana en que Apple publicó su aviso, este archivo no se había actualizado para reflejar los nuevos bloqueos. Apple confirmó en el artículo de soporte 149555 que estas herramientas no consultan la lista de bloqueo ni verifican si un certificado ha sido revocado.

Esta fragmentación llevó a informes contradictorios por parte de operadores y desarrolladores. Algunos señalaron que sus comandos integrados curl y git continuaban conectándose a servidores que usaban los certificados bloqueados, mientras que otros afirmaban que estas herramientas respetaban los ajustes de confianza del sistema. La confusión probablemente surge de diferencias en las versiones de macOS, el uso de herramientas instaladas vía Homebrew frente a binarios del sistema, o malentendidos sobre qué almacén de certificados referencia un binario específico. Por ejemplo, Homebrew mantiene su propio paquete de certificados en /opt/homebrew/opt/ca-certificates, que se actualiza independientemente de las actualizaciones del SO de Apple. De manera similar, entornos de ejecución como Python a menudo incluyen sus propias autoridades de certificación mediante paquetes como certifi, creando otra superficie de confianza aislada.

Detalles clave

• Apple bloqueó doce certificados el 19 de octubre de 2026 y el emSign ECC Root CA - G3 el 23 de octubre de 2026.
• Las herramientas que leen /etc/ssl/cert.pem no consultan la lista de bloqueo de Apple ni realizan comprobaciones de revocación.
• La remediación manual implica eliminar certificados raíz del archivo plano, pero las actualizaciones de software de macOS pueden sobrescribir este archivo.
• Existen al menos cuatro verificadores distintos en un solo Mac: marcos de Apple, LibreSSL del sistema, paquetes de Homebrew y paquetes de entornos de ejecución.
• Apple recomienda a los administradores volver a verificar el archivo de certificados después de cada actualización del SO, ya que los parches pueden revertir los cambios manuales.
• Los informes contradictorios sobre el comportamiento de curl sugieren variaciones en las fuentes de las herramientas o en las versiones de macOS entre los usuarios.

Antecedentes

La revocación de certificados no es una propiedad inherente del certificado en sí, sino una decisión tomada por el verificador que lo comprueba. Cuando una autoridad de certificación compromete claves o emite certificados incorrectamente, los revoca. Sin embargo, para que un cliente respete esta revocación, debe consultar una lista actualizada de certificados revocados o comprobarlo en línea en tiempo real. En el ecosistema de macOS, este proceso está fragmentado. El sistema de llaveros de Apple está diseñado para ser actual y automático, pero las herramientas heredadas y los gestores de paquetes de terceros a menudo dependen de instantáneas estáticas de raíces confiables. Estas instantáneas se vuelven obsoletas hasta que se actualizan explícitamente, creando ventanas de vulnerabilidad donde los certificados revocados aún son aceptados como válidos.

Por qué importa

Para equipos que gestionan infraestructura autoalojada o desarrollan software en macOS, esta fragmentación plantea un riesgo de seguridad significativo. Si sus scripts de despliegue, pipelines de CI/CD o herramientas de monitoreo dependen de utilidades de línea de comandos como curl o git, pueden seguir confiando en certificados comprometidos incluso después de que Apple los haya bloqueado. Esto significa que sus sistemas automatizados podrían estar comunicándose con actores maliciosos o endpoints inseguros sin generar ninguna alarma. El silencio de estas herramientas es peligroso porque reportan conexiones exitosas, ocultando el fallo subyacente de confianza.

Además, la solución recomendada —editar manualmente el archivo de certificados— es frágil. Dado que las actualizaciones de macOS pueden restaurar la versión original sin parchear de /etc/ssl/cert.pem, una máquina que estaba asegurada ayer podría volver a ser vulnerable hoy tras una actualización rutinaria del sistema. Sin verificación continua, los administradores no pueden estar seguros de en qué estado de confianza se encuentran sus máquinas. Esta incertidumbre complica la respuesta a incidentes y la auditoría de cumplimiento, ya que dos máquinas aparentemente idénticas pueden tener posturas de seguridad completamente diferentes respecto a la validación de certificados.

Qué puede hacer

• Identifique qué almacén de certificados están usando sus herramientas críticas ejecutando pruebas de conexión detalladas y buscando salidas de CAfile o CApath.
• Compare los resultados de security verify-cert con sus herramientas de línea de comandos para detectar discrepancias en las decisiones de confianza.
• Si parchea manualmente /etc/ssl/cert.pem, registre el hash del archivo y la fecha, y vuelva a verificarlo después de cada actualización de software de macOS.
• Considere dirigir las herramientas a un único paquete de certificados controlado utilizando variables de entorno como CURL_CA_BUNDLE o SSL_CERT_FILE.
• Monitoree sus servicios expuestos externamente para validar la vigencia y caducidad de los certificados, asegurando que su propia infraestructura permanezca segura.
• Audite los paquetes de certificados específicos de lenguajes, como certifi de Python, y actualícelos independientemente del sistema operativo.