La prima volta in assoluto che ho ricevuto un promemoria da Redsift che i miei certificati scadranno tra una settimana. Di solito discourse rinnova i certificati con largo anticipo. Questa volta no, prima di iniziare a fare una ricostruzione (che dovrebbe risolvere il problema), @Falco c’è qualcosa che vuoi che controlli e che ti riporti qui per aiutare a capire la causa per cui i certificati non sono stati rinnovati?
La radice del certificato è ISRGX1 e qui ci sono le informazioni sul certificato in scadenza:
Ma è passato più di un giorno da quando ho aggiornato il software del forum e il certificato non sembra essere stato ancora aggiornato. Ha 5 giorni prima della scadenza, quindi deve essere rinnovato presto.
Sono sul ramo stabile di Discourse, se questo fa la differenza. È possibile che la correzione dell’endpoint non sia stata retroportata?
Abbiamo avuto la stessa esperienza di SSL non rinnovato.
Sarebbe fantastico se qualcuno potesse ricontrollare che web.ssl.template si comporti correttamente su discourse-docker, mi è sembrato che la porta 80 non servisse effettivamente URL /.well-known/ utilizzati da Let’s Encrypt, tutti gli URL venivano inoltrati a SSL inclusi file di test che ho posizionato manualmente in /var/www/discourse/public/.well-known/ . Ho dovuto modificare /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf direttamente all’interno del container dell’app.
Anche qui. Non ho ricevuto un avviso sulla scadenza del certificato. Accedere al server e avviare una ricostruzione /var/discourse % ./launcher rebuild ha risolto il problema.
Nella mia sperimentazione su un’installazione vanilla di nginx (1.18.0 ma penso sia lo stesso per 1.26.3), una riga di configurazione nginx return 301 https://thehostname$request_uri; al di fuori di una location sovrascrive completamente qualsiasi blocco location precedente, anziché fungere da catch-all. Credo che /.well-known/ semplicemente non venga servito sulla porta 80 a meno che il reindirizzamento 301 non sia specificamente per un’altra location come / alla fine del blocco server. Potrebbe essere lo stesso problema di questo post di stackoverflow?
Sono contento che rebuild funzioni, ma poiché il certificato si era già rinnovato per me, non ho potuto confermare se un rebuild avrebbe permesso ai server di validazione Let’s Encrypt di raggiungerlo se un certificato fosse scaduto. Forse un rebuild avvia il rinnovo del certificato prima che quella riga del template sia in atto o simile, piuttosto che correggere i template, ma non sono in grado di confermare se è per questo che rebuild ottiene il rinnovo.
Posso confermare che il rinnovo di letsencrypt fallisce. Gestisco un’installazione Discourse self-hosted da anni, e molto stranamente il rinnovo è fallito per me due volte di seguito negli ultimi due mesi. La seconda volta è stata questa mattina, e così ho iniziato a indagare.
L’ho ricondotto ai seguenti due commit:
E la riga pertinente collegata:
Ci sono due problemi, credo.
Primo, return 301 https://${DISCOURSE_HOSTNAME}$request_uri; viene trasformato in return 301 https://<NOME_MIO_SERVER> senza un $request_uri alla fine. L’ho verificato sulla mia installazione self-hosted, e anche su quella di un amico impostata la scorsa settimana. Non capisco come funzioni il template di Discourse, quindi non so perché venga eliminato.
Secondo, come menzionato da @lessLost, il redirect 301 è al di fuori del blocco location. Credo che un redirect a livello di server sovrascriva tutti i blocchi location. LetsEncrypt usa http per i rinnovi. Tuttavia, qualsiasi tentativo di curl -I http://TUA_DOMINIO/.well-known/acme-challenge/test restituirà un 301 a https, invece di un 404 (che è il comportamento atteso; vogliamo un 404 non un 301).
Ho risolto questo problema manualmente sulla mia installazione self-hosted, ma mi aspetto che qualsiasi aggiornamento sovrascriva le mie modifiche. Purtroppo non capisco abbastanza i template per inviare una pull request @pfaffman — altrimenti lo farei anch’io.
Modificato per aggiungere:
Credo che questo sia un errore —
Sono abbastanza certo che LetsEncrypt usi http per impostazione predefinita (per ovvie ragioni, se il certificato è scaduto non può rinnovarsi!) Ma posizionare il 301 a livello di blocco server forza tutte le richieste a 301 su https, il che è incoerente con questa strategia di rinnovo.
Questa mattina, circa 10 minuti dopo essermi svegliato, ho visitato il mio forum e ho capito che il certificato era scaduto di nuovo. (Ricostruire è ciò che lo ha rinnovato l’ultima volta che mi è scaduto — circa 3 mesi fa?)
Penso che abbiano apportato modifiche da allora che hanno risolto questo problema, ma dato che ci vogliono 3 mesi per scoprirlo, il verdetto è ancora sospeso. Potresti impostare un promemoria un paio di settimane prima della scadenza del certificato corrente.
La nuova installazione del sito del mio amico risale a una settimana fa. La riga 37 del modello sopra riporta: return 301 https://${DISCOURSE_HOSTNAME}$request_uri; ma nel container Docker di Discourse, sia il suo che il mio /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf riporta return 301 https://<il_tuo_sito_discourse>; Nota come $request_uri venga rimosso. Qualcosa lo sta facendo svanire! (Non so cosa).
Ho eseguito un rinnovo forzato simulato questa mattina come parte della mia indagine. È fallito. Ho poi modificato /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf. Ha avuto successo!
In realtà va bene; modificherò manualmente 20-redirect-http-to-https.conf ogni volta che aggiorno Discourse. Per coloro che si imbattono in questo commento, il comando da eseguire è:
Non sono del tutto sicuro di cosa stia causando questo fallimento, ma so che modificare il conf sopra lo risolve. Ma ho anche modificato le notifiche in modo che i rinnovi di letsencrypt non falliscano più silenziosamente — così posso avere un preavviso. Volevo solo farti sapere!