Cambiamos nuestra CA a Let's Encrypt (y posibles fallos)

Kevin van Zonneveld

Cofundador · Ámsterdam, Países Bajos · Mostrar bio

Escribimos para abordar un problema reciente que ha surgido a raíz de nuestro cambio de certificados SSL de GoDaddy a Let's Encrypt. Un número reducido de nuestros clientes ha informado de que encuentra un error CERT_HAS_EXPIRED al ejecutar Assemblies desde sistemas antiguos. Este mensaje de error indica que el sistema del cliente considera que el certificado SSL de nuestro servidor ha expirado, lo que impide la conexión.

A la luz de estos problemas, queremos ofrecer un breve post-mortem de lo que ocurrió, por qué sucedió y las medidas que estamos tomando para evitar este tipo de incidentes en el futuro.

1. Qué ocurrió

   El 3 de julio migramos de GoDaddy a Let's Encrypt para nuestros certificados SSL. El 4 de julio, dos clientes empezaron a reportar un error CERT_HAS_EXPIRED al crear Assemblies.

2. Causa raíz

   Tras investigar, nos dimos cuenta de que este problema está relacionado con una deprecación conocida de septiembre de 2021 por parte de Let's Encrypt (consulta el aviso de expiración de DST Root CA X3⁠ para obtener más información). En esencia, algunos sistemas no han actualizado su almacén de confianza (un conjunto almacenado de certificados de confianza) para incluir el nuevo certificado raíz de Let's Encrypt, y siguen dependiendo de un certificado raíz expirado. Esta situación puede darse sobre todo en sistemas de producción antiguos o que se actualizan con menos frecuencia. En los dos casos reportados, se trataba de contenedores Docker que llevaban tiempo sin actualizarse (por ejemplo: php:7.0-apache). Normalmente se trata de contenedores, porque si el sistema operativo anfitrión no se hubiera actualizado, habría tenido problemas para conectarse a cualquier servidor que use Let's Encrypt, así que los administradores probablemente ya se habrían dado cuenta antes. Ahora podrías tener problemas con contenedores Docker creados con un propósito específico, que solo se usan para conectarse a Transloadit y que llevan varios años sin actualizarse.

3. Por qué no lo detectamos

   Durante nuestro proceso de migración y de pruebas, no tuvimos en cuenta el posible impacto en los sistemas antiguos que todavía dependen del DST Root CA X3 deprecado. Lamentamos profundamente este descuido.

4. Próximos pasos

   • Comunicación: en el futuro, nos comprometemos a informar a los clientes con mucha antelación sobre cualquier cambio que pueda afectar a tu servicio, para darte la oportunidad de prepararte y hacer los ajustes necesarios.
   • Pruebas exhaustivas: ampliaremos nuestros procesos de pruebas para contemplar el abanico más amplio posible de situaciones de los usuarios, incluidos los sistemas desactualizados.
   • Soporte: seguiremos ofreciendo soporte y soluciones a quienes se vean afectados por este cambio, y te guiaremos en el proceso de actualizar tus almacenes de confianza si es necesario.

Recomendamos a quienes se vean afectados que actualicen el almacén de confianza de su sistema para incluir el nuevo certificado raíz de Let's Encrypt, algo que normalmente se consigue actualizando el sistema operativo (del contenedor) o los paquetes de software correspondientes. Entendemos que esta puede no ser una solución adecuada para todos los clientes, y estamos aquí para orientarte y ayudarte. Ponte en contacto con soporte si te ves afectado.

En Transloadit nos importa mucho no romper la compatibilidad con versiones anteriores y normalmente ofrecemos avisos y rutas de actualización sin sobresaltos en todos los ámbitos. En este caso, yo, como fundador, supervisé personalmente el control de calidad y el despliegue gradual, y consideré que el cambio era seguro. Me equivoqué, lo lamento, y también lamento las molestias causadas.

Seguiremos trabajando sin descanso para garantizar un servicio seguro y fiable para todos nuestros clientes.