Un’installazione o una ricostruzione di Discourse può rifiutare un certificato Let’s Encrypt valido con:
C=US, O=Let's Encrypt, CN=YR2
error 2 at 1 depth lookup: unable to get issuer certificate
error fullchain.cer: verification failed
Ho riprodotto il problema immediatamente dopo un’emissione RSA riuscita. Il controllo fallito innesca una richiesta --force non necessaria, che può portare a errori HTTP 429 / rateLimited / “too many certificates”. Nella mia installazione, l’emissione ECDSA è stata quindi bloccata e HTTPS non è stato avviato.
Con le catene di certificati interessate, ogni ricostruzione o riavvio del contenitore può innescare una reimmissione forzata non necessaria dei certificati RSA ed ECDSA, anche se sono ancora validi. Le reimmissioni riuscite consumano la quota di Let’s Encrypt, quindi ricostruzioni o riavvii ripetuti possono raggiungere rapidamente il limite di frequenza.
Questo può passare inosservato mentre HTTPS continua a funzionare con i certificati già installati. L’eliminazione e la reinstallazione di un’istanza con lo stesso nome host non reimpostano tale quota. Se i certificati richiesti mancano nella nuova installazione, l’emissione limitata dalla frequenza può impedire l’avvio di HTTPS.
Correzione
In templates/web.letsencrypt.ssl.template.yml, all’interno di cert_exists(), sostituire:
- openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
+ openssl verify -untrusted ca.cer fullchain.cer
Mantenere il resto della funzione invariato. Il template corretto deve essere incluso nella prossima ricostruzione del contenitore per aggiornare /usr/local/bin/letsencrypt.
Se si è già raggiunta la limitazione di frequenza, la patch non reimposta la quota. Applicare la correzione e rispettare il tempo retry after prima di tentare ulteriori emissioni.
Conferma del problema di verifica della catena
Dal directory del certificato interessato all’interno del contenitore (/shared/letsencrypt/<hostname>, o <hostname>_ecc), confrontare:
openssl verify -CAfile <(openssl x509 -in ca.cer) fullchain.cer
openssl verify -untrusted ca.cer fullchain.cer
Nel caso riprodotto, il primo comando fallisce con l’errore 2; il secondo restituisce:
fullchain.cer: OK
Causa e validazione
openssl x509 -in ca.cer legge solo il primo certificato dal bundle dell’emittente. Nella catena YR2 osservata, elimina il Root YR cross-firmato necessario per raggiungere ISRG Root X1.
-untrusted ca.cer fornisce il bundle completo dell’emittente mantenendo gli ancoraggi di fiducia nello store di sistema, preservando l’intento della correzione del 2021 (#576).
Ho verificato le catene RSA ed ECDSA effettive all’interno del contenitore. Una ricostruzione completa con la patch ha riutilizzato entrambi i certificati esistenti: due messaggi Skip, entrambe le catene installate e nginx -t superato.