Il client ownCloud Desktop potrebbe interrompere la sincronizzazione e segnalare un errore di verifica del certificato SSL, anche se il server risulta raggiungibile tramite browser. Questo messaggio indica che il client non è riuscito a stabilire che il certificato del server HTTPS sia valido per l'indirizzo del server e considerato attendibile dall'ambiente client. Si tratta di un controllo di identità TLS, non di un errore di password, e l'accettazione ripetuta di un certificato non verificato può esporre le credenziali dell'account e i file a potenziali intercettazioni.
Iniziate verificando l'indirizzo del server, la validità del certificato e la catena di certificati. Corregete questi dati sul server o sul suo proxy inverso, se possibile. Se il server utilizza intenzionalmente un'autorità di certificazione (CA) privata, aggiungete il certificato radice verificato di tale CA all'archivio dei certificati attendibili del computer. Quindi riavviate il client desktop e verificate che la sincronizzazione riprenda senza avvisi relativi al certificato.
ownCloud attualmente offre sia ownCloud Classic Server (versioni 10 e 11) che ownCloud Infinite Scale (oCIS). Non tutte le versioni dell'app desktop sono intercambiabili. Secondo la pagina di download di ownCloud del 1° settembre 2026, l'app desktop 7.1.1 è per Infinite Scale, mentre ownCloud Classic è supportato da un client 6.x; la pagina indica la versione 6.0.3 per Classic. Se un client è stato aggiornato di recente e il backend è ownCloud Server 10 o 11, verificare la compatibilità prima di considerare un errore di connessione come un problema di certificato.
Verificate inoltre l'URL esatto configurato nell'account di sincronizzazione. Il nome host in tale URL deve corrispondere a un nome presente nel certificato del server. Per un server Classic installato in un percorso, l'account potrebbe avere un aspetto simile a questo https://cloud.example.com/owncloud; un'installazione oCIS potrebbe utilizzare un URL di base diverso. Utilizzate l'indirizzo configurato dal vostro amministratore anziché passare continuamente da un nome host a un indirizzo IP o a un dominio alternativo.
Assicurati che la data, l'ora e il fuso orario del computer siano corretti. Un orologio errato può far apparire scaduto o non ancora valido un certificato attualmente valido. Successivamente, apri l'URL di ownCloud esatto dall'account di sincronizzazione in un browser sullo stesso computer. Controlla i dettagli del certificato per verificare il nome host, la data di scadenza e l'emittente. Un browser che carica la pagina senza avvisi è un indizio utile, ma non dimostra che il client desktop utilizzi lo stesso archivio di certificati o che ogni richiesta WebDAV segua lo stesso percorso proxy.
Se l'errore si verifica solo su reti Wi-Fi di hotel, aeroporti, scuole o reti pubbliche, completate la procedura di accesso al portale di quella rete e riprovate. Le note di rilascio dell'app desktop di ownCloud descrivono la sospensione della sincronizzazione quando un portale captive causa una mancata corrispondenza del certificato, per poi riavviarla dopo aver svuotato il portale. Il fatto che una pagina del portale intercetti HTTPS non è un motivo sufficiente per fidarsi del certificato inatteso.
Chiedi all'amministratore del server di verificare il certificato TLS sull'endpoint pubblico, incluso il server web o il proxy inverso che termina HTTPS. Il certificato deve essere valido, includere il nome DNS esatto utilizzato dal client ed essere fornito con i certificati intermedi richiesti. Un errore di implementazione comune è configurare solo il certificato foglia anziché l'intera catena. Se il certificato è stato rinnovato di recente, assicurati che il proxy inverso stia presentando il nuovo certificato e non uno obsoleto.
Su un sistema con OpenSSL, è possibile ispezionare l'handshake TLS e verificare il nome host con questo comando. Sostituire il nome di esempio con il nome host di ownCloud, senza il percorso URL:
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/nullEsamina il risultato della verifica e le date del certificato. Questo test analizza l'endpoint dal computer su cui viene eseguito; non riproduce ogni dettaglio dell'archivio certificati attendibili del client desktop. Se l'output identifica un certificato scaduto, una mancata corrispondenza del nome host, un emittente mancante o un'autorità di certificazione non attendibile, correggi il certificato o la catena di certificati sull'endpoint TLS ed esegui nuovamente il test. Non tentare di risolvere un problema di nome host o di catena di certificati lato server installando un certificato non correlato su ogni computer desktop.
Per un servizio ownCloud accessibile da Internet, la soluzione più semplice consiste solitamente nell'utilizzare un certificato rilasciato da un'autorità di certificazione pubblica riconosciuta dai sistemi operativi più recenti. Configurate l'endpoint HTTPS con il certificato e la catena completa per l'hostname pubblico e verificate che il rinnovo funzioni correttamente. Se il protocollo HTTPS è gestito da un proxy inverso, il certificato deve essere installato su tale proxy; la modifica della sola configurazione dell'applicazione ownCloud non influirà sul certificato ricevuto dai client.
Dopo che l'amministratore ha aggiornato l'endpoint, testare lo stesso nome host dalla stessa rete di un computer interessato. I controlli tramite browser e riga di comando non dovrebbero più segnalare un avviso relativo al certificato e il client ownCloud dovrebbe riconnettersi dopo un nuovo tentativo o un riavvio. Se solo alcuni computer continuano a presentare problemi, confrontare gli aggiornamenti del sistema operativo, gli archivi attendibili, le impostazioni del proxy e le versioni del client.
Spesso le organizzazioni utilizzano un'autorità di certificazione (CA) interna per i servizi privati di ownCloud. In tal caso, è necessario ottenere il certificato radice della CA dell'organizzazione tramite un canale autenticato e verificarne l'impronta digitale con l'amministratore. Installare la CA radice su ciascun computer client interessato utilizzando la procedura di gestione dei certificati del sistema operativo o i criteri di gestione dei dispositivi aziendali. Non aggiungere come radice un certificato scaricato dalla pagina di avviso solo perché il client di sincronizzazione lo propone; verificare prima che appartenga alla CA desiderata.
.crtfile in /usr/local/share/ca-certificates/ed eseguire sudo update-ca-certificates. Questo aggiorna l'archivio di certificati attendibili del sistema per le applicazioni che lo utilizzano. Ubuntu avverte che le applicazioni Snap potrebbero non utilizzare automaticamente i certificati aggiunti all'archivio host, quindi un pacchetto con restrizioni potrebbe richiedere una soluzione di attendibilità specifica per il pacchetto.Dopo aver aggiornato le impostazioni di attendibilità, riavvia il client ownCloud Desktop. Il pacchetto client e il sistema operativo possono influenzare l'archivio certificati utilizzato. Se è installata un'autorità di certificazione (CA) e il browser considera attendibile il sito, ma l'applicazione desktop continua a non funzionare, verifica il comportamento e i log relativi alle impostazioni di attendibilità del pacchetto client anziché importare più copie del certificato del server in modo casuale.
ownCloud Server dispone di un occ security:certificatescomando per i certificati di cui il server stesso deve fidarsi, come ad esempio i certificati utilizzati per la federazione o l'archiviazione esterna. Si tratta di un archivio di certificati attendibili lato server. Non corregge la decisione di attendibilità presa dal client di sincronizzazione desktop di un utente durante la connessione al sito Web di ownCloud. In caso di errore di verifica del desktop, correggere l'endpoint HTTPS o la configurazione di attendibilità del computer interessato.
Evitate di disabilitare la convalida del certificato come soluzione temporanea permanente. Il client a riga di comando di ownCloud documenta un'opzione --trust, ma sopprimere o accettare un errore di verifica non risolve un problema di certificato scaduto, nome host errato, catena di CA mancante o connessione non attendibile. Utilizzate tali controlli di attendibilità solo nell'ambito di un piano di test deliberato e verificato, non come sostituto di una corretta configurazione TLS su un account di sincronizzazione di produzione.
Se il sito web si apre ma la sincronizzazione non riesce ancora a connettersi dopo che i controlli TLS hanno esito positivo, passare alla configurazione di WebDAV e del server. L'app desktop ownCloud utilizza WebDAV per ownCloud Classic; la guida alla risoluzione dei problemi del fornitore consiglia di verificare che l'endpoint WebDAV sia raggiungibile quando tutti i client non riescono ad accedere ma l'accesso tramite browser funziona. Se l'errore del certificato è scomparso ma l'accesso o la sincronizzazione continuano a non funzionare, esaminare l'errore di autenticazione, di reverse proxy o WebDAV separato visualizzato nel log.
Il certificato presentato per il nome host configurato è valido, contiene tale nome host e la catena di certificati punta a un'autorità di certificazione (CA) considerata attendibile dal computer client. Il client desktop si riconnette senza richiedere il certificato e un file di test viene sincronizzato in entrambe le direzioni. Se la catena di certificati pubblici è corretta ma solo un singolo client gestito continua a non funzionare, concentrarsi sull'orologio, sull'archivio certificati attendibili, sul proxy di rete, sul portale captive e sulla versione del client compatibile di tale computer.
Questi controlli riguardano gli errori di verifica dei certificati. Non possono correggere problemi non correlati relativi all'account, a WebDAV, al firewall o alla disponibilità del server, e i menu esatti variano a seconda del sistema operativo e della versione dell'app ownCloud Desktop. Utilizzare i log del client e la configurazione dell'endpoint TLS del server per identificare quale delle due parti continua a non essere d'accordo.
Scopri cosa fa Microsoft IIS, come funzionano la sua pipeline di richieste e i pool di applicazioni e quando Apache, NGINX o Caddy potrebbero essere più adatti alle tue esigenze di server web.
Diagnostica i picchi di utilizzo della CPU del browser Jitsi Meet e riduci il carico del client controllando i riquadri video, gli effetti della fotocamera, la grafica del browser e le impostazioni dell'host.
Monitora lo stato di salute, il carico della conferenza e il traffico di Jitsi Videobridge con il suo endpoint Prometheus integrato, quindi esplora e visualizza i dati in Grafana.
Configura un dominio personalizzato per Jitsi Meet Docker con DNS, URL pubblico, HTTPS, Let's Encrypt, porte del firewall, impostazioni NAT e verifica end-to-end.
Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.
Scopri come diagnosticare e risolvere l'avviso di configurazione di PHP OPcache di Nextcloud controllando l'SAPI PHP attivo, i limiti di dimensionamento, i commenti e le impostazioni di riconvalida.
Risolvere i problemi di migrazione del database Kopano dopo un aggiornamento di MySQL o MariaDB verificando i backup, le versioni del server, le modalità SQL, il set di caratteri, lo stato dello schema e i log.
Collega Nextcloud a LDAP o Active Directory con trasporto sicuro, filtri per utenti e gruppi, attributi di accesso e un'implementazione collaudata.
Risolvi i problemi di notifiche di Element Android sui telefoni senza Google configurando UnifiedPush, le autorizzazioni Android, le impostazioni della batteria ed eseguendo test di verifica affidabili.
Risolvi l'avviso di Nextcloud relativo agli indici del database mancanti utilizzando il comando ufficiale occ. Prima di procedere, esegui un backup, visualizza in anteprima le modifiche, avvia la riparazione e verifica il risultato.
