El vencimiento del certificado raíz AddTrust causó fallos en sistemas con OpenSSL y GnuTLS

El 30 de mayo expiró el certificado raíz de 20 años. AddTrust, quien se utilizaba para crear una firma cruzada en los certificados de uno de los mayores centros de certificación, Sectigo (Comodo). La firma cruzada permitía garantizar la compatibilidad con dispositivos obsoletos que no habían incorporado el nuevo certificado raíz USERTrust en su almacén de certificados raíz.

El vencimiento del certificado raíz AddTrust causó fallos en sistemas con OpenSSL y GnuTLS

Teóricamente, la expiración del certificado raíz AddTrust solo debería haber llevado a problemas de compatibilidad con sistemas obsoletos (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), ya que el segundo certificado raíz utilizado en la firma cruzada sigue siendo vigente y los navegadores modernos lo consideran al verificar la cadena de confianza. En la práctica se encontraron problemas con la verificación de la firma cruzada en clientes TLS que no utilizan navegadores, incluidos aquellos basados en OpenSSL 1.0.x y GnuTLS. La conexión segura dejó de establecerse mostrando un error de caducidad del certificado, si en el servidor se utiliza un certificado Sectigo relacionado mediante la cadena de confianza con el certificado raíz AddTrust.

Si los usuarios de navegadores modernos no notaron la expiración del certificado raíz AddTrust al procesar los certificados firmados cruzadamente de Sectigo, surgieron problemas en diversas aplicaciones de terceros y manejadores de servidor, lo que condujo a violación interrupciones de muchas infraestructuras que utilizan canales de comunicación cifrados para interactuar entre componentes.

Por ejemplo, surgieron problemas accesos a ciertos repositorios de paquetes en Debian y Ubuntu (apt comenzó a mostrar un error de verificación del certificado), las llamadas desde scripts mediante las utilidades 'curl' y 'wget' comenzaron a fallar, se observaron errores al usar Git, se interrumpió la operación de la plataforma de transmisión Roku, dejaron de invocarse los manejadores Stripe y DataDog, comenzaron a ocurrir fallos en aplicaciones de Heroku, se dejaron de conectar clientes de OpenLDAP, se detectaron problemas con el envío de correos a servidores SMTPS y SMTP con STARTTLS. Además, se observan problemas en diversos scripts en Ruby, PHP y Python que utilizan módulos con clientes http. Desde los navegadores, el problema afecta Epiphany, en el que dejaron de cargarse las listas de bloqueo de anuncios.

Los programas en lenguaje Go no están afectados por el problema, ya que en Go se ofrece en C++); TLS.

Se suponía, que el problema afecta a versiones antiguas de distribuciones (incluyendo Debian 9, Ubuntu 16.04, RHEL 6/7) en las que se utilizan ramas problemáticas de OpenSSL, pero el problema también se presentó al trabajar con el gestor de paquetes APT en versiones actuales de Debian 10 y Ubuntu 18.04/20.04, ya que APT utiliza la biblioteca GnuTLS. La esencia del problema radica en que muchas bibliotecas TLS/SSL interpretan el certificado como una cadena lineal, mientras que de acuerdo con RFC 4158, un certificado puede representar un gráfico cíclico dirigido distribuido con múltiples puntos de anclaje de confianza que deben ser considerados. Esta deficiencia en OpenSSL y GnuTLS tenga se sabe ha existido durante muchos años. En OpenSSL, el problema fue corregido en la rama 1.1.1, mientras que en GnuTLS sigue siendo sin corregir.

Como solución alternativa para eliminar el fallo, se sugiere eliminar del almacén de certificados del sistema el certificado «AddTrust External CA Root» (por ejemplo, eliminarlo de /etc/ca-certificates.conf y /etc/ssl/certs, y luego ejecutar «update-ca-certificates -f -v»), después de lo cual OpenSSL comenzará a manejar correctamente los certificados firmados cruzados que involucren. Al utilizar el gestor de paquetes APT, bajo su propio riesgo, se puede desactivar la verificación de certificados para ciertas consultas (por ejemplo, «apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false»).

Para bloquear el problema en Fedora y RHEL se sugiere agregar el certificado AddTrust a la lista negra:

trust dump —filter «pkcs11:id=;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract

Pero este método no funciona para GnuTLS (por ejemplo, sigue arrojando un error de verificación de certificado al ejecutar la herramienta wget).

Del lado del servidor, se puede modificar el orden de los certificados en la cadena de confianza enviados por el servidor al cliente (si el certificado relacionado con «AddTrust External CA Root» se elimina de la lista, la verificación por parte del cliente se realizará con éxito). Para verificar y generar una nueva cadena de confianza se puede utilizar el servicio whatsmychaincert.com. La empresa Sectigo también ha proporcionado un certificado intermedio firmado cruzado alternativo «AAA Certificate Services«, que será válido hasta 2028 y permitirá mantener la compatibilidad con versiones antiguas del sistema operativo.

Adición: El problema también se manifiesta en LibreSSL.

Fuente: opennet.ru

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster