Cosa dice il file log/production.log (nel docker in esecuzione) quando provi a effettuare il login con un errore (quindi con force_https=true)?
@RGJ – Mi piace la tua soluzione! Devo usare force-https con l’ultimo suggerimento? Riguardo a proxy_pass https.
MODIFICA: Ottengo un errore 502 se uso solo proxy_pass https://192.168.86.108.
MODIFICA 2: Ho disabilitato la porta 80 su Discourse tramite app.yml e funzionava comunque male – ho appena rilettto il tuo post: il container di Discourse ha la propria istanza di Nginx? Quindi, in pratica, sto passando un proxy a un proxy? Scusa, sono davvero confuso a questo punto.
@itsbhanusharma commento fuori 80:80 #http e seguo il consiglio di @RGJ per proxy_pass https?
Perché non state seguendo il processo supportato per i multisiti in questo caso? State di fatto reinventando una ruota estremamente fragile.
Sono stati forniti così tanti link, @Stephen, che non riesco a capirci più nulla. Pensavo di seguire le procedure supportate. I commenti sopra non sono supportati? 
Sì, perché non stavi utilizzando force_https, da cui il tag unsupported-install sopra. Se ti discosti da una versione supportata, non riceverai molto aiuto.
Inizia qui:
Esiste una guida separata per gestire l’incapsulamento SSL con multisito.
Quindi, il contenitore standard esegue solo http? In che modo ciò che sto cercando di fare è multi-sito? Non sto cercando di ospitare più domini; ho un singolo dominio. Potete chiarire come questo risolva il mio problema?
Cosa intendevi con:
Ho configurato server Discourse in circa 5 istanze e tutte sembrano mostrare comportamenti strani; non sono sicuro che si tratti davvero di un bug o se qualcun altro abbia avuto la stessa esperienza.
Infrastrutture indipendenti, in nessun modo collegate tra loro.
Ma tutte con impostazioni molto simili come sopra indicato.
Allora, perché nginx sta facendo da proxy per l’host in primo luogo? Cosa altro sta accadendo sulle macchine?
Abbiamo diverse VM che non sono esposte esternamente; il traffico viene instradato attraverso il proxy (che è esposto esternamente) verso la VM Discourse internamente. Situazione simile in ciascuna delle installazioni separate. Questo chiarisce?
Non proprio, ma in un modo o nell’altro questa è una difficoltà tecnica con cui dovrai semplicemente convivere. È impossibile commentare se esista un approccio migliore quando il caso d’uso e la topologia sono così ambigui.
Credo che la combinazione giusta di soluzioni sia stata la seguente:
Come indicato da @itsbhanusharma:
MODIFICA /var/discourse/containers/app.yml e modifica le porte con dei valori personalizzati; io ho usato:
- "8080:80" #http
- "4343:443" #https
Ho eseguito ./launcher rebuild app.
Successivamente ho modificato il nostro proxy accessibile dall’esterno per inoltrare le richieste su 80/443 verso http://internal_ip:8080.
Dopo aver eseguito sudo nginx -t e sudo systemctl restart nginx, ho effettuato il login sul server https://discourse.mobiusnode.io (che presentava ancora i problemi sopra descritti) e ho abilitato force_https; da quel momento sembra che tutto funzioni correttamente.
Ora procederò a riprodurre questa configurazione sugli altri server/infrastrutture.
Solo per chiarire, non è questo che ho suggerito.
Ho solo chiesto di esporre la porta 80 su un IP locale e di terminare SSL sul tuo reverse proxy.
Quindi, non utilizzare SSL sul mio proxy esposto esternamente, ma inoltrare invece le richieste http in chiaro al server Discourse e lasciare che force_https gestisca tali richieste? Come viene poi passato il certificato? Attraverso la prima istanza di Nginx? È qui che le cose si bloccano per me.
Bene, purché funzioni e tu possa ricostruire/aggiornare in modo pulito. Sembra che tu stia già facendo ciò che @itsbhanusharma ha suggerito nel suo ultimo post.
Se stai condividendo un singolo IP con più connessioni SSL, hai bisogno di un certificato SAN sul lato frontale del tuo proxy. Se la rete è sicura, tutto ciò che si trova dietro di essa può essere non crittografato.
Discourse richiede force_https se l’utente si connette tramite SSL, e devi assicurarti che l’intestazione indicata sopra venga preservata e inoltrata.
No, esiste qualcosa chiamato SNI.
Ne sono ben consapevole, ma dato che tutti i certificati provengono da Let’s Encrypt, qual è il valore nel richiedere certificati separati? Let’s Encrypt supporta gli SAN, quindi perché non utilizzarli?