Los het probleem "SSL-certificaatverificatie mislukt" op in de ownCloud Desktop Sync Client.

De ownCloud Desktop-client kan stoppen met synchroniseren en melden dat de SSL-certificaatverificatie is mislukt, zelfs als de server in een browser bereikbaar lijkt. Deze melding betekent dat de client niet kon vaststellen dat het HTTPS-servercertificaat geldig is voor het serveradres en wordt vertrouwd door de clientomgeving. Het betreft een TLS-identiteitscontrole, geen wachtwoordfout, en het herhaaldelijk accepteren van een niet-geverifieerd certificaat kan accountgegevens en bestanden blootstellen aan onderschepping.

Begin met het serveradres, de geldigheidsduur van het certificaat en de certificaatketen. Corrigeer deze gegevens indien mogelijk op de server of de reverse proxy. Als de server bewust een particuliere certificeringsinstantie (CA) gebruikt, voeg dan het geverifieerde rootcertificaat van die CA toe aan de vertrouwde certificatenopslag van de computer. Start vervolgens de desktopclient opnieuw op en controleer of de synchronisatie zonder certificaatwaarschuwing wordt hervat.

Controleer eerst welke ownCloud-client en -server u gebruikt.

ownCloud biedt momenteel zowel ownCloud Classic Server (versies 10 en 11) als ownCloud Infinite Scale (oCIS) aan. Niet alle versies van de desktop-app zijn door elkaar te gebruiken. Volgens de informatie op de downloadpagina van ownCloud van 1 september 2026 is Desktop App 7.1.1 bedoeld voor Infinite Scale, terwijl ownCloud Classic wordt ondersteund door een 6.x-client; op de pagina staat 6.0.3 vermeld voor Classic. Als een client recent is geüpgraded en de backend ownCloud Server 10 of 11 is, controleer dan de compatibiliteit voordat u een verbindingsfout als een certificaatfout beschouwt.

Controleer ook de exacte URL die is geconfigureerd in het synchronisatieaccount. De hostnaam in die URL moet overeenkomen met een naam in het servercertificaat. Voor een Classic-server die is geïnstalleerd onder een pad, kan het account er bijvoorbeeld zo uitzien https://cloud.example.com/owncloud: ; een oCIS-installatie kan een andere basis-URL gebruiken. Gebruik het adres dat door uw beheerder is geconfigureerd in plaats van te wisselen tussen een hostnaam, IP-adres en alternatief domein.

Doorloop de waarschijnlijke oorzaken in de juiste volgorde.

1. Controleer de datum, het netwerk en de exacte servernaam.

Zorg ervoor dat de datum, tijd en tijdzone van de computer correct zijn. Een onjuiste klok kan ervoor zorgen dat een geldig certificaat als verlopen of nog niet geldig wordt weergegeven. Open vervolgens de exacte ownCloud-URL van het synchronisatieaccount in een browser op dezelfde computer. Controleer de certificaatgegevens op de hostnaam, vervaldatum en uitgever. Een browser die de pagina zonder waarschuwing laadt, is een nuttige aanwijzing, maar bewijst niet dat de desktopclient dezelfde certificaatopslag gebruikt of dat elke WebDAV-aanvraag hetzelfde proxypad volgt.

Als de fout zich alleen voordoet op wifi-netwerken in hotels, op luchthavens, scholen of openbare netwerken, voltooi dan de aanmelding via het betreffende netwerkportaal en probeer het opnieuw. In de release-opmerkingen van de ownCloud desktop-app wordt beschreven hoe de synchronisatie wordt gepauzeerd wanneer een captive portal een certificaatfout veroorzaakt, en hoe de synchronisatie vervolgens wordt hervat nadat de portal is gewist. Een portalpagina die HTTPS onderschept, is geen reden om het onverwachte certificaat te vertrouwen.

2. Controleer het certificaat dat door de server wordt gepresenteerd.

Vraag de serverbeheerder om het TLS-certificaat op het publieke eindpunt te controleren, inclusief de webserver of reverse proxy die HTTPS afhandelt. Het certificaat moet actueel zijn, de exacte DNS-naam bevatten die door de client wordt gebruikt en vergezeld gaan van de vereiste tussenliggende certificaten. Een veelvoorkomende implementatiefout is het configureren van alleen het bladcertificaat in plaats van de volledige certificaatketen. Als het certificaat recent is vernieuwd, zorg er dan voor dat de reverse proxy het nieuwe certificaat presenteert in plaats van een verouderd certificaat.

Op een systeem met OpenSSL kunt u de TLS-handshake inspecteren en de hostnaam controleren met dit commando. Vervang de voorbeeldnaam door de hostnaam van ownCloud, zonder het URL-pad:

openssl s_client -connect cloud.example.com:443 \
  -servername cloud.example.com \
  -verify_hostname cloud.example.com \
  -verify_return_error </dev/null

Controleer het verificatieresultaat en de certificaatdatums. Deze test onderzoekt het eindpunt vanaf de computer waarop u deze uitvoert; het reproduceert niet elk detail van de vertrouwensarchief van de desktopclient. Als de uitvoer een verlopen certificaat, een onjuiste hostnaam, een ontbrekende uitgever of een niet-vertrouwde CA aangeeft, corrigeer dan het certificaat of de certificaatketen op het TLS-eindpunt en test opnieuw. Probeer een probleem met de hostnaam of certificaatketen aan de serverzijde niet op te lossen door een ander certificaat op elke desktop te installeren.

3. Gebruik een openbaar vertrouwd certificaat wanneer de server openbaar toegankelijk is.

Voor een via internet toegankelijke ownCloud-service is de meest eenvoudige oplossing meestal een certificaat uitgegeven door een openbare CA die wordt vertrouwd door de huidige besturingssystemen. Configureer het HTTPS-eindpunt met het certificaat en de volledige certificaatketen voor de openbare hostnaam en controleer of de verlenging werkt. Als een reverse proxy HTTPS afhandelt, hoort het certificaat bij die proxy; het wijzigen van alleen de ownCloud-applicatieconfiguratie zal het certificaat dat clients ontvangen niet wijzigen.

Nadat de beheerder het eindpunt heeft bijgewerkt, test u de exacte hostnaam vanaf hetzelfde netwerk als een getroffen computer. De browser- en opdrachtregelcontroles zouden geen certificaatwaarschuwing meer moeten weergeven en de ownCloud-client zou na een nieuwe poging of herstart opnieuw verbinding moeten maken. Als slechts enkele computers nog steeds problemen ondervinden, vergelijk dan hun besturingssysteemupdates, vertrouwensarchieven, proxy-instellingen en clientbuilds.

4. Vertrouw een private CA alleen als de server daarvoor bedoeld is.

Organisaties gebruiken vaak een interne CA voor private ownCloud-services. In dat geval dient u het root-CA-certificaat van de organisatie via een geauthenticeerd kanaal te verkrijgen en de vingerafdruk ervan te verifiëren met de beheerder. Installeer de root-CA op elke betreffende clientcomputer met behulp van het certificaatbeheerproces van het besturingssysteem of het beheerbeleid voor apparaten van de organisatie. Voeg geen certificaat dat u van de waarschuwingspagina hebt gedownload toe als root-certificaat, alleen omdat de synchronisatieclient dit aanbiedt; controleer eerst of het certificaat daadwerkelijk van de beoogde CA afkomstig is.

  • Windows: een beheerder kan de module Certificaten in Microsoft Management Console gebruiken om het geverifieerde rootcertificaat te importeren in de juiste opslag voor vertrouwde rootcertificeringsinstanties. Volg het beleid van uw organisatie met betrekking tot de vraag of het vertrouwen per gebruiker of voor de hele computer geldt.
  • macOS: gebruik Sleutelhangertoegang om het geverifieerde certificaat toe te voegen aan de juiste sleutelhanger en controleer de vertrouwensinstellingen. Apple documenteert het toevoegen van certificaatbestanden aan een sleutelhanger; beheerde Macs zouden privé-rootcertificaten moeten ontvangen via het apparaatbeheerproces van de organisatie.
  • Ubuntu: voor een CA-certificaat in PEM-formaat plaatst u een .crtbestand in de map /usr/local/share/ca-certificates/en voert u het commando uit sudo update-ca-certificates. Hiermee wordt de vertrouwensopslag van het systeem bijgewerkt voor toepassingen die het gebruiken. Ubuntu waarschuwt dat Snap-toepassingen mogelijk niet automatisch certificaten gebruiken die aan de hostopslag zijn toegevoegd, dus een beperkt pakket heeft mogelijk een pakketspecifieke vertrouwensoplossing nodig.

Start de ownCloud Desktop-client opnieuw op na het bijwerken van de vertrouwensrelatie. Het clientpakket en het besturingssysteem kunnen bepalen welke certificaatopslag wordt gebruikt. Als een CA is geïnstalleerd en een browser de site vertrouwt, maar de desktop-app nog steeds niet werkt, controleer dan het vertrouwensgedrag en de logboeken van het clientpakket in plaats van willekeurig meerdere kopieën van het servercertificaat te importeren.

Verwar desktopvertrouwen niet met het importeren van certificaten voor ownCloud-servers.

ownCloud Server heeft een occ security:certificatescommando voor certificaten die de server zelf moet vertrouwen, zoals certificaten die worden gebruikt voor federatie of externe opslag. Dit is een server-side vertrouwensarchief. Het herstelt niet de vertrouwensbeslissing die de desktopsynchronisatieclient van een gebruiker neemt bij het verbinden met de ownCloud-website. Bij een verificatiefout op de desktop moet u het HTTPS-eindpunt of de vertrouwensconfiguratie van de betreffende computer corrigeren.

Vermijd het uitschakelen van certificaatvalidatie als permanente oplossing. De ownCloud-opdrachtregelclient beschrijft een --trustoptie, maar het onderdrukken of accepteren van een verificatiefout lost een verlopen certificaat, onjuiste hostnaam, ontbrekende CA-keten of onbetrouwbare verbinding niet op. Gebruik dergelijke vertrouwensinstellingen alleen in het kader van een weloverwogen en geverifieerd testplan, en niet als vervanging voor een correcte TLS-configuratie op een productie-synchronisatieaccount.

Controleer of de synchronisatie goed verloopt.

  1. Sluit en heropen de ownCloud Desktop-client nadat u het certificaat of de vertrouwensopslag hebt gecorrigeerd.
  2. Controleer of de accountstatus verandert van een SSL- of herverbindingsfout naar een verbonden of synchroniserende status, zonder waarschuwing voor een nieuw certificaat.
  3. Maak een klein testbestand aan in de synchronisatiemap en controleer of het op de server verschijnt. Breng vervolgens een kleine wijziging aan in de webinterface en controleer of deze op het bureaublad wordt weergegeven.
  4. Controleer het clientlogboek op een succesvolle HTTPS/WebDAV-verbinding als de status onduidelijk blijft. De handleiding voor probleemoplossing van ownCloud 5.3 beschrijft hoe u het logvenster kunt openen via Geavanceerd > Logboekinstellingen of door F12, Ctrl+L of Cmd+L te gebruiken. Menunamen kunnen in andere clientversies afwijken.

Als de website wel opent, maar de synchronisatie na de TLS-controles nog steeds niet lukt, ga dan verder met WebDAV en de serverconfiguratie. De ownCloud Desktop-app gebruikt WebDAV voor ownCloud Classic; de handleiding voor probleemoplossing van de leverancier raadt aan te controleren of het WebDAV-eindpunt bereikbaar is wanneer alle clients falen, maar toegang via de browser wel werkt. Als de certificaatfout is verdwenen, maar inloggen of synchroniseren nog steeds mislukt, onderzoek dan de afzonderlijke authenticatie-, reverse-proxy- of WebDAV-fout die in het logboek wordt weergegeven.

Hoe succes eruitziet

Het certificaat dat voor de geconfigureerde hostnaam wordt aangeboden, is geldig, bevat die hostnaam en verwijst naar een certificeringsinstantie (CA) die door de clientcomputer wordt vertrouwd. De desktopclient maakt opnieuw verbinding zonder dat er om een ​​certificaat wordt gevraagd en een testbestand wordt in beide richtingen gesynchroniseerd. Als een openbare certificaatketen correct is, maar slechts één beheerde client blijft problemen ondervinden, controleer dan de klok, het vertrouwensarchief, de netwerkproxy, de captive portal en de compatibele clientversie van die computer.

Deze controles verhelpen fouten bij de certificaatverificatie. Ze kunnen geen problemen oplossen die losstaan ​​van deze controles, zoals problemen met accounts, WebDAV, firewalls of de beschikbaarheid van servers. De exacte menu's variëren bovendien per besturingssysteem en versie van de ownCloud Desktop-app. Gebruik de clientlogboeken en de TLS-eindpuntconfiguratie van de server om te achterhalen welke partij nog steeds een conflict heeft.

Officiële referenties

Laat een reactie achter

Het probleem met het hoge CPU-gebruik in Jitsi Meet op clientbrowsers oplossen.

Het probleem met het hoge CPU-gebruik in Jitsi Meet op clientbrowsers oplossen.

Diagnoseer pieken in het CPU-gebruik van de Jitsi Meet-browser en verlaag de belasting van de client door videotegels, camera-effecten, browsergraphics en hostinstellingen te controleren.

Hoe je Jitsi Videobridge-statistieken kunt monitoren met Prometheus en Grafana

Hoe je Jitsi Videobridge-statistieken kunt monitoren met Prometheus en Grafana

Monitor de status van Jitsi Videobridge, de belasting van conferenties en het verkeer met het ingebouwde Prometheus-eindpunt, en analyseer en visualiseer de gegevens vervolgens in Grafana.

Hoe configureer je een aangepaste domeinnaam voor Jitsi Meet Docker?

Hoe configureer je een aangepaste domeinnaam voor Jitsi Meet Docker?

Configureer een aangepast domein voor Jitsi Meet Docker met DNS, PUBLIC_URL, HTTPS, Let's Encrypt, firewallpoorten, NAT-instellingen en end-to-end verificatie.

Oplossing voor de 404-fout 'Zimbra Admin Console niet gevonden' na SSL-vernieuwing.

Oplossing voor de 404-fout 'Zimbra Admin Console niet gevonden' na SSL-vernieuwing.

Los 404-fouten in de Zimbra Admin Console op na het vernieuwen van een SSL-certificaat door de juiste URL en poort, proxy-routering, servicestatus, geïmplementeerde certificaten en logbestanden te controleren.

Los de Nextcloud-waarschuwing "De PHP OPcache is niet correct geconfigureerd" op.

Los de Nextcloud-waarschuwing "De PHP OPcache is niet correct geconfigureerd" op.

Leer hoe u de PHP OPcache-configuratiewaarschuwing van Nextcloud kunt diagnosticeren en oplossen door de actieve PHP SAPI, groottelimieten, opmerkingen en hervalidatie-instellingen te controleren.

Corrigeer migratiefouten in de Kopano-database na een MySQL-versie-upgrade.

Corrigeer migratiefouten in de Kopano-database na een MySQL-versie-upgrade.

Los problemen met Kopano-databasemigraties na een MySQL- of MariaDB-upgrade op door back-ups, serverversies, SQL-modi, tekenset, schemastatus en logbestanden te controleren.

Hoe configureer je LDAP- en Active Directory-authenticatie in Nextcloud?

Hoe configureer je LDAP- en Active Directory-authenticatie in Nextcloud?

Verbind Nextcloud met LDAP of Active Directory via beveiligd transport, gebruikers- en groepsfilters, inlogkenmerken en een geteste uitrolprocedure.

Element Android-meldingen repareren zonder Google-services: UnifiedPush-handleiding

Element Android-meldingen repareren zonder Google-services: UnifiedPush-handleiding

Los problemen met Element Android-meldingen op telefoons zonder Google op door UnifiedPush, Android-machtigingen, batterij-instellingen en betrouwbare verificatietests te configureren.

Los de Nextcloud-waarschuwing "Database mist enkele indexen" op.

Los de Nextcloud-waarschuwing "Database mist enkele indexen" op.

Verwijder de waarschuwing van Nextcloud over ontbrekende database-indexen met het officiële occ-commando. Maak eerst een back-up, bekijk de wijzigingen, voer de reparatie uit en controleer het resultaat.

Hoe configureer je Single Sign-On (SSO) met Keycloak in Element Web?

Hoe configureer je Single Sign-On (SSO) met Keycloak in Element Web?

Configureer Keycloak SSO voor Element Web door OIDC met Synapse te verbinden, de exacte callback-URL in te stellen, gebruikersclaims te koppelen en het uitloggen te testen.