Não, nenhuma instalação adicional necessária.
Além disso, o único bloco que precisei adicionar foi:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d mywebsite.org --keylength"
(O redirecionamento de HTTP para HTTPS parece estar funcionando bem sem os outros dois blocos replace, aqueles com nginx)
Então, finalmente consegui tempo para trabalhar nos guias ‘Configurando o Let’s Encrypt com Múltiplos Domínios’ e ‘Redirecionar domínio único/múltiplo(s) para sua instância Discourse’.
Adicionei muito mais ao meu arquivo containers/app.yml do que você, e quase tudo funciona corretamente.
Meu Discourse está hospedado no subdomínio www, e meu objetivo era redirecionar as solicitações http e https do domínio principal (apex) para o subdomínio www. Isso agora funciona, mas quando acesso https://mydomain.com, ele redireciona, porém o Chrome exibe o seguinte aviso no console:
Redirecionando navegação example.com -> www.example.com porque o servidor apresentou um certificado válido para www.example.com, mas não para example.com. Para desativar esse tipo de redirecionamento, inicie o Chrome com a seguinte flag: --disable-features=SSLCommonNameMismatchHandling
Aqui estão minhas adições ao 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'; # lembre o certificado por um ano e conecte automaticamente via HTTPS para este domínio
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;
}
Isso parece correto? Se sim, existe uma solução para o problema de incompatibilidade do nome do certificado?
EDIT: Tenho dois registros A, um para o subdomínio www e outro usando @ para capturar todas as solicitações ao domínio principal. Ambos apontam para o IP do meu droplet da Digital Ocean. Suponho que isso também esteja correto?
Obrigado.
Grátis de implementar, mesmo que o Cloudflare não seja o seu registrador. Funciona com HTTPS, sem complexidade adicional na sua instalação do Discourse.
Obrigado, eu não estou usando o Cloudflare no momento, então não havia me deparado com isso antes. Optei por outro caminho e segui os guias acima, conseguindo resolver a maior parte do meu problema. Você postou exatamente quando enviei minha resposta acima.
Por favor, verifique este site; ele possui todos os redirecionamentos que você precisa? Isso é feito com apenas um bloco replace (veja acima) e esta configuração de DNS (apenas redigi os registros TXT de e-mail):
Não recebo nenhum aviso no console.
Sim, apenas esteja preparado para que isso falhe quando a configuração do Let’s Encrypt mudar.
Quando o Let’s Encrypt foi atualizado para suportar curvas elípticas, a abordagem em que você está confiando acima foi quebrada por algumas semanas.
A única diferença é que eu não tenho o registro CAA no meu DNS. Vou adicioná-lo usando o mesmo valor que você utilizou.
Presumo que o hostname do seu Discourse seja www.example.com. Tem certeza de que não recebe um aviso ao acessar https://example.com?
O aviso é ainda mais grave no Chrome para Android: ele bloqueia o site completamente e não redireciona.
Você me perdeu agora 
O que preciso ficar atento ou estar preparado para corrigir?
Correto.
Sim, tenho certeza, nenhum aviso no console.
Acho que encontrei o problema. Eu tinha isso:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
Quando deveria ter:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com --keylength"
Note a última linha: eu tinha example.com e www.example.com.
Também alterei return 301 https://$host$request_uri; para return 301 $scheme://$host$request_uri;. Após uma nova compilação, parece que está funcionando.
Agora, estou apenas preocupado com o que @Stephen mencionou sobre isso quebrar quando a configuração do Let’s Encrypt mudar.
Uma alteração em 9 de setembro do ano passado quebrou a abordagem que você está seguindo e, como a implementação está fora da instalação padrão, só em 31 de outubro foi publicada uma solução. Se você examinar o tópico que seguiu e o histórico de edições na wiki, verá que está claramente documentado.
Como você não está fazendo algo que exija se meter profundamente em configurações adicionais, eu recomendo contra isso. Por outro lado, quando o Let’s Encrypt realmente mudar e você for afetado, podemos remetê-lo de volta a este tópico.