Reeve Basi della sicurezza
Certificato non attendibile: tre cause oltre alla scadenza
Certificato non attendibile anche se la data è giusta? Nomina un altro indirizzo, si è firmato da solo o alla sua catena manca un anello. Come capirlo.
In breve
- Un certificato non attendibile per i browser può essere perfettamente in data. Viene rifiutato perché nomina un altro indirizzo, perché si è firmato da solo, o perché è arrivato senza il certificato che garantisce per lui.
- La schermata di avviso è la stessa di un certificato scaduto, e rinnovarlo non risolve nessuna delle tre cause. Il codice mostrato sotto l’avviso ti dice quale hai.
- Su Lovable e Vercel, un dominio personalizzato mostra questo avviso finché il suo certificato non viene emesso. Quell’attesa è normale. Un avviso che dura di più significa che qualcosa sta bloccando il certificato.
Ieri la tua app si caricava senza problemi. Oggi qualcuno ti manda lo screenshot di un avviso del browser a tutta pagina, che dice che la connessione non è privata, e ti chiede se il sito è stato violato. Apri il certificato ed è valido fino alla prossima primavera. Non è scaduto, eppure il browser dice che il certificato non è attendibile.
La mossa ovvia è rinnovarlo, e per questa schermata è quella sbagliata. Ognuna delle tre cause qui sotto colpisce un certificato già in data, quindi un rinnovo ti dà una scadenza più lontana su un certificato che continua a essere rifiutato per un altro motivo.
Nel nostro articolo sulla scadenza, il certificato è la licenza in vetrina che dice che questo negozio è davvero quello dell’insegna. Il browser di un visitatore legge tre cose su quella licenza prima di far entrare chiunque: la data, il nome del negozio per cui è stata emessa e la firma di chi l’ha emessa. La scadenza è la data. Questo articolo parla delle altre due.
Certificato non attendibile anche se non è scaduto: perché?
Perché è fallito il nome o la firma, e il browser alza lo stesso muro per ognuno dei suoi controlli.
Un certificato è attendibile solo se nomina esattamente l’indirizzo nella barra del visitatore ed è stato firmato da un’autorità di cui il browser si fida già, con ogni certificato intermedio inviato insieme a lui. Se fallisce uno dei due, Chrome mostra l’avviso che la connessione non è privata e Firefox quello di un potenziale rischio per la sicurezza, esattamente come per uno scaduto.
Quello che cambia è il testo piccolo sotto l’avviso. Leggilo prima di toccare qualsiasi cosa:
| Cosa mostra Chrome | Cosa dice la spiegazione di Firefox | Cosa significa | Cosa lo risolve |
|---|---|---|---|
NET::ERR_CERT_COMMON_NAME_INVALID | Il certificato non è valido per il tuo indirizzo | È stato emesso per un altro nome | Un certificato che elenchi esattamente il tuo indirizzo |
NET::ERR_CERT_AUTHORITY_INVALID | Il certificato non è attendibile perché è autofirmato | Nessuno garantisce per lui tranne il server stesso | Un certificato di una vera autorità |
NET::ERR_CERT_AUTHORITY_INVALID | L’emittente del certificato è sconosciuto | Il browser non riesce a collegarlo a un’autorità di cui si fida | La catena completa, da un’autorità riconosciuta |
NET::ERR_CERT_DATE_INVALID | Il certificato è scaduto | La data | Un certificato nuovo |
Chrome mostra lo stesso codice per la seconda e la terza riga, ed è per questo che vale la pena aprire il certificato stesso.
Se una sola persona segnala l’avviso e nessun altro lo vede, chiedile su quale rete fosse. Il codice sorgente di Chrome cita una rete wifi che manda i suoi utenti a una pagina di accesso come una delle cause dell’errore di nome. Quello si risolve appena accede alla rete.
Come vedo cosa dice il certificato?
Aprilo dall’avviso e leggi due campi: a chi è stato emesso e chi l’ha emesso.
In Chrome, fai clic sull’indicazione di avviso a sinistra della barra degli indirizzi (Not secure in un Chrome in inglese) e apri il certificato dal pannello che compare. In Firefox, fai clic su Advanced nell’avviso e poi sul link al certificato del sito (si chiamano così in un Firefox in inglese). I due browser chiamano gli stessi campi in modo diverso:
- Il campo che dice a chi è stato emesso il certificato (Issued To in un Chrome in inglese, Subject Name in Firefox) dà il nome per cui è stato fatto. L’elenco completo dei nomi che copre si trova sotto Subject Alternative Name, ed è quell’elenco che il browser confronta con l’indirizzo.
- Il campo che dice chi l’ha emesso (Issued By in Chrome, Issuer Name in Firefox) dà l’autorità che l’ha firmato.
Ognuna delle tre cause si legge in modo diverso lì:
- Il certificato nomina un altro indirizzo. È la causa 1.
- Titolare ed emittente hanno lo stesso nome. Si è firmato da solo: è la causa 2.
- Nomina il tuo indirizzo, l’emittente è un’autorità di cui hai sentito parlare, e il browser lo rifiuta lo stesso. È la causa 3, la catena.
Causa 1: il certificato è per un altro indirizzo
Il certificato è autentico e in data, ed è stato emesso per un altro nome. È la licenza di un altro negozio, appesa nella tua vetrina.
Si presenta in tre forme:
- Il tuo dominio punta a un hosting che non ha ancora un certificato per lui. L’hosting risponde con il certificato che ha, emesso a un nome suo. La documentazione di Lovable lo dice chiaramente: finché il certificato non è pronto, il browser mostra un avviso di sicurezza al posto del tuo sito.
- Il certificato copre una grafia del tuo indirizzo e il visitatore ha
digitato l’altra.
www.yourapp.comeyourapp.comsono due nomi per un certificato, e ciascuno deve essere nel suo elenco. - Una parte del tuo DNS punta ancora a un posto che hai lasciato. Un vecchio hosting, o la pagina di parcheggio che il tuo registrar mostrava prima che collegassi qualcosa, risponde su quel nome con un certificato suo.
Su Lovable e Vercel non compri né installi questo certificato tu. L’hosting ne emette uno per ogni nome che aggiungi nelle sue impostazioni del dominio, una volta che il tuo DNS fa puntare quel nome verso di lui. La documentazione di Lovable aggiunge che il suo hosting non usa affatto un certificato comprato dal tuo registrar. Aggiungi entrambe le grafie, fai puntare entrambe all’hosting e aspetta che ciascuna risulti attiva.
Causa 2: il certificato si è firmato da solo
Nessuno garantisce per questo certificato tranne il server che lo presenta. È una licenza che il negoziante ha stampato a casa.
Ogni browser ne rifiuta uno su un sito pubblico, ed è giusto così. Un commento nel codice sorgente di Chrome dà il motivo in una riga: un certificato autofirmato non offre alcuna difesa contro un attaccante che si mette tra il tuo visitatore e la tua app.
Lo incontri su server che qualcuno ha configurato a mano: un server in affitto, uno strumento self-hosted, un’impostazione di prova finita in produzione con l’app. Un builder emette certificati veri per i domini che gli aggiungi. Un certificato autofirmato su un’app ospitata da un builder significa quindi che qualcosa di diverso dal builder sta rispondendo sul tuo indirizzo. Controlla dove punta il tuo DNS prima di cambiare qualsiasi altra cosa.
La soluzione è un certificato di una vera autorità. Let's Encrypt li emette gratis, ed è l’autorità che Vercel usa quando emette il tuo.
Causa 3: un anello della catena non è mai stato inviato
Il certificato è per il tuo indirizzo ed è stato firmato da una vera autorità, ma il server l’ha inviato senza il certificato intermedio, quindi il browser non riesce a collegarlo a nessuno di cui si fidi. La licenza l’ha firmata una filiale, e nella vetrina manca la lettera della sede centrale che garantisce per quella filiale.
Mozilla definisce un certificato intermedio mancante uno dei problemi di configurazione dei server più comuni. Firefox ora scarica in anticipo una copia di ogni certificato intermedio attendibile, perché i suoi utenti smettano di incontrare l’errore.
È questo che rende difficile vedere questa causa: sul tuo portatile può sembrare tutto a posto mentre a qualcun altro fallisce. Un browser che ha una sua copia dell’anello mancante riempie il buco. Un software che usa solo quello che invia il tuo server non ha niente con cui riempirlo. Il nostro scanner è un software di questo tipo, ed è per questo che può segnalare un certificato come non attendibile mentre il tuo browser mostra un lucchetto.
Su un builder la catena è gestita per te. Manca sui server configurati a mano, e
lì la soluzione è servire il certificato seguito dal certificato intermedio, in
un solo file. Se usi certbot di Let's Encrypt, quel file è fullchain.pem, e
l’errore è far puntare il server a cert.pem al suo posto. Per controllare
dall’esterno, il test gratuito dei server di SSL Labs
segnala un certificato intermedio mancante come un problema della catena.
Il caso del dominio personalizzato, in ordine
Quando colleghi il tuo dominio a un builder, i visitatori vedono questo avviso finché l’hosting non ha un certificato per il tuo nome, e l’avviso dice il vero. Finisce da solo appena il certificato viene emesso.
L’ordine, su Lovable:
- Aggiungi il dominio in Lovable. Configura
yourapp.comewww.yourapp.come li elenca separatamente. - Cambia i record DNS presso il tuo registrar con i valori che ti dà Lovable. Secondo Lovable, la maggior parte delle modifiche è attiva in poche ore, e la propagazione può richiedere fino a 72 ore.
- Lovable verifica il dominio ed emette il certificato. Vercel funziona allo stesso modo: dimostra a Let's Encrypt che il nome è tuo, in automatico, purché il dominio punti a Vercel.
- Apri il sito quando il dominio risulta Live, come consiglia Lovable stessa.
Se l’avviso c’è ancora dopo 72 ore, Lovable ti chiede di contattare il suo supporto. Due impostazioni vale la pena controllarle prima di scrivere:
- Cerca un record CAA. È una voce DNS che indica quali autorità possono emettere certificati per il tuo dominio. Una che esclude l’autorità del tuo hosting blocca il certificato, e un sottodominio eredita i record CAA del dominio padre quando non ne ha di suoi. L’articolo sulla scadenza incontra lo stesso record come motivo per cui un rinnovo fallisce. Qui impedisce che il primo certificato venga mai emesso.
- Cerca un proxy davanti. Se il tuo DNS è su Cloudflare con la nuvola arancione attiva sui record che ti ha dato l’hosting, risponde Cloudflare al posto del tuo hosting. Lovable dice che allora non può verificare il dominio né emettere certificati per lui, e sia Lovable sia Vercel dicono di impostare quei record su DNS only.
Cosa abbiamo trovato su 30.879 app
Otto avevano un certificato di cui nessun browser si sarebbe fidato, e ognuna era su un dominio che il proprietario aveva collegato.
Ad agosto 2026 la nostra scansione ha letto il certificato di 30.879 app online: 29.927 sul sottodominio di un builder e 952 su un dominio proprio. Tutti e otto i certificati non attendibili erano tra le 952, poco meno di uno su cento. Nessuna delle app sul sottodominio di un builder ne aveva uno, il che torna con tutto quanto sopra. Sull’indirizzo del builder, nome e certificato sono del builder.
Il nostro rilievo registra che il certificato è fallito, ma non quale delle tre cause fosse, quindi non possiamo dirti come si dividono gli otto. I certificati scaduti o in scadenza della stessa scansione sono contati nell’articolo sulla scadenza.
Per controllare la tua app, la nostra scansione gratuita legge dall’esterno il certificato che invia il tuo server e nomina questo rilievo quando lo vede. Ci mette circa 20 secondi e non serve un account.
Accorgertene la prossima volta che cambia qualcosa
Un certificato passa da attendibile a rifiutato quando cambia qualcosa intorno a lui: un dominio nuovo, un trasloco del DNS, un proxy attivato. Il controllo che conta è quello che gira dopo il cambiamento.
Scansiona la tua app gratis per vedere cosa riceve oggi il browser di un visitatore.
- Legge dall’esterno il certificato che invia il tuo server, insieme ad altri otto controlli.
- Nomina il rilievo quando il certificato non è attendibile, e quando è scaduto o sta per scadere.
- Circa 20 secondi, e nessun account.
Reeve Monitor per saperlo poco dopo il cambiamento.
- Controlla la tua app ogni 60 secondi, e un certificato di cui non può fidarsi conta come un’interruzione della tua app. Vieni avvisato quindi come per qualsiasi altra interruzione.
- Ripete tutti e nove i controlli ogni ora e ti manda un’email quando il tuo voto scende.
- Copre fino a tre app.
Cosa fare adesso
Cosa fare
- Leggi il codice sotto l’avviso prima di rinnovare qualsiasi cosa. Un errore di data richiede un certificato nuovo. Un errore di nome o di autorità richiede altro.
- Apri il certificato e confronta il nome per cui è stato emesso con l’indirizzo nella barra, e con il nome di chi l’ha emesso.
- Su un builder, aggiungi
yourapp.comewww.yourapp.comnelle impostazioni del dominio e fai puntare entrambi verso di lui. - Se un dominio nuovo mostra ancora l’avviso dopo 72 ore, cerca un record CAA o un proxy davanti all’hosting prima di contattare il supporto.
- Su un server che gestisci tu, servi la catena completa e controllala dall’esterno con SSL Labs.
Quando l’avviso è sparito e l’app continua a non caricarsi, la domanda successiva è se il problema sia la tua app o la piattaforma sotto, e Supabase è giù o è la tua app? spiega come distinguerlo.
FAQ
Perché il mio sito dice che la connessione non è privata se il certificato non è scaduto?
Perché la data è solo una delle tre cose che un browser controlla, e le altre due falliscono per conto loro. Il certificato deve anche nominare esattamente l’indirizzo digitato dal visitatore, ed essere firmato da un’autorità di cui il browser si fida, con ogni certificato intermedio inviato insieme a lui. Un certificato che fallisce uno dei due controlli riceve lo stesso avviso a tutta pagina di uno scaduto, e rinnovarlo non cambia nulla.
Che cos’è un errore di nome del certificato?
Un certificato emesso per un indirizzo e presentato su un altro. Chrome lo segnala come NET::ERR_CERT_COMMON_NAME_INVALID e Firefox dice che il certificato non è valido per il tuo indirizzo. Il certificato in sé di solito è autentico e in data. Appartiene semplicemente a un altro nome, spesso quello del tuo hosting, ed è quello che un hosting presenta sul tuo dominio prima di averne emesso uno per te.
Perché con www funziona e il dominio senza www no?
Perché per un certificato sono due nomi diversi. O il certificato ne elenca solo uno, o il DNS dell’altro punta ancora altrove, per esempio alla pagina di parcheggio del tuo registrar o a un vecchio hosting, che risponde con un certificato suo. Lovable collega entrambi e li elenca separatamente, quindi controlla che ciascuno risulti attivo.
Quanto ci mette il certificato di un dominio personalizzato?
Secondo Lovable, la configurazione di un dominio di solito si completa in pochi minuti ma può richiedere diverse ore, le modifiche DNS possono impiegare fino a 72 ore per propagarsi, e va contattato il suo supporto se il certificato non è stato emesso dopo 72 ore. Finché non viene emesso, i visitatori vedono un avviso di sicurezza al posto del tuo sito.
Un certificato autofirmato va mai bene?
Sul tuo computer, per sviluppare, sì. Su un sito che il pubblico visita, no. Il browser di ogni visitatore lo rifiuta, e un commento nel codice sorgente di Chrome nota che un certificato autofirmato non offre alcuna difesa contro un attaccante che si mette tra il visitatore e il sito.