Serve aiuto con doppio container. Problema con LetsEncrypt da qualche giorno

Sto arrivando a un punto di disperazione, perché provare a far risolvere questo problema al Bot di Discourse o a Claude sembra impossibile. Non riesco davvero a spiegare il problema, perché non sono così informato, e credo che sia proprio questo a farmi più male.

Proverò a spiegare cosa è successo, dal mio punto di vista.

Quando stavo passando da un singolo contenitore a due contenitori, il file in samples/ usava web-only e, per errore, l’ho lasciato così invece di usare web_only.

Poi, a causa di questo (credo), le mie immagini non venivano caricate, perché una “cosa” si aspettava che puntasse a web_only, ma era impostata su web-only. Ho apportato alcune modifiche e le immagini sono state riparate. Il problema ora sono i certificati LetsEncrypt.

Ho chiesto al bot di aiutarmi a risolverlo; mi ha detto di aspettare il giorno successivo, perché il problema era il limite di frequenza (rate-limit) dei certificati. Il problema avrebbe dovuto risolversi. Non è successo. Poi l’ho chiesto di nuovo, poi ho chiesto a Claude, poi di nuovo a Claude… e da una settimana siamo in questo “aspetta fino a domani alle X ore e si risolverà”. Non si risolve mai, entrambi dicono “oh, mi dispiace, non avrei dovuto dare per scontato che si sarebbe risolto, proviamo questo invece, perché ora si risolverà davvero”. Non succede mai.

Il sito web stesso è attivo e funzionante, ma sento che ogni volta che voglio ricostruire, succederà qualcosa, e onestamente non voglio fare affidamento su cerotti tutto il tempo.

Claude mi ha detto di aggiungere qualcosa agli hook in web_only.yml, ma dato che nulla di simile è menzionato nelle istruzioni fornite qui sul forum, mi aspettavo una soluzione diversa, come… risolvere il problema reale.

Qualcuno può per favore aiutarmi a capire qual è il problema e dove le cose si rompono? Lo apprezzerei davvero, perché a questo punto è esaurente. Non il lavoro, ma il non capire cosa sta succedendo e perché “aspetta fino a domani” non sembra mai risolvere nulla.

Grazie!


Ho chiesto a Claude di spiegare qual sembra essere il problema, forse aiuta? Ecco cosa ha detto:

Titolo: Setup a due contenitori: cartella certificati ECC mancante dopo la separazione, loop --force che colpisce il limite di frequenza ad ogni avvio

Setup: Due contenitori (data + web_only), migrati da standalone. Template: web, ratelimited, ssl, letsencrypt, cloudflare. Nome host alltiago.com, nessun alias.

Sintomo: Ad ogni avvio di web_only viene raggiunto il limite di frequenza di Let’s Encrypt e nginx non riesce a servire, restituendo errori di connessione finché le righe ECC non vengono rimosse manualmente da /etc/nginx/conf.d/outlets/server/20-https.conf.

Cosa ho trovato:

/shared/letsencrypt/alltiago.com_ecc/ non esiste nel mio install. /shared/letsencrypt/alltiago.com/ (RSA) esiste e funziona bene, rinnovandosi normalmente.

In web.letsencrypt.ssl.template.yml:

cert_exists() {
  [[ "$(cd ${LETSENCRYPT_DIR}/${DISCOURSE_HOSTNAME}$1 && openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer | grep "OK")" ]]
}

issue_cert "ec-256"
if ! cert_exists "_ecc"; then
  issue_cert "ec-256" "--force"
fi

Poiché la directory è mancante, cert_exists "_ecc" fallisce ad ogni avvio, quindi --force viene eseguito e richiede un nuovo certificato ECC a prescindere da ciò che è su disco. Questo avviene tramite l’hook after_ssl che applica una patch a /etc/runit/1.d/install-ssl, quindi si esegue ad ogni avvio del contenitore, non solo durante il bootstrap.

Risultato: 429 too many certificates (5) already issued for this exact set of identifiers in the last 168h. Poi --installcert viene eseguito comunque contro la directory vuota e scrive un /shared/ssl/alltiago.com_ecc.cer inutilizzabile. nginx è configurato con entrambi i certificati, non riesce a caricare quello ECC e non servirà nulla.

Confermato funzionante: La validazione ACME HTTP-01 ha successo (testato tramite staging, certificato ECC emesso senza problemi contro letsencrypt_test, struttura della directory corretta creata). Il certificato RSA è stato rinnovato con successo oggi. Quindi questo non è un problema di DNS, firewall o validazione.

Domande:

  1. C’è un modo supportato per ricreare alltiago.com_ecc/ senza aspettare che scada il limite di frequenza?
  2. cert_exists che restituisce falso dovrebbe davvero attivare --force piuttosto che una normale emissione? --force bypassa il controllo del “certificato valido esistente” e garantisce l’esaurimento del limite di frequenza quando la directory è assente.
  3. C’è un modo documentato per eseguire solo RSA?

Due note fattuali affinché il thread non prenda una direzione sbagliata: la data di ripartenza è passata dal 27 agosto al 29 agosto perché il rinnovo RSA di oggi ha consumato uno slot nella finestra mobile di 168 ore. E la ragione per cui nessun altro riporta questo problema è che in un’installazione normale entrambe le directory vengono create al primo avvio e la branch --force non viene mai eseguita.

Aspetta. https://alltiago.com/ sembra funzionare senza problemi. Ma ecco cosa avrei consigliato

Sì, ma è un po’ complicato. Se richiedi un certificato DIVERSO, puoi ricominciare la conta da zero.

Quello che probabilmente consiglierei è aggiungere www al nome host in modo da ottenere certificati per entrambi (ma forse l’hai già fatto, quindi potresti aggiungere un terzo nome, solo per ottenere un nuovo certificato).

Set up Let’s Encrypt with multiple domains / redirects dovrebbe aiutare.

Sì, funziona, perché mi è stato detto di usare una “benda” relativa a nginx. Non riesco davvero a spiegare di cosa si tratta, perché non lo capisco.
Ma il problema è che se poi voglio fare un rebuild normale, avrò problemi (almeno, da quanto mi è stato detto ora, se lo faccio prima del 29 agosto, quando, si spera, il certificato verrà ripubblicato. A questo punto, non posso davvero fidarmi di nessuna di queste informazioni.

Sì, www c’è già da quando ho installato Discourse per la prima volta l’anno scorso.

Ora, dopo aver spinto Claude al limite per farmi capire cosa stesse succedendo, ecco cosa ho ottenuto, e sentiti libero di contestarlo, perché sono qui per imparare quando possibile:

  • L’ECC, che sembra essere il problema attuale, non è davvero necessario, perché l’RSA è l’impostazione predefinita e tutti potranno comunque accedere al mio sito web senza problemi, se rimuovo completamente l’ECC.
  • Come ho detto, si spera che, il 29 agosto, questo intero problema sarà risolto, una volta che i 168h si azzereranno e anche il limite di 5 certificati verrà ripristinato:
sudo docker exec web_only grep -i "retry after" /shared/letsencrypt/acme.sh.log | tail -1
  "detail": "too many certificates (5) already issued for this exact set of identifiers in the last 168h0m0s, retry after 2026-08-29 03:43:15 UTC: see https://letsencrypt.org/docs/rate-limits/#new-certificates-per-exact-set-of-identifiers",
  • Se il 29 agosto le cose non tornano alla normalità, Claude consiglia di rimuovere l’ECC. Ecco cosa ha detto quando gli ho chiesto quale file sarebbe stato modificato e quale sezione:

File: la copia che stiamo per creare, web.letsencrypt.rsa-only.template.yml (lasciando intatto il tuo file originale di fabbrica come fallback).

Cosa viene rimosso al suo interno: questo intero blocco, trovato nella sezione /usr/local/bin/letsencrypt del file:

########################################################
# ECDSA cert
########################################################
issue_cert "ec-256"

if ! cert_exists "_ecc"; then
  # Try to issue the cert again if something goes wrong
  issue_cert "ec-256" "--force"
fi

LE_WORKING_DIR="${LETSENCRYPT_DIR}" ${LETSENCRYPT_DIR}/acme.sh \
  --installcert --ecc \
  -d ${DISCOURSE_HOSTNAME} \
  --fullchainpath /shared/ssl/${DISCOURSE_HOSTNAME}_ecc.cer \
  --keypath /shared/ssl/${DISCOURSE_HOSTNAME}_ecc.key \
  --reloadcmd "sv reload nginx"

Questa è l’intera sezione ECC, nessun’altra parte del file viene modificata. La sezione RSA subito sopra resta esattamente come è.

Un altro file viene modificato dopo: containers/web_only.yml, per puntare a questa nuova copia invece del template di fabbrica. Lo faremo come un passo separato, in una fase successiva.

Sì. No. Non cambierei nessun template.

Penso che il modo più semplice sia aspettare e poi ricostruire con i template standard. A meno che tu non voglia ricevere supporto dall’AI, anziché da chiunque altro che sappia usare Discourse, per sempre.

Ho chiesto a Claude di seguire il tuo consiglio aggiungendo www come nuova richiesta di certificato (se è così che si chiama?). Sembra che ora stia funzionando.

Quando ho chiesto quali file fossero residui di tutto questo processo, ho ottenuto questa risposta:

Ecco cosa c’è effettivamente, suddiviso tra ciò che risale a stasera e i residui più vecchi di prima di questa conversazione:

Da stasera (questa sessione):

  • /tmp/acme.sh.txt — la copia dello script che hai chiesto di scaricare, puoi eliminarla in sicurezza ora che la hai sul tuo Mac
  • /tmp/crtsh.json — file vuoto da 150 byte derivato dall’errore 502 di crt.sh, spazzatura, sicuro da eliminare
  • /root/discourse-backup-20260827-1857.tar.gz — il backup vero e proprio di poco fa (configurazioni SSL/letsencrypt), questo in realtà vale la pena conservarlo, non è spazzatura

Più vecchi, di prima di questa conversazione (23 e 25 agosto), non li ho messi io io:

  • /tmp/app.yml
  • /tmp/check.png, /tmp/check162.png, /tmp/after.png, /tmp/rendered_avatar.png

Non so a cosa servano quelli più vecchi, risalgono a prima di qualsiasi cosa fatta stasera, probabilmente sono residui di una precedente sessione di risoluzione dei problemi (tua, del bot o di una chat precedente con Claude). Li riconosci, o vuoi che ti aiuti a capire da dove provengono prima di decidere se eliminarli?

Niente di sospetto è apparso al di fuori di /tmp e /root, la scansione più ampia del sistema è tornata pulita, solo normali file di log.


Posso procedere con l’eliminazione di tutti questi?

Dovrei quindi annullare ciò che ho appena fatto?

Non ho alcun problema a parlare con esseri umani reali, ma non voglio semplicemente fare tutte le domande qui e inondare il forum con l’intero processo (output/log da Terminale), e preferisco piuttosto arrivare con qualcosa che funziona già “abbastanza” per rendere la conversazione un po’ più breve. Tutti abbiamo le nostre vite e tempo limitato, e non voglio tuffarmi subito nel forum, a meno che non mi imbatta davvero in un muro, capisci?

Apprezzo il tuo aiuto!
Quindi, in questo momento, dovrei annullare ciò che ho fatto? Vedi qualche problema con quell’approccio rispetto al semplice aspettare il 29?