Questo sembra proprio essere un problema dal lato del tuo sito web.
Il certificato fornito dal server è corretto ed è accettato dalla quasi totalità dei browser: il problema è che molti server più vecchi non dispongono del certificato root (relativamente) nuovo nel loro archivio di fiducia, quindi molte operazioni automatizzate stanno generando errori al momento.
Non conosco il tuo sito esatto, quindi ho preso un sito arbitrario hosted-by-discourse.com e l’ho sottoposto al Qualys SSL Server Test.
Come puoi vedere, la radice del secondo percorso di certificazione è effettivamente scaduta, ma questo è mitigato dal fatto che il certificato ISRG Root X1 è presente nell’archivio di fiducia (cioè incluso nel tuo browser e/o sistema operativo) per il primo percorso di certificazione.
I server in genere non aggiornano frequentemente il proprio archivio di fiducia, quindi è probabile che il tuo server non abbia il certificato ISRG Root X1 nel suo archivio di fiducia. (Questo è accaduto anche all’immagine Docker per la ricezione della posta).
Puoi trovare un bundle aggiornato, ad esempio, su https://curl.se/ca/cacert.pem. Su CentOS, quel file va in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. Su Ubuntu puoi usare il comando update-ca-certificates, che aggiorna /etc/ssl/certs/ca-certificates.crt.
In alternativa, potresti disabilitare temporaneamente la verifica del certificato SSL nel codice del tuo server.
Ho pubblicato l’output di openssl per dimostrare che non c’entra nulla con il nostro sito web; inoltre, Postman viene eseguito da una macchina Windows locale.
Modifica: non sono così esperto dei diversi livelli di archivi di fiducia, ci darò un’occhiata più da vicino; il problema si verifica su ogni macchina che proviamo.
Questa è una risposta che ho ricevuto dal nostro responsabile DevOps.
Il problema è che esistono due copie di ISRG Root X1: una è stata emessa da DST Root CA X3 molto tempo fa, mentre quella più recente è autofirmata dall’ISRG (il gruppo che gestisce Let’s Encrypt, tra le altre cose) e questa CA radice autofirmata è ora accettata come CA radice attendibile sulla maggior parte dei sistemi.
Si tratta dello stesso certificato di firma, quindi è possibile convalidare qualsiasi cosa che dichiari di essere stata emessa da ‘ISRG Root X1’ utilizzando entrambe le versioni. Tuttavia, quella firmata da DST non è più valida come percorso di certificazione, poiché il certificato DST che l’ha firmata è ora scaduto.
Se il server stesse facendo la cosa giusta e fornisse la versione più recente di ISRG Root X1 (quella autofirmata), il client confronterebbe quello fornito con il proprio archivio di fiducia, verificherebbe che si tratti dello stesso certificato e procederebbe correttamente. Invece, rileva il certificato fornito, pensa: “Ok, devo convalidarlo contro DST Root CA X3 che ho in archivio… ops, è scaduto” e fallisce la verifica.
Fornire un certificato nella catena di certificati che ci si aspetta di trovare nel deposito delle CA radice di fiducia è assolutamente “non fare la cosa giusta”.
Quindi o il tuo responsabile DevOps ha torto, oppure CDCK, LetsEncrypt e Qualys hanno tutti torto.
Digli di aggiornare il deposito delle CA radice. Questo risolverà il problema. Credimi.
Ciao @bpaterson2000, mi dispiace sentire che stai riscontrando problemi di connessione al nostro servizio ospitato. Come ha menzionato @RGJ, il problema non è da parte di Discourse: deve essere risolto sul lato del tuo client. (I nostri server non ‘forniscono’ il certificato root; questi sono gestiti dal tuo client)
Puoi trovare maggiori dettagli su questa modifica da Let’s Encrypt qui:
Grazie per le informazioni, si è trattato di un problema inaspettato per noi, poiché gli errori sembravano provenire dal server ospitato.
Utilizziamo Heroku, che include le funzionalità di cui parli tramite node/packages; a quanto pare, l’aggiornamento di Node è stato la chiave per ristabilire con successo la connessione all’API REST di Discourse.
