La primera vez que recibí un recordatorio de Redsift de que mis certificados iban a caducar en una semana. Normalmente, Discourse renueva los certificados con mucha antelación. Esta vez no fue así, antes de empezar a reconstruir (lo que se supone que soluciona el problema), @Falco, ¿hay algo que quieras que compruebe y publique aquí para ayudar a llegar a la raíz de por qué los certificados no se renovaron?
El certificado raíz es ISRGX1 y aquí tienes la información del certificado que caduca:
Nombre Común (CN)
E6
Organización (O)
Let’s Encrypt
Unidad Organizacional (OU)
Emitido el
Miércoles, 16 de julio de 2025 a las 7:36:45 PM
Caduca el
Martes, 14 de octubre de 2025 a las 7:36:44 PM
La compilación actual es 3.6.0.beta1-dev (7ee52c8f85)
Pero ha pasado más de un día desde que actualicé el software del foro y el certificado aún no parece haberse actualizado. Le quedan 5 días antes de que expire, por lo que realmente necesita renovarse pronto.
Estoy en la rama estable de Discourse si eso marca la diferencia. ¿Es posible que la corrección del punto final no se haya retroportado?
Hemos tenido la misma experiencia de que SSL no se renueva.
Sería genial si alguien pudiera verificar que web.ssl.template se comporta correctamente en discourse-docker, me pareció que el puerto 80 en realidad no estaba sirviendo ninguna URL de /.well-known/ utilizada por Let’s Encrypt, todas las URL se estaban redirigiendo a SSL, incluidos los archivos de prueba que coloqué manualmente en /var/www/discourse/public/.well-known/. Tuve que editar /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf directamente dentro del contenedor de la aplicación.
A mí también. No recibí ninguna advertencia sobre la caducidad del certificado. Entrar en el servidor y lanzar una reconstrucción /var/discourse % ./launcher rebuild solucionó el problema.
En mis pruebas en una instalación vanilla de nginx (1.18.0, pero creo que es lo mismo para 1.26.3), una línea de configuración de nginx return 301 https://thehostname$request_uri; fuera de una ubicación anula completamente cualquier bloque location anterior, en lugar de ser un “catch-all”. Creo que /.well-known/ simplemente no se sirve en el puerto 80 a menos que la redirección 301 sea específicamente para otra ubicación, como / al final del bloque server. ¿Podría ser el mismo problema que esta publicación de stackoverflow?
Me alegra que rebuild funcione, pero como el certificado ya se había renovado por mí, no pude confirmar si un rebuild permitiría a los servidores de validación de Let’s Encrypt llegar allí si un certificado hubiera expirado. Quizás un rebuild inicia la renovación del certificado antes de que esa línea de plantilla esté en su lugar o similar, en lugar de arreglar las plantillas, pero no puedo confirmar si esa es la razón por la que rebuild logra que la renovación funcione.