Risolvi un errore del certificato di sincronizzazione di ownCloud Desktop correggendo il certificato TLS presentato dal server o installando l'autorità di certificazione privata attendibile che lo ha emesso. Innanzitutto, verifica che il certificato sia valido per l'hostname esatto del server e che includa la sua catena intermedia; non disabilitare i controlli dei certificati né ignorare avvisi non chiari.
Prima di apportare qualsiasi modifica, verifica la versione del client. A ottobre 2026, le note di rilascio di ownCloud elencano le versioni 7.1.0 e 6.0.3 dell'app Desktop: la serie 7.x supporta solo Infinite Scale, mentre ownCloud Server Classic 10 o 11 richiede la serie 6.x. Le stesse note spiegano anche che un captive portal può causare un'incongruenza del certificato e sospendere la sincronizzazione. Consulta le note di rilascio dell'app Desktop di ownCloud .
Confronta l'URL del server mostrato nell'app desktop ownCloud con l'indirizzo funzionante nel tuo browser. Utilizza lo stesso nome host e lo stesso percorso. A volte un browser può recuperare automaticamente un certificato intermedio mancante, mentre un client desktop non può.
Esamina i dettagli del certificato e verifica che il suo Subject Alternative Name (SAN), ovvero i nomi host che copre, includa il nome host che hai inserito. Un certificato files.internal.localnon è valido cloud.example.comsolo perché entrambi i nomi raggiungono lo stesso server. Controlla le date di validità e l'emittente, e verifica l'orologio del computer; una data locale errata può far apparire scaduto o non ancora valido un certificato valido.
Se anche il browser segnala un errore o se si verificano problemi su più dispositivi, la soluzione più probabile risiede nel server o nel proxy inverso. Se si verifica un problema su un solo computer, verificare l'archivio attendibile, l'orologio, il proxy e la versione del client. La guida alla risoluzione dei problemi dell'app desktop di ownCloud consiglia di verificare l'accesso tramite browser e di controllare l'URL del server o il proxy quando i client desktop non riescono a connettersi.
Chiedi all'amministratore del server di installare un certificato il cui SAN includa il nome host pubblico inserito dagli utenti, le cui date siano aggiornate e la cui chiave privata corrisponda al certificato. Un certificato può crittografare una connessione e comunque non consentire la verifica dell'identità se il nome host è errato o se non è possibile verificarne l'emittente.
L'endpoint HTTPS deve presentare il certificato del server e i certificati CA intermedi richiesti in ordine. Normalmente non dovrebbe inviare il certificato CA radice; i client devono già fidarsi di tale certificato. Verifica il reverse proxy o il load balancer che termina la connessione HTTPS, non solo l'host ownCloud. Il proxy potrebbe continuare a servire una catena di certificati obsoleta o incompleta anche dopo l'aggiornamento dei file di backend.
Per una rapida diagnostica da una macchina con OpenSSL, eseguire questo comando dopo aver sostituito il nome host di esempio:
openssl s_client -connect cloud.example.com:443 -servername cloud.example.com -showcerts -verify_return_error </dev/null-servernameInvia il nome host per Server Name Indication quando un server ospita più siti TLS. Esamina la catena e il risultato della verifica: un errore dell'emittente suggerisce la mancanza di un'autorità di certificazione intermedia o non attendibile; un errore nel nome host o nella data richiede la correzione del certificato o dell'URL. Questo verifica solo l'endpoint raggiungibile da quella macchina e da quel percorso di rete. Consulta la documentazione di riferimento di OpenSSLs_client .
Se la tua organizzazione utilizza un'autorità di certificazione (CA) privata, ottieni il suo certificato radice tramite un canale autenticato e verifica la sua impronta digitale con l'amministratore. Installa tale certificato CA, e non la chiave privata del server, nell'archivio attendibile del sistema operativo, quindi riavvia il client ownCloud. Su Debian o Ubuntu, un amministratore può posizionare un certificato CA codificato in formato PEM con estensione .pm nella .crtdirectory /usr/local/share/ca-certificates/e avviare il comando sudo update-ca-certificates. Altre piattaforme utilizzano strumenti di archivio attendibile diversi.
Il comportamento di TLS può variare a seconda della build del client e della piattaforma. Qt documenta che la sua configurazione TLS predefinita utilizza l'elenco delle CA di sistema, ma non tutti i pacchetti sono necessariamente configurati allo stesso modo. Se l'aggiunta della CA non risolve il problema, chiedere all'amministratore di controllare il pacchetto client e i log; non importare mai un certificato da un browser non verificato (avviso). Consultare la documentazione di Qt sulla configurazione dei certificati CA. Le FAQ di ownCloud sui certificati SSL autofirmati rimandano gli amministratori alle linee guida sulla sicurezza; non raccomandano di indebolire la normale verifica del client.
Un certificato server autofirmato non è la stessa cosa di un certificato emesso da un'autorità di certificazione privata attendibile. Se si utilizza un'autorità di certificazione privata, è necessario distribuire e considerare attendibile la radice dell'autorità di certificazione tramite un canale controllato, quindi fornire un certificato server corrispondente al nome host e firmato da tale autorità di certificazione. Evitare di accettare una richiesta di modifica del certificato come soluzione temporanea di routine: ciò potrebbe indurre gli utenti ad approvare un certificato non valido durante un attacco man-in-the-middle.
Se il problema si verifica solo su reti Wi-Fi pubbliche, reti di hotel o reti aziendali recentemente modificate, apri un browser e completa prima la pagina di accesso alla rete. Un portale captive intercetta le richieste prima del login e potrebbe presentare un certificato che non appartiene al nome host di ownCloud. Le note di rilascio di ownCloud affermano esplicitamente che la sincronizzazione può essere sospesa quando un portale captive causa una mancata corrispondenza del certificato e dovrebbe riprendere dopo che il portale è stato svuotato.
Su un dispositivo di lavoro gestito, un proxy di ispezione HTTPS potrebbe sostituire il certificato del server con uno firmato dall'autorità di certificazione (CA) di ispezione dell'organizzazione. Chiedete al reparto IT se questo comportamento è previsto e se la CA approvata è installata sul client desktop. Non ignorate la verifica per far funzionare la sincronizzazione; la configurazione del proxy o della fiducia deve essere corretta dall'amministratore.
Chiudi e riapri il client, verifica che l'account si connetta all'URL HTTPS corretto e attendi che lo stato della sincronizzazione indichi il completamento. Crea un piccolo file di prova nella cartella di sincronizzazione e verifica che venga visualizzato nell'interfaccia web, quindi controlla il registro del client per eventuali messaggi di verifica TLS ricorrenti. Se l'errore del certificato persiste, invia all'amministratore il nome host esatto, la versione del client, il sistema operativo, l'ora dell'errore e lo specifico errore del certificato: non inviare mai password o chiavi private. Se l'interfaccia web di ownCloud funziona ma tutte le app desktop compatibili continuano a non funzionare, fornisci l'URL del server e l'output diagnostico TLS in modo che l'amministratore possa esaminare il proxy o la catena di certificati.
Ripristina la sincronizzazione desktop di ownCloud verificando il nome host del server, la catena di certificati, la fiducia nell'autorità di certificazione privata e i problemi relativi al portale captive, senza disabilitare la verifica TLS.
Utilizza il report sui file non validi per identificare i file di sistema o le firme delle app non corrispondenti, ripristinare i file di rilascio corretti e verificare in modo sicuro l'integrità dei dati.
Distribuisci ownCloud Infinite Scale utilizzando l'esempio ufficiale di Compose, configura i domini e lo storage persistente, quindi verifica TLS, i container ed effettua il primo accesso.
Configura il driver S3NG, le autorizzazioni del bucket, l'archiviazione persistente dei metadati e le dimensioni di caricamento in modo che ownCloud Infinite Scale possa archiviare il contenuto dei file in modo affidabile.
Scopri perché un caricamento su ownCloud Server si interrompe quasi al termine, verificando lo stato del file, la quota, lo spazio su disco temporaneo, i limiti PHP e i timeout del proxy.
Imposta AllowOverride All solo per la directory principale del sito web di ownCloud, verifica il vhost Apache attivo e riavvia il sito in modo sicuro per ripristinare le regole .htaccess.
Abilita l'app Enterprise Auditing di ownCloud, instrada gli eventi admin_audit a un file di registro protetto e verifica che vengano registrate le azioni reali degli utenti.
Allineare l'emittente del realm, il client web e le attestazioni utente di Keycloak consente a ownCloud Infinite Scale di autenticare gli utenti in modo affidabile su client web e mobile.
Trasferisci i file di tua proprietà e le cartelle condivise in uscita con il comando occ di ownCloud, scopri cosa rimane e verifica l'accesso prima di eliminare il vecchio account.
Scopri quando gli indici del database di ownCloud 10 necessitano di attenzione, come applicare in modo sicuro gli aggiornamenti dello schema supportati e quando l'ottimizzazione delle query o una modifica del database rappresentano la soluzione migliore.
