No, no hay instalación adicional.
Además, el único bloque que necesité agregar es:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d mywebsite.org --keylength"
(el redireccionamiento de HTTP a HTTPS parece funcionar correctamente sin los otros dos bloques de replace, aquellos con nginx)
Así que finalmente he encontrado tiempo para trabajar en las guías “Configuración de Let’s Encrypt con múltiples dominios” y “Redirección de dominio(s) único(s) o múltiples a tu instancia de Discourse”.
He añadido mucho más a mi archivo containers/app.yml que lo que tú hiciste y casi todo funciona correctamente.
Mi Discourse está alojado en el subdominio www y mi objetivo era redirigir las solicitudes HTTP y HTTPS desde el dominio principal (apex) al subdominio www. Esto ahora funciona, pero si voy a https://mydomain.com, aunque se redirige, Chrome muestra la siguiente advertencia en la consola:
Redirección de navegación example.com -> www.example.com porque el servidor presentó un certificado válido para www.example.com pero no para example.com. Para desactivar este tipo de redirecciones, inicia Chrome con la siguiente bandera: --disable-features=SSLCommonNameMismatchHandling
Aquí están mis añadidos al archivo app.yml:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /return 301 https.+/
to: |
return 301 https://$host$request_uri;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /gzip on;[^\}]+\}/m
to: |
gzip on;
add_header Strict-Transport-Security 'max-age=31536000'; # recuerda el certificado durante un año y conecta automáticamente a HTTPS para este dominio
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
¿Esto parece correcto? Si es así, ¿hay alguna solución para el problema de discrepancia en el nombre del certificado?
EDITO: Tengo dos registros A, uno para el subdominio www y otro usando @ para capturar todas las solicitudes al dominio principal. Ambos apuntan a la IP de mi droplet de Digital Ocean. Supongo que esto también es correcto.
Gracias.
Es gratuito de implementar, incluso si Cloudflare no es tu registrador. Funciona con HTTPS, sin complejidad adicional en tu instalación de Discourse.
Gracias, actualmente no estoy usando Cloudflare, así que no había topado con eso antes. Tomé otro camino y seguí las guías de arriba, logrando resolver mi problema en gran medida. Publicaste justo cuando envié mi respuesta anterior.
Por favor, verifica este sitio web; ¿tiene todas las redirecciones que necesitas? Se ha realizado con un único bloque replace (ver arriba) y esta configuración de DNS (solo he censurado los registros TXT de correo electrónico):
No recibo ninguna advertencia en la consola.
Sí, solo prepárate para que se rompa cuando cambie la configuración de Let’s Encrypt.
Cuando Let’s Encrypt se actualizó para admitir curvas elípticas, el enfoque en el que te basas anteriormente dejó de funcionar durante un par de semanas.
La única diferencia es que no tengo el registro CAA en mi DNS. Lo agregaré con el mismo valor que has utilizado.
Asumo que el nombre de host de tu Discourse es www.example.com; ¿estás seguro de que no recibes una advertencia al acceder a https://example.com?
La advertencia es aún más grave en Chrome para Android, ya que bloquea el sitio por completo y no redirige.
Me has perdido ahora 
¿Qué debo tener en cuenta o estar preparado para solucionar?
Correcto.
Sí, estoy seguro, no hay advertencia en la consola.
Creo que he encontrado el problema. Tenía esto:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
Cuando debería haber tenido:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com --keylength"
Fíjate en la última línea; tenía example.com y www.example.com.
También cambié return 301 https://$host$request_uri; por return 301 $scheme://$host$request_uri;, hice una reconstrucción y parece que ya funciona.
Ahora solo me preocupa lo que mencionó @Stephen sobre que podría dejar de funcionar si cambia la configuración de Let’s Encrypt.
Un cambio el 9 de septiembre del año pasado rompió el enfoque que estás siguiendo y, dado que la implementación no formaba parte de la instalación estándar, no fue hasta el 31 de octubre que se publicó una solución. Si revisas el tema que seguiste y el historial de ediciones en la wiki, verás que está claramente documentado.
Dado que no estás haciendo algo que requiera meterse hasta los codos en configuraciones adicionales, te desaconsejo hacerlo. Por otro lado, cuando Let’s Encrypt sí cambie y te veas afectado, podemos referirte de nuevo a este tema.