Le client ownCloud Desktop peut cesser la synchronisation et signaler un échec de vérification du certificat SSL, même si le serveur semble accessible via un navigateur. Ce message signifie que le client n'a pas pu établir la validité du certificat HTTPS du serveur pour l'adresse du serveur et sa fiabilité par l'environnement client. Il s'agit d'une vérification d'identité TLS, et non d'une erreur de mot de passe. Accepter de manière répétée un certificat non vérifié peut exposer les identifiants de compte et les fichiers à une interception.
Commencez par vérifier l'adresse du serveur, la validité du certificat et la chaîne de certificats. Corrigez ces éléments sur le serveur ou son proxy inverse si possible. Si le serveur utilise intentionnellement une autorité de certification (AC) privée, ajoutez le certificat racine vérifié de cette AC au magasin de certificats de confiance de votre ordinateur. Redémarrez ensuite le client de bureau et vérifiez que la synchronisation reprend sans avertissement de certificat.
ownCloud propose actuellement ownCloud Classic Server (versions 10 et 11) et ownCloud Infinite Scale (oCIS). Les versions de l'application de bureau ne sont pas interchangeables entre les deux. Au 1er septembre 2026, la page de téléchargement d'ownCloud indiquait que l'application de bureau 7.1.1 était destinée à Infinite Scale, tandis qu'ownCloud Classic était compatible avec un client 6.x (la page mentionnait la version 6.0.3 pour Classic). Si un client a été récemment mis à jour et que le serveur est ownCloud Server 10 ou 11, vérifiez la compatibilité avant d'attribuer un échec de connexion à un problème de certificat.
Vérifiez également l'URL exacte configurée dans le compte de synchronisation. Le nom d'hôte de cette URL doit correspondre à un nom figurant dans le certificat du serveur. Pour un serveur Classic installé sous un chemin spécifique, le compte peut ressembler à cecihttps://cloud.example.com/owncloud ; une installation oCIS peut utiliser une URL de base différente. Utilisez l'adresse configurée par votre administrateur plutôt que d'alterner entre un nom d'hôte, une adresse IP et un domaine alternatif.
Vérifiez que la date, l'heure et le fuseau horaire de votre ordinateur sont corrects. Une horloge mal réglée peut faire apparaître un certificat valide comme expiré ou non valide. Ensuite, ouvrez l'URL exacte d'ownCloud depuis le compte de synchronisation dans un navigateur sur le même ordinateur. Examinez les détails du certificat : nom d'hôte, date d'expiration et émetteur. Si votre navigateur charge la page sans avertissement, cela peut être utile, mais ne prouve pas que le client de bureau utilise le même magasin de certificats ni que chaque requête WebDAV emprunte le même chemin proxy.
Si l'erreur se produit uniquement sur les réseaux Wi-Fi d'hôtel, d'aéroport, d'école ou publics, terminez la connexion au portail de ce réseau et réessayez. Les notes de version de l'application de bureau ownCloud indiquent qu'il faut suspendre la synchronisation lorsqu'un portail captif provoque une incompatibilité de certificat, puis la reprendre une fois le portail nettoyé. Le fait qu'une page de portail intercepte le protocole HTTPS ne justifie pas de faire confiance au certificat inattendu.
Demandez à l'administrateur du serveur de vérifier le certificat TLS du point de terminaison public, y compris le serveur web ou le proxy inverse qui termine le trafic HTTPS. Le certificat doit être valide, inclure le nom DNS exact utilisé par le client et être accompagné des certificats intermédiaires requis. Une erreur fréquente lors du déploiement consiste à configurer uniquement le certificat final au lieu de la chaîne complète. Si le certificat a été renouvelé récemment, assurez-vous que le proxy inverse présente bien le nouveau certificat et non une version obsolète.
Sur un système équipé d'OpenSSL, vous pouvez examiner la négociation TLS et vérifier le nom d'hôte à l'aide de cette commande. Remplacez le nom d'exemple par le nom d'hôte ownCloud, sans le chemin d'URL :
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/nullVérifiez le résultat de la vérification et les dates des certificats. Ce test examine le point de terminaison depuis l'ordinateur sur lequel il est exécuté ; il ne reproduit pas tous les détails du magasin de certificats de confiance du client de bureau. Si le résultat détecte un certificat expiré, une incohérence de nom d'hôte, un émetteur manquant ou une autorité de certification non approuvée, corrigez le certificat ou la chaîne au niveau du point de terminaison TLS et effectuez un nouveau test. N'essayez pas de résoudre un problème de nom d'hôte ou de chaîne côté serveur en installant un certificat non pertinent sur chaque poste de travail.
Pour un service ownCloud accessible depuis Internet, la solution la plus simple consiste généralement à utiliser un certificat émis par une autorité de certification publique reconnue par les systèmes d'exploitation actuels. Configurez le point de terminaison HTTPS avec le certificat et sa chaîne complète pour le nom d'hôte public, et vérifiez que le renouvellement fonctionne. Si un proxy inverse gère le protocole HTTPS, le certificat doit être installé sur ce proxy ; modifier uniquement la configuration de l'application ownCloud n'aura aucun impact sur le certificat reçu par les clients.
Une fois le point de terminaison mis à jour par l'administrateur, testez le nom d'hôte exact depuis le même réseau qu'un ordinateur concerné. Les vérifications via le navigateur et la ligne de commande ne devraient plus signaler d'avertissement de certificat, et le client ownCloud devrait se reconnecter après une nouvelle tentative ou un redémarrage. Si le problème persiste sur certains ordinateurs seulement, comparez leurs mises à jour de système d'exploitation, leurs magasins de certificats de confiance, leurs paramètres de proxy et leurs versions du client.
Les organisations utilisent souvent une autorité de certification interne pour leurs services ownCloud privés. Dans ce cas, obtenez le certificat racine de l'autorité de certification de l'organisation via un canal authentifié et vérifiez son empreinte numérique auprès de l'administrateur. Installez ce certificat racine sur chaque ordinateur client concerné à l'aide du processus de gestion des certificats du système d'exploitation ou de la politique de gestion des appareils de l'entreprise. N'ajoutez pas un certificat téléchargé depuis la page d'avertissement comme certificat racine simplement parce que le client de synchronisation le propose ; vérifiez d'abord qu'il appartient bien à l'autorité de certification prévue.
.crtfichier dans le répertoire approprié /usr/local/share/ca-certificates/et exécutez la commande sudo update-ca-certificates. Cela met à jour le magasin de certificats de confiance du système pour les applications qui l’utilisent. Ubuntu précise que les applications Snap peuvent ne pas utiliser automatiquement les certificats ajoutés au magasin de l’hôte ; un paquet isolé peut donc nécessiter une solution de confiance spécifique.Redémarrez le client ownCloud Desktop après la mise à jour des certificats de confiance. Le package client et le système d'exploitation peuvent influencer le magasin de certificats utilisé. Si une autorité de certification est installée et qu'un navigateur fait confiance au site, mais que l'application de bureau ne fonctionne toujours pas, vérifiez le comportement et les journaux de confiance du package client au lieu d'importer plusieurs copies aléatoires du certificat du serveur.
Le serveur ownCloud dispose d'une occ security:certificatescommande pour les certificats auxquels il doit faire confiance, tels que ceux utilisés pour la fédération ou le stockage externe. Il s'agit d'un magasin de certificats de confiance côté serveur. Cette commande ne corrige pas la décision de confiance prise par le client de synchronisation de l'utilisateur lors de la connexion au site web ownCloud. En cas d'erreur de vérification sur l'ordinateur, corrigez le point de terminaison HTTPS ou la configuration de confiance de l'ordinateur concerné.
Évitez de désactiver la validation des certificats comme solution de contournement permanente. Le client en ligne de commande ownCloud propose une --trustoption, mais ignorer ou accepter un échec de vérification ne résout pas les problèmes liés à un certificat expiré, un nom d'hôte incorrect, une chaîne d'autorité de certification manquante ou une connexion non sécurisée. N'utilisez ces contrôles de confiance que dans le cadre d'un plan de test rigoureux et validé, et non comme alternative à une configuration TLS correcte sur un compte de synchronisation en production.
Si le site web s'ouvre mais que la synchronisation échoue toujours après la validation du protocole TLS, passez à la configuration WebDAV et serveur. L'application de bureau ownCloud utilise WebDAV pour ownCloud Classic ; le guide de dépannage du fournisseur recommande de vérifier que le point de terminaison WebDAV est accessible lorsque tous les clients échouent, mais que l'accès via navigateur fonctionne. Si l'erreur de certificat a disparu mais que la connexion ou la synchronisation échoue toujours, examinez l'erreur d'authentification, de proxy inverse ou WebDAV distincte indiquée dans le journal.
Le certificat présenté pour le nom d'hôte configuré est valide, contient ce nom d'hôte et est associé à une autorité de certification approuvée par le client. Le client se reconnecte sans invite de certificat et un fichier de test se synchronise correctement dans les deux sens. Si la chaîne de certificats publics est correcte mais qu'un seul client géré continue de rencontrer des problèmes, vérifiez ensuite l'horloge, le magasin de certificats de confiance, le proxy réseau, le portail captif et la version du client compatibles de cet ordinateur.
Ces vérifications permettent de résoudre les échecs de vérification de certificat. Elles ne peuvent pas corriger les problèmes non liés au compte, à WebDAV, au pare-feu ou à la disponibilité du serveur, et les menus exacts varient selon les systèmes d'exploitation et les versions de l'application ownCloud Desktop. Utilisez les journaux du client et la configuration du point de terminaison TLS du serveur pour identifier l'élément qui pose toujours problème.
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
