Aspetta… credo di averlo risolto… ho disabilitato il proxy e ricostruito senza il template Cloudflare. Ho riattivato il proxy e ora riesco ad accedere a WordPress e al forum con SSL stretto!
Saresti soggetto a limitazioni di velocità molto facilmente se scegliessi di non utilizzare il template Cloudflare…
Discourse penserebbe che molte persone si stiano registrando dallo stesso indirizzo IP (proxy Cloudflare) e inizierebbe a limitarne la velocità.
Hmm… allora è meglio rifarlo senza l’email di Let’s Encrypt ma con il template di Cloudflare… sai se dovrei lasciare il proxy abilitato quando ricompilo con il template di Cloudflare?
Grazie mille per tutto l’aiuto… sono davvero più una persona creativa.
È il mio registrar, non solo il DNS… e non posso permettermi di pagare la somma enorme che richiedono per usare un DNS diverso. Quindi, ops.
La configurazione di Discourse non richiede più un indirizzo email per l’iscrizione ai certificati, e non lo richiedeva da un po’ di tempo. A meno che non modifichi il file YAML per disabilitare SSL, l’impostazione predefinita sarà sempre HTTPS.
Utilizzare Cloudflare per il DNS e attivare la nuvola arancione sono due cose completamente diverse. Nel contesto di cui sopra, l’uso di Cloudflare si riferisce al loro servizio di proxy e ottimizzazioni, che in passato hanno causato alcuni problemi. Il loro DNS è invece ottimo, anche molto buono.
La tua installazione di Discourse non ha bisogno di modifiche: hai già HTTPS funzionante e tutto è a posto. Se SSL funziona e il template di CloudFlare è abilitato, non toccare nulla.
Sembra che il problema sia ora a livello di WordPress: come lo hai installato? È solo un VPS o utilizzi un hosting WordPress di qualche tipo?
Questa è una configurazione molto comune; sono abbastanza sicuro che sia una soluzione semplice da applicare.
Questa è una VeriBrIdea. Una volta che Discourse ha registrato il certificato presso Let’s Encrypt, i rinnovi avranno successo poiché avvengono tramite un meccanismo diverso. Non c’è alcuna necessità di disabilitare TLS tra server e CDN.
Perché farlo considerando quanto detto sopra? Oltre a creare un carico aggiuntivo di elaborazione locale per le regole UFW su tutto il traffico, rischi semplicemente che le tue regole diventino obsolete; è un modo rapido per generare numerosi errori di rete. Cloudflare mette periodicamente online nuovi intervalli di indirizzi IP; la prima volta che ne verrai a conoscenza sarà quando i tuoi utenti non potranno più accedere al sito. Lascia che il certificato venga registrato e, se desideri comunque utilizzare CloudFlare, configura semplicemente una regola di pagina di conseguenza.
Utilizzo Cloudflare in modalità solo DNS, è molto semplice. Basta cliccare e disattivare la “nuvola arancione” nel pannello di controllo DNS, in modo che la nuvola diventi grigia. È tutto ciò che serve.
Questo non funziona più come una volta. Se non vuoi utilizzare Let’s Encrypt, devi configurare manualmente invece di usare discourse-setup
Quale certificato otterrebbe Discourse in assenza di un indirizzo email di Let’s Encrypt? Uno generato autonomamente o un certificato emesso con un indirizzo email arbitrario?
In entrambi i casi, dovrebbe comunque funzionare correttamente con SSL di Cloudflare, poiché permettono host con certificato valido nella loro configurazione Full SSL e superiori.
Dovrai controllare il codice sorgente, poiché non lo ricordo con precisione. Credo che utilizzi l’email dell’amministratore. Se il controllo per verificare che il server sia disponibile sulla porta 443 fallisce, rifiuterà l’installazione.
Potrei avere assolutamente torto qui, ma da questo
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 per saltare"
else
local letsencrypt_status="Inserisci 'OFF' per disabilitare."
fi
sembra che il controllo della configurazione predefinita dovrebbe offrire la possibilità di inserire “off” per disabilitare Let’s Encrypt? Forse ho completamente torto e sto guardando nel posto sbagliato?
Disabilitare Let’s Encrypt non è la soluzione.
In un’installazione standard, non lo è.
In un’installazione avanzata (ad esempio, qualcuno che utilizza un proxy inverso), è assolutamente una risposta.
Potresti spiegare più nel dettaglio il motivo?
È semplice far funzionare lo scenario del certificato. Anche se gestisci un secondo server web sullo stesso server e fai il proxy localmente, è facile far funzionare il certificato, quindi perché non farlo?
Perché dovrei richiedere più certificati?
Se posso semplicemente richiedere un unico certificato (unificato) da Let’s Encrypt tramite il reverse proxy (ad esempio nginx o Caddy), perché vorresti un secondo certificato all’interno del contenitore Discourse, dato che non verrà utilizzato da nulla?
Penso che la risposta generale sia evitare completamente la complessità del proxy, se possibile 
Ma diventa inevitabile non appena si inizia a considerare un deployment che va oltre la configurazione standard di uno o due container.
Il tuo forum deve diventare davvero molto grande per aver bisogno di qualcosa come il proxy di Cloudflare. È qualcosa da considerare quando il forum inizia a essere sopraffatto. A meno che tu non stia migrando un forum di grandi dimensioni verso Discourse, nessuno che sta installando Discourse dovrebbe pensarci.
Non sono affatto d’accordo: configurare correttamente HTTPS è semplice. In questo caso, l’utente ha due siti su due server diversi sotto un singolo dominio.
Non c’è alcun motivo tecnico per cui entrambi i siti non possano essere serviti via HTTPS, indipendentemente dall’attivazione di CloudFlare. È facile da fare una volta compreso il metodo di registrazione utilizzato da Let’s Encrypt e come configurare CloudFlare per Discourse. CloudFlare offre una modalità HTTPS completa, pensata proprio per questo scenario: TLS dal server alla loro rete, TLS dalla loro rete ai client, con decrittazione intermedia per consentire caching e “ottimizzazione”, anche se nel caso di Discourse sappiamo che quest’ultimo aspetto non funziona molto bene.
Principalmente per questo, anche se c’è sicuramente un vantaggio nell’avere una regola di pagina che metta in cache /uploads/: aiuterà a ridurre il carico per un po’ e permetterà a un VPS di fascia bassa di durare un po’ di più.