La Autoridad de Certificación de Sectigo (Comodo) advirtió a los usuarios antes de la expiración del certificado raíz AddTrust , que se utilizó para la firma cruzada, para garantizar la compatibilidad con dispositivos heredados que no tienen un nuevo certificado raíz USERTrust en el almacenamiento.AddTrust expiró el 20 de mayo de 2020 a las 10:48:38 UTC. Desafortunadamente, surgieron problemas no solo en los navegadores obsoletos, sino también en los clientes que no son navegadores basados en OpenSSL 1.0.x, LibreSSL y GnuTLS . Por ejemplo, en los decodificadores Roku (consulte la respuesta en soporte técnico con fecha 30/05/2020), Heroku , en Fortinet, aplicaciones Chargify, en la plataforma .NET Core 2.0 bajo Linux y muchos otros.Se supuso que el problema afectaría solo a los sistemas heredados (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9, etc.), ya que los navegadores modernos pueden usar el segundo certificado raíz USERTRust, como se muestra en el diagrama.
Cadena de certificadosPero el 30 de mayo de 2020, de hecho, comenzaron los bloqueos en cientos de servicios web que usaban las bibliotecas gratuitas OpenSSL 1.0.xy GnuTLS. Se ha dejado de establecer una conexión segura con un error de obsolescencia del certificado.El ticket correspondiente en el rastreador de errores de OpenSSL (nombre de usuario y contraseña: invitado) se cerró el 25 de febrero de 2020 solo para la versión OpenSSL 1.1.0.Por qué ocurre un error
Cuando un cliente se conecta, el servidor TLS le envía su certificado. El cliente debe crear una cadena de certificados desde el certificado del servidor hasta el certificado raíz en el que el cliente confía. Para ayudar al cliente a construir esta cadena, el servidor envía uno o más certificados intermedios adicionales junto con los suyos.
Por ejemplo, un sitio web envía los siguientes dos certificados:1)
Asunto = * .habr.com
Editor = Validación de dominio Sectigo ECC Servidor seguro CA
Inicio de acción = sábado 30 de mayo de 2020 3:00:00
Fecha de caducidad = viernes 3 de diciembre de 2021 2:59:59
2)
Asunto = Validación de dominio Sectigo ECC Servidor seguro CA
Editor = USERTrust Autoridad de certificación ECC
Inicio de acción = viernes 2 de noviembre de 2018 3:00:00
Fin de la acción = miércoles 1 de enero de 2031 2:59:59
El primer certificado pertenece al servidor y es emitido por la autoridad de certificación Sectigo. El segundo es emitido por la autoridad de certificación USERTrust ECC y es el certificado raíz. Estos dos certificados forman una cadena completa a una raíz confiable.Sin embargo, la autoridad de certificación USERTrust es una raíz relativamente nueva. Fue creado en 2010, y todos los clientes tardaron muchos años en confiar en él. El año pasado, hubo informes de que los clientes individuales no confían en esta raíz. Por lo tanto, algunos servidores envían un certificado intermedio adicional de la Autoridad de Certificación USERTrust ECC emitido por AddTrust External CA Root al cliente. Este certificado se generó en 2000, y fue su certificado que expiró el 30 de mayo de 2020.Para los validadores de certificados competentes, incluidos los navegadores modernos, esto no causó problemas, ya que ellos mismos pueden construir una cadena de confianza antes de USERTrust, pero hubo un problema con los clientes que usan OpenSSL 1.0.xo GnuTLS. Incluso si estos clientes confían en la autoridad de certificación raíz de USERTrust y desean construir una cadena, siguen terminando con una cadena para agregar raíz externa de CA de AddTrust, lo que hace que la verificación del certificado falle.Sectigo ha proporcionado un certificado intermedio alternativo con firma cruzada AAA Certificate Services , que será válido hasta 2028.Comprobando sus servicios
Se recomienda a los operadores de aplicaciones de cliente y controlador de servidor que comprueben en su cadena de certificados si hay un certificado raíz de AddTrust desactualizado.Esencialmente, solo necesita eliminar AddTrust External CA Root de la cadena de confianza.Para los operadores de servidores hay un servicio ¿Cuál es mi certificado de cadena? , que realiza esta comprobación y ayuda a generar una nueva cadena de confianza con todos los certificados intermedios necesarios. No es necesario incluir un certificado raíz en esta cadena, ya que todos los clientes ya lo tienen en la tienda. Además, incluirlo en la cadena es simplemente ineficiente debido al aumento en el tamaño del protocolo de enlace SSL.Se recomienda a los operadores de aplicaciones del cliente que actualicen a la última biblioteca TLS. Si esto no es posible, debe eliminar el certificado AddTrust External CA Root de su almacenamiento. Si no está en el repositorio, se construye la cadena de confianza correcta para el nuevo certificado raíz USERTrust RSA Certification Authority, de modo que la verificación TLS pase correctamente.Para eliminar la raíz externa de CA AddTrust, debe hacer lo siguiente :- Editar
/etc/ca-certificates.confy comentarmozilla/AddTrust_External_Root.crt
- correr
update-ca-certificates
Para solucionar el problema, Fedora y RHEL sugieren agregar el certificado AddTrust a la lista negra: trust dump --filter "pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;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.Consulte también:
" El problema con los certificados Sectigo después del 30 de mayo de 2020 y el método de solución " en el blog corporativo de Habr
Soluciones PKI para su empresa. Contáctenos +7 (499) 678 2210, sales-ru@globalsign.com.