Pour résoudre une erreur de certificat de synchronisation ownCloud Desktop, corrigez le certificat TLS présenté par le serveur ou installez l'autorité de certification privée de confiance qui l'a émis. Vérifiez d'abord que le certificat est valide pour le nom d'hôte exact du serveur et qu'il inclut sa chaîne intermédiaire ; ne désactivez pas les vérifications de certificat et ne cliquez pas sur un avertissement non expliqué.
Vérifiez la version du client avant toute modification. En octobre 2026, les notes de version d'ownCloud mentionnent les applications de bureau 7.1.0 et 6.0.3 : la série 7.x prend uniquement en charge Infinite Scale, tandis qu'ownCloud Server Classic 10 ou 11 requiert la série 6.x. Ces mêmes notes expliquent également qu'un portail captif peut entraîner une incompatibilité de certificat et interrompre la synchronisation. Consultez les notes de version de l'application de bureau ownCloud .
Comparez l'URL du serveur affichée dans l'application ownCloud Desktop avec l'adresse qui fonctionne dans votre navigateur. Utilisez le même nom d'hôte et le même chemin. Un navigateur peut parfois récupérer automatiquement un certificat intermédiaire manquant, contrairement à un client de bureau.
Examinez les détails du certificat et vérifiez que son nom alternatif de sujet (SAN) – les noms d'hôtes qu'il couvre – inclut bien le nom d'hôte que vous avez saisi. Un certificat files.internal.localne couvre pas un serveur cloud.example.comsimplement parce que les deux noms pointent vers le même serveur. Vérifiez les dates de validité et l'émetteur, ainsi que l'heure de votre ordinateur ; une date locale incorrecte peut faire apparaître un certificat valide comme expiré ou non valide.
Si le navigateur signale également une erreur ou si plusieurs appareils rencontrent le même problème, la réparation provient probablement du serveur ou du proxy inverse. Si un seul ordinateur est concerné, vérifiez son magasin de certificats de confiance, son horloge, son proxy et la version du client. Le guide de dépannage de l'application de bureau ownCloud recommande de vérifier l'accès au navigateur et l'URL du serveur ou du proxy lorsque les clients de bureau ne parviennent pas à se connecter.
Demandez à l'administrateur du serveur d'installer un certificat dont le SAN inclut le nom d'hôte public saisi par les utilisateurs, dont la validité est actuelle et dont la clé privée correspond à celle du certificat. Un certificat peut chiffrer une connexion et néanmoins échouer à la vérification d'identité si son nom d'hôte est incorrect ou si son émetteur ne peut être vérifié.
Le point de terminaison HTTPS doit présenter le certificat du serveur et les certificats d'autorité de certification intermédiaires requis, dans l'ordre. Il ne doit généralement pas transmettre le certificat de l'autorité de certification racine ; les clients doivent déjà faire confiance à cette autorité. Vérifiez le proxy inverse ou l'équilibreur de charge qui termine le trafic HTTPS, et pas seulement l'hôte ownCloud. Le proxy peut encore diffuser une chaîne de certificats ancienne ou incomplète après la mise à jour des fichiers backend.
Pour un diagnostic rapide depuis une machine avec OpenSSL, exécutez cette commande après avoir remplacé le nom d'hôte d'exemple :
openssl s_client -connect cloud.example.com:443 -servername cloud.example.com -showcerts -verify_return_error </dev/null-servernameEnvoie le nom d'hôte pour l'indication du nom du serveur (SNDI) lorsqu'un serveur héberge plusieurs sites TLS. Examinez la chaîne et le résultat de la vérification : une défaillance de l'émetteur suggère un certificat intermédiaire manquant ou une autorité de certification non approuvée ; une erreur de nom d'hôte ou de date nécessite la correction du certificat ou de l'URL. Cette vérification ne porte que sur le point de terminaison accessible depuis cette machine et ce chemin réseau. Consultez la documentation OpenSSLs_client .
Si votre organisation utilise une autorité de certification (AC) privée, obtenez son certificat racine via un canal authentifié et vérifiez son empreinte numérique auprès de l'administrateur. Installez ce certificat d'AC (et non la clé privée du serveur) dans le magasin de certificats de confiance du système d'exploitation, puis redémarrez le client ownCloud. Sous Debian ou Ubuntu, un administrateur peut placer un certificat d'AC au format PEM se terminant par `.pm` .crtet /usr/local/share/ca-certificates/exécuter la commande sudo update-ca-certificatescorrespondante. Les autres plateformes utilisent des outils de gestion de certificats de confiance différents.
Le comportement TLS peut varier selon la version du client et la plateforme. Qt indique que sa configuration TLS par défaut utilise la liste des autorités de certification système, mais tous les paquets ne sont pas nécessairement configurés de la même manière. Si l'ajout de l'autorité de certification ne résout pas le problème, demandez à l'administrateur de vérifier le paquet client et les journaux ; n'importez jamais un certificat provenant d'un navigateur non vérifié. Consultez la documentation de Qt sur la configuration des certificats d'autorité de certification . La FAQ du serveur ownCloud relative aux certificats SSL auto-signés renvoie les administrateurs à ses recommandations de sécurité ; elle déconseille d'affaiblir la vérification standard du client.
Un certificat serveur auto-signé est différent d'un certificat émis par une autorité de certification privée de confiance. Si vous utilisez une autorité de certification privée, diffusez et approuvez son autorité racine via un canal contrôlé, puis servez un certificat serveur correspondant au nom d'hôte et signé par cette autorité. Évitez d'accepter systématiquement une demande de changement de certificat : cela pourrait inciter les utilisateurs à approuver un imposteur lors d'une attaque de type « homme du milieu ».
Si le problème survient uniquement sur les réseaux Wi-Fi publics, les réseaux d'hôtel ou un réseau d'entreprise récemment modifié, ouvrez un navigateur et connectez-vous au réseau. Un portail captif intercepte les requêtes avant la connexion et peut présenter un certificat qui n'appartient pas au nom d'hôte ownCloud. Les notes de version d'ownCloud indiquent clairement que la synchronisation peut être interrompue lorsqu'un portail captif provoque une incompatibilité de certificat et qu'elle doit reprendre une fois le portail désactivé.
Sur un poste de travail géré, un proxy d'inspection HTTPS peut remplacer le certificat du serveur par un certificat signé par l'autorité de certification d'inspection de l'organisation. Renseignez-vous auprès du service informatique pour savoir si ce comportement est normal et si l'autorité de certification approuvée est installée sur le poste client. Ne contournez pas la vérification pour permettre la synchronisation ; la configuration du proxy ou des certificats de confiance doit être corrigée par l'administrateur.
Quittez puis rouvrez le client, vérifiez que le compte se connecte bien à l'URL HTTPS exacte et attendez que la synchronisation soit terminée. Créez un petit fichier de test dans le dossier de synchronisation et assurez-vous qu'il apparaît bien dans l'interface web. Consultez ensuite le journal du client pour détecter tout message de vérification TLS récurrent. Si l'erreur de certificat persiste, envoyez à l'administrateur le nom d'hôte exact, la version du client, le système d'exploitation, l'heure de l'erreur et le code d'erreur spécifique du certificat ; ne communiquez jamais vos mots de passe ni vos clés privées. Si l'interface web d'ownCloud fonctionne mais que toutes les applications de bureau compatibles échouent, fournissez l'URL du serveur et le résultat du diagnostic TLS afin que l'administrateur puisse examiner le proxy ou la chaîne de certificats.
Rétablissez la synchronisation de votre ordinateur ownCloud en vérifiant le nom d'hôte du serveur, la chaîne de certificats, la confiance de l'autorité de certification privée et les problèmes liés au portail captif sans désactiver la vérification TLS.
Utilisez le rapport de fichiers invalides pour identifier les fichiers principaux ou les signatures d'application non concordants, restaurer les fichiers de version corrects et vérifier l'intégrité en toute sécurité.
Déployez ownCloud Infinite Scale à partir de son exemple Compose officiel, configurez les domaines et le stockage persistant, puis vérifiez TLS, les conteneurs et la première connexion.
Configurez le pilote S3NG, les autorisations du compartiment, le stockage persistant des métadonnées et la taille des chargements afin qu'ownCloud Infinite Scale puisse stocker le contenu des fichiers de manière fiable.
Découvrez pourquoi un chargement sur un serveur ownCloud s'interrompt presque complètement en vérifiant l'état du fichier, le quota, l'espace disque temporaire, les limites PHP et les délais d'expiration du proxy.
Configurez AllowOverride All uniquement pour la racine web d'ownCloud, validez l'hôte virtuel Apache actif et rechargez en toute sécurité pour restaurer les règles .htaccess.
Activez l'application d'audit d'entreprise d'ownCloud, acheminez les événements admin_audit vers un fichier journal protégé et vérifiez que les actions réelles des utilisateurs sont bien enregistrées.
Alignez l'émetteur de domaine Keycloak, le client web et les revendications des utilisateurs pour permettre à ownCloud Infinite Scale de connecter les utilisateurs de manière fiable sur les clients web et mobiles.
Transférez les fichiers dont vous êtes propriétaire et les partages sortants avec la commande occ d'ownCloud, comprenez ce qui reste et vérifiez l'accès avant de supprimer l'ancien compte.
Découvrez quand les index de la base de données ownCloud 10 nécessitent une attention particulière, comment appliquer en toute sécurité les mises à jour de schéma prises en charge et quand l'optimisation des requêtes ou une modification de la base de données constitue la meilleure solution.
