Espera… creo que lo tengo… desactivé el proxy y reconstruí sin la plantilla de Cloudflare. Volví a activar el proxy después y puedo acceder a WordPress y al foro con SSL estricto.
Te limitarías la tasa de solicitudes muy fácilmente si eligieras no usar la plantilla de Cloudflare…
Discourse pensará que muchas personas se están registrando desde la misma IP (proxy de Cloudflare) y comenzará a limitarles la tasa de solicitudes.
Hmm… mejor lo hago de nuevo sin el correo de Let’s Encrypt pero con la plantilla de Cloudflare. ¿Sabes si debería dejar el proxy activado al reconstruir con la plantilla de Cloudflare?
Muchas gracias por toda la ayuda… soy más bien de lo creativo.
Es mi registrador, no solo DNS… y no puedo permitirme pagar la enorme cantidad que exigen para que use un DNS diferente. Así que, ups.
La configuración de Discourse ya no requiere un correo electrónico para inscribir certificados, y así ha sido desde hace un tiempo. A menos que modifiques el archivo YAML para deshabilitar SSL, siempre usará HTTPS por defecto.
Usar Cloudflare para DNS y activar la nube naranja son cosas totalmente diferentes. Usar Cloudflare en el contexto anterior se refiere a su proxy y optimizaciones, las cuales han causado problemas extraños en el pasado. Su DNS es bueno, incluso excelente.
Tu instalación de Discourse no necesita cambios; tienes HTTPS funcionando y todo está bien allí. Si SSL funciona y la plantilla de CloudFlare está habilitada, no la toques.
Parece que el problema ahora está en WordPress. ¿Cómo lo tienes instalado? ¿Es solo un VPS o estás en algún tipo de hosting de WordPress?
Esta es una configuración muy común; estoy bastante seguro de que es una solución sencilla.
Esta es una Muy Mala Idea. Una vez que Discourse haya inscrito el certificado de Let’s Encrypt, las renovaciones se realizarán con éxito, ya que ocurren mediante un mecanismo diferente. No hay necesidad de deshabilitar TLS entre el servidor y la CDN.
¿Por qué hacer esto a la luz de lo anterior? Además de crear carga adicional al procesar localmente las reglas de UFW para todo el tráfico, corres el riesgo de que tus reglas queden desactualizadas; es una forma rápida de obtener errores de red. Cloudflare pone en línea nuevos rangos de IP periódicamente; lo primero que sabrás será cuando tus usuarios no puedan acceder al sitio. Deja que se inscriba el certificado y, si deseas usar CloudFlare, simplemente ajusta una regla de página en consecuencia.
Uso Cloudflare en modo solo DNS, es muy sencillo. Solo haz clic y desactiva la “nube naranja” en tu panel de control de DNS, para que la nube quede gris. Eso es todo lo que necesitas hacer.
Eso ya no funciona como antes. Si no quieres usar Let’s Encrypt, debes configurarlo manualmente en lugar de usar discourse-setup.
Entonces, ¿qué certificado obtendría Discourse en ausencia de un correo de LE? ¿Uno auto-firmado o un certificado emitido con un correo arbitrario?
En cualquier caso, debería funcionar correctamente con SSL de Cloudflare, ya que permiten hosts con un certificado válido en su configuración de SSL completo y superior.
Tendrás que consultar el código fuente, ya que no lo recuerdo con exactitud. Creo que utiliza el correo del administrador. Si la verificación de que el servidor está disponible en el puerto 443 falla, se negará a instalarse.
Puede que esté totalmente equivocado, pero según esto
read_config "LETSENCRYPT_ACCOUNT_EMAIL"
local letsencrypt_account_email=$read_config_result
if [ -z $letsencrypt_account_email ]
then
letsencrypt_account_email="me@example.com"
fi
if [ "$letsencrypt_account_email" = "me@example.com" ]
then
local letsencrypt_status="ENTER para omitir"
else
local letsencrypt_status="Escriba 'OFF' para desactivarlo."
fi
parece que la comprobación de configuración predeterminada debería ofrecer la opción de escribir “off” para desactivar Let’s Encrypt. ¿Quizás estoy totalmente equivocado y estoy mirando en el lugar incorrecto?
Desactivar Let’s Encrypt no es la solución.
En una instalación estándar, no lo es. En una instalación avanzada (por ejemplo, alguien que utiliza un proxy inverso), es totalmente una respuesta.
¿Podrías explicar por qué?
Es sencillo hacer que el escenario de certificados funcione. Incluso si operas un segundo servidor web en el mismo equipo y haces el proxy localmente, es fácil configurar el certificado, así que, ¿por qué no hacerlo?
¿Por qué solicitaría múltiples certificados?
Si puedo solicitar un solo certificado (unificado) de Let’s Encrypt a través del proxy inverso (por ejemplo, nginx o Caddy), ¿por qué querría un segundo certificado dentro del contenedor de Discourse si nada lo utilizará?
Creo que la respuesta general es evitar por completo la complejidad del proxy, si puedes ![]()
Pero es inevitable una vez que comienzas a considerar un despliegue más allá de la configuración estándar de uno o dos contenedores.
Tu foro tiene que crecer bastante para necesitar algo como el proxy de Cloudflare. Es algo a considerar cuando tu foro empieza a verse desbordado. A menos que estés migrando un foro grande a Discourse, nadie que esté instalando Discourse debería estar pensando en ello.
Realmente no estoy de acuerdo; configurar HTTPS correctamente es sencillo. En este caso, el usuario tiene dos sitios en dos servidores diferentes bajo un único dominio.
No hay ninguna razón técnica por la que ambos sitios no puedan servir contenido a través de HTTPS, independientemente de si CloudFlare está activado o no. Es fácil de hacer una vez que se entiende el método de registro utilizado por Let’s Encrypt y cómo configurar CloudFlare para Discourse. CloudFlare tiene un modo HTTPS completo, diseñado precisamente para este escenario: TLS desde el servidor hasta su red, TLS desde su red hasta los clientes, y descifrado intermedio para que puedan almacenar en caché y «optimizar», aunque, como sabemos con Discourse, esa última parte no funciona muy bien.
Principalmente eso, aunque sin duda hay beneficios en tener una regla de página que almacene en caché /uploads/; esto ayudará a aliviar la carga durante un tiempo y permitirá que un VPS de gama baja funcione un poco más.