No, nessun’installazione aggiuntiva necessaria.
Inoltre, l’unico blocco che ho dovuto aggiungere è:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d mywebsite.org --keylength"
(Il reindirizzamento da HTTP a HTTPS sembra funzionare correttamente senza gli altri due blocchi replace, quelli con nginx)
Alla fine ho trovato il tempo per lavorare sulle guide “Configurazione di Let’s Encrypt con più domini” e “Reindirizzamento di uno o più domini alla tua istanza Discourse”.
Ho aggiunto molto di più al mio file containers/app.yml rispetto a quanto hai fatto tu e quasi tutto funziona correttamente.
Il mio Discourse è ospitato sul sottodominio www e il mio obiettivo era reindirizzare le richieste HTTP e HTTPS dal dominio apice al sottodominio www. Ora funziona, ma se vado su https://mydomain.com, anche se avviene il reindirizzamento, Chrome mostra il seguente avviso nella console:
Reindirizzamento della navigazione example.com -> www.example.com perché il server ha presentato un certificato valido per www.example.com ma non per example.com. Per disabilitare tali reindirizzamenti, avvia Chrome con il flag seguente: --disable-features=SSLCommonNameMismatchHandling
Ecco le mie aggiunte al file 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'; # ricorda il certificato per un anno e connettiti automaticamente a HTTPS per questo 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;
}
Sembra tutto corretto? In tal caso, esiste una soluzione al problema di disallineamento del nome del certificato?
EDIT: Ho due record A, uno per il sottodominio www e un altro che utilizza @ per intercettare tutte le richieste al dominio apice. Entrambi puntano all’IP del mio droplet Digital Ocean. Immagino che anche questo sia corretto?
Grazie.
Gratuita da implementare, anche se Cloudflare non è il tuo registrar. Funziona con https, senza complessità aggiuntive nella tua installazione di Discourse.
Grazie, al momento non sto utilizzando Cloudflare, quindi non mi ero imbattuto in quelle soluzioni prima. Ho scelto un percorso diverso e ho seguito le guide sopra riportate, riuscendo in gran parte a risolvere il mio problema. Hai pubblicato proprio mentre inviavo la mia risposta qui sopra.
Controlla questo sito web; contiene tutti i reindirizzamenti di cui hai bisogno? È realizzato con un unico blocco replace (vedi sopra) e questa configurazione DNS (ho oscurato solo i record TXT dell’email):
Non ricevo alcun avviso nella console.
Sì, sii solo pronto a vedere tutto rompersi quando la configurazione di Let’s Encrypt cambierà.
Quando Let’s Encrypt è stato aggiornato per supportare le curve ellittiche, l’approccio su cui ti stai affidando qui sopra è stato interrotto per un paio di settimane.
L’unica differenza è che non ho il record CAA nel mio DNS. Lo aggiungerò con lo stesso valore che hai usato tu.
Immagino che il hostname di Discourse sia www.example.com; sei sicuro di non ricevere un avviso quando accedi a https://example.com?
L’avviso è ancora più grave con Chrome su Android: blocca completamente il sito e non reindirizza.
Mi hai fatto perdere il filo 
Di cosa devo stare attento/essere pronto a sistemare?
Corretto.
Sì, ne sono certo, nessun avviso nella console.
Credo di aver individuato il problema. Avevo impostato questo:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com -d www.example.com --keylength"
Invece avrei dovuto avere:
after_ssl:
- replace:
filename: "/etc/runit/1.d/letsencrypt"
from: /--keylength/
to: "-d example.com --keylength"
Notate l’ultima riga: avevo sia example.com che www.example.com.
Ho anche modificato return 301 https://$host$request_uri; in return 301 $scheme://$host$request_uri;. Dopo un rebuild sembra che tutto funzioni.
Ora sono solo preoccupato per quanto menzionato da @Stephen riguardo alla possibilità che si rompa quando la configurazione di Let’s Encrypt cambia..
Un cambiamento del 9 settembre dello scorso anno ha interrotto l’approccio che stai seguendo e, poiché l’implementazione non rientra nell’installazione standard, una soluzione è stata pubblicata solo il 31 ottobre. Se osservi l’argomento che hai seguito e la cronologia delle modifiche sulla wiki, è chiaramente documentato.
Dato che non stai eseguendo qualcosa che richieda di metterti le mani fino ai gomiti in configurazioni aggiuntive, sconsiglio di farlo. D’altro canto, quando Let’s Encrypt cambierà e tu ne sarai interessato, potremo rimandarti a questo argomento.