Espero que alguien pueda ofrecer algún consejo; se lo agradecería mucho. Les explicaré la situación.
He configurado Discourse muchas veces en mi dominio, hostballs[.]com. Cada vez que se visita www[.]hostballs[.]com, se redirige correctamente a hostballs[.]com, ya que el certificado de Let’s Encrypt cubre ambas versiones, con y sin www. Esto es lo que he conocido como el comportamiento predeterminado y estándar de Discourse con su implementación de Let’s Encrypt.
Actualmente, mi nueva instalación de Discourse está configurando SSL solo para el sitio sin www (que es el configurado como URL), pero no cubre www. Esto significa que cualquier persona que visite www[.]hostballs[.]com no será redirigida, sino que verá un error de SSL. Dado que sé que el comportamiento predeterminado suele ser diferente y que la instalación de Discourse está demasiado controlada como para simplemente recurrir a certbot y hacerlo todo manualmente (¿no haría eso más divertido las actualizaciones periódicas?), no estoy seguro de cuál es el mejor camino a seguir.
Mientras intentaba resolver esto, comenté las plantillas de SSL y Let’s Encrypt, así como la dirección de correo electrónico de Let’s Encrypt, en app.yml. Luego eliminé los directorios letsencrypt y ssl de /shared/standalone. Reconstruí el sitio sin SSL, luego volví a habilitar esas opciones en app.yml y reconstruí nuevamente para generar nuevos certificados y configuraciones de SSL. Aunque esto tuvo éxito, aún no solucionó el problema de www.
¿Alguien más ha enfrentado una situación similar y encontró una solución?
Si el consejo anterior te resulta demasiado intimidante, también podrías configurar una redirección DNS sencilla. La mayoría de los registradores ofrecen este servicio.
Discourse no puede publicarse bajo múltiples URLs; el registro raíz (sin www) y el registro ‘A’ de www son direcciones distintas. Una vez que asignes un FQDN a tu sitio, cualquier dirección adicional deberá gestionarse mediante una redirección.
Si ninguna de las sugerencias proporcionadas te convence, puedes optar por usar www.example.com y utilizar http://forcewww.com/ para redirigir al sitio con www.
Gracias, amigos. Déjame repasar algunos detalles que podrían ayudar a alguien más en el futuro.
Esto comenzó porque un usuario me dijo que visitar www no funcionaba y mostraba un error de certificado. Cuando accedí directamente al enlace https que proporcionó en el hilo de reporte, obtuve el mismo error. En el pasado, al usar www, no había encontrado este problema; en su lugar, se redirigía sin problemas al dominio raíz. Esto me llevó a concluir que mi instalación, tras una migración reciente, estaba de alguna manera dañada y no se comportaba según las características predeterminadas de una nueva instalación de Discourse.
Así que instalé una copia fresca de Discourse en un nuevo dominio para demostrar que www funcionaba por defecto al usar el dominio raíz. Fui al dominio, luego edité la URL en mi barra de direcciones y agregué “www.” al principio. Se redirigió al dominio raíz sin problemas, como esperaba. Entonces, pensé en probar una cosa más. Escribí manualmente “https://” antes de la URL. En ese momento, falló con el mismo error de certificado.
Por lo tanto, lo que pudo haberme llevado a asumir que la configuración de www era el comportamiento predeterminado en la implementación de LE de Discourse, podría haber sido en realidad mi navegador usando por defecto el puerto 80, ocultando la parte http/https de la URL mientras reescribía la dirección en la barra de direcciones.
Esta es mi mejor evaluación de la situación, al menos.
Solución más sencilla para alguien que usa su dominio raíz y desea que www esté firmado por LE para una redirección https adecuada, sin complicarlo demasiado ni usar otro servidor web para gestionar la redirección:
Sí, no veo una manera de lograrlo que no tenga el potencial de romperse con las actualizaciones. Esto simplemente parece ser el problema de las personas que tienen dominios dedicados para comunidades y no les gustan los subdominios innecesarios.
A menos que, por supuesto, ejecutes otro servidor web en otro lugar.
Bien, ya estoy viendo un intento que luego fue detenido porque un archivo cambió, rompiendo la forma en que estaban configurando la modificación del archivo en app.yml:
Ya sea que estemos editando un archivo directamente o que app.yml lo edite después, una actualización tiene el potencial de cambiar ese archivo y romper la forma en que lo estás editando, sin importar qué.
Mi punto es que cualquier cambio en esa plantilla volverá a romperla. En los últimos años, solo un cambio ha roto el método PUPS/ganchos: la introducción del soporte para ECC.