El 30 de mayo de 2020 vivimos una situación rara en la infraestructura pública de clave del Internet: dos de los certificados principales caducaron, siendo cada uno firmado por una de las otras entidades de verificación SSL.
Teóricamente, esto no es algo inusual. Los certificados caducan constantemente (normalmente en un año o incluso en 90 días, si utiliza Let’s Encrypt), y los certificados de las entidades de certificación caducan después de algunos años. Pero el 30 de mayo, la entidad de certificación caducada abordó un problema fundamental que hizo que nuestra API no estuviera disponible para algunos de nuestros clientes.
El 30 de mayo, cuando expiraron los certificados de las autoridades de certificación, recibimos solicitudes de soporte informando que había un problema con el certificado de nuestro servicio. Esta fue una noticia inesperada, ya que cuidadosamente verificamos si nuestros certificados eran válidos y no se iban a caducar en un futuro previsible. Una rápida verificación en el navegador también confirmó que todo parecía estar bien y que la API estaba respondiendo correctamente.
Al analizar las estadísticas de nuestra infraestructura, observamos que el número de solicitudes API ha disminuido, pero lejos de ser nulo, como se habría esperado en caso de una interrupción completa del SSL. Cuando las cosas no funcionan completamente, a menudo es más fácil detectar lo que no funciona que en situaciones en las que algunas cosas funcionan y otras no.
Una exhaustiva investigación finalmente reveló que también había problemas en otros servicios en Internet. En poco tiempo encontramos pistas sobre la causa: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020
- El certificado de nuestra entidad de certificación intermedia Sectigo RSA Organization Validation Secure Server CA era válido.
- En el camino 1, el certificado de raíz USERTrust RSA Certification Authority era válido y toda la cadena era válida.
- En el camino 2, el certificado de nuestra autoridad de certificación principal, USERTrust RSA Certification Authority, se emitió el 30 de mayo a las 10:48 UTC.
- El certificado de la autoridad de certificación de raíces AddTrust External CA Root, que cruzó de forma simultánea la firma del certificado de USERTrust RSA, expiró el 30 de mayo a las 10:48 UTC.
Esta fue una situación interesante. Había un camino válido hacia la autoridad de certificación RSA de USERTrust, y también había un camino caducado. El navegador era capaz de encontrar la cadena válida, pero la herramienta no pudo encontrarla. El test realizado por Quality SSL Labs demostró que el sistema funcionaba y que la configuración de certificados funcionaba correctamente.
Nuestro equipo comenzó con la segunda modificación de nuestro certificado público y intentó restablecer el servicio para los clientes que quedaban, y poco después del despliegue les confirmó que podrían volver a acceder al servicio. El incidente había terminado finalmente, y el servicio fue restablecido para todos los clientes. Pero ¿por qué algunos de nuestros clientes perdieron el acceso en primer lugar, si incluso el escáner SSL indica que el certificado es válido?
El certificado era, de hecho, válido, y toda la cadena de certificados fue generada de manera bastante correcta por la entidad de certificación Comodo/Sectigo (el uso de un certificado durante el fin de semana no es una buena práctica). Lo que no estaba previsto era la forma en que las bibliotecas de clientes abordarán esta situación, principalmente OpenSSL, que es la que opera la gran mayoría de HTTPS en el mundo. Durante el análisis del incidente, nos topamos con un interesante error de OpenSSL de 2014 que dice lo siguiente:
No utilice certificados caducados si es posible.
Fuente: https://github.com/openssl/openssl/commit/0930251df814f3993bf2c598761e0c7c6d0d62a2
Al buscar el emisor de un certificado, si el candidato actual ha caducado, continúe buscando. Devuelva un certificado caducado solo si no se encuentran certificados válidos.
Esto significa que antes de implementar este cambio, OpenSSL siempre declara el certificado como inválido cada vez que detecta un certificado inválido en la cadena. Después de implementar este cambio, OpenSSL pasa por alto el certificado caducado y busca de manera correcta otros certificados adicionales que puedan demostrar que el certificado es válido. Este pequeño cambio se adapta a la forma de la cadena de certificados: una única entidad de certificación puede ser firmada por varias entidades de certificación, algunas de las cuales aún son válidas y otras ya no lo son. Todo esto parece genial, ¿por qué entonces las consecuencias?
Si seguimos explorando, esta modificación en OpenSSL solo es parte de OpenSSL 1.1.1 y no de OpenSSL 1.0.x. Esto significa, por ejemplo, que todas las versiones de Ubuntu 16.04 y anteriores, Debian 9 y anteriores, CentOS 7 y anteriores o RedHat 7 y anteriores están afectadas, pero todas ellas siguen siendo versiones generalmente soportadas, al menos desde el punto de vista de la seguridad.
Pero ¿por qué los navegadores verificaron correctamente los certificados? Los navegadores se proporcionan con sus propias bibliotecas SSL/TLS y sus propios métodos para verificar la PKI. Chrome se proporciona con BoringSSL y Firefox con NSS, independientemente de las bibliotecas SSL/TLS del sistema operativo subyacente; no tiene el mismo error y se actualiza mucho más a menudo.
Ahora finalmente tenemos una imagen completa de lo que sucedió y por qué solo algunas implementaciones de backend de algunos clientes fueron afectadas, además de por qué algunos sistemas tenían almacenes de certificados obsoletos que requerían un certificado raíz mucho más antiguo.
¿Qué sigue? Contactamos a los clientes afectados y les explicamos lo que ha sucedido. Mejoramos nuestra herramienta de verificación de certificados para verificar el proceso en toda la cadena, y no solo nuestro certificado.
FAQ
¿Fue la indisponibilidad del servicio causada por un problema en los servidores de LOX24?
No, el servicio siguió funcionando pero no estaba disponible para sistemas antiguos.
¿Qué debería hacer para evitar que en el futuro se produzca una situación similar con LOX24 o con otros servicios?
Actualice su OpenSSL a al menos la versión 1.1.1 y LibreSSL a al menos la versión 3.2.0. Actualice también sus almacenes de certificados, en Linux a menudo como un paquete llamado „ca-certificates“.
¿Ha caducado el certificado de LOX24?
No, el certificado de LOX24 no expiró y sigue siendo válido. Lo que expiró fue una de las 3 versiones de los certificados de CA de las entidades de certificación que firmaron nuestro certificado.
¿Se vio afectado algún otro proveedor o era el problema específico de LOX24?
Lamentablemente, también había otros proveedores afectados: Heroku, Stripe, kernel.org, Datadog, Gandi.net y muchos otros.