Klient ownCloud Desktop może przestać synchronizować dane i zgłosić, że weryfikacja certyfikatu SSL nie powiodła się, nawet gdy serwer wydaje się być dostępny w przeglądarce. Ten komunikat oznacza, że klient nie mógł ustalić, czy certyfikat serwera HTTPS jest ważny dla danego adresu serwera i czy jest zaufany w środowisku klienta. Jest to weryfikacja tożsamości TLS, a nie błąd hasła, a wielokrotne akceptowanie niezweryfikowanego certyfikatu może narazić dane uwierzytelniające konta i pliki na przechwycenie.
Zacznij od adresu serwera, ważności certyfikatu i łańcucha certyfikatu. Popraw te dane na serwerze lub jego odwrotnym serwerze proxy, jeśli to możliwe. Jeśli serwer celowo korzysta z prywatnego urzędu certyfikacji (CA), dodaj zweryfikowany certyfikat główny tego urzędu do zaufanego magazynu na komputerze. Następnie uruchom ponownie klienta stacjonarnego i sprawdź, czy synchronizacja zostanie wznowiona bez ostrzeżenia o certyfikacie.
ownCloud oferuje obecnie zarówno ownCloud Classic Server (wersje 10 i 11), jak i ownCloud Infinite Scale (oCIS). Nie wszystkie wersje aplikacji desktopowych są używane zamiennie. Według listy pobierania ownCloud z 1 września 2026 roku, aplikacja desktopowa 7.1.1 jest przeznaczona dla Infinite Scale, natomiast ownCloud Classic jest obsługiwany przez klienta 6.x; strona podaje wersję 6.0.3 dla Classic. Jeśli klient został niedawno zaktualizowany, a backendem jest ownCloud Server 10 lub 11, sprawdź zgodność przed potraktowaniem awarii połączenia jako błędu certyfikatu.
Sprawdź również dokładny adres URL skonfigurowany na koncie synchronizacji. Nazwa hosta w tym adresie URL musi być zgodna z nazwą w certyfikacie serwera. W przypadku serwera Classic zainstalowanego w ścieżce, konto może wyglądać następująco https://cloud.example.com/owncloud: ; instalacja OCIS może używać innego adresu URL bazowego. Użyj adresu skonfigurowanego przez administratora, zamiast przełączać się między nazwą hosta, adresem IP i domeną alternatywną.
Upewnij się, że data, godzina i strefa czasowa komputera są poprawne. Błędny zegar może sprawić, że aktualnie ważny certyfikat będzie wyglądał na wygasły lub jeszcze nieważny. Następnie otwórz dokładny adres URL ownCloud z konta synchronizacji w przeglądarce na tym samym komputerze. Sprawdź szczegóły certyfikatu, takie jak nazwa hosta, data ważności i wystawca. Przeglądarka, która ładuje stronę bez ostrzeżenia, jest przydatną wskazówką, ale nie dowodzi, że klient stacjonarny korzysta z tego samego magazynu certyfikatów ani że każde żądanie WebDAV podąża tą samą ścieżką proxy.
Jeśli błąd występuje tylko w hotelowej, na lotnisku, w szkole lub w publicznej sieci Wi-Fi, zakończ działanie portalu logowania tej sieci i spróbuj ponownie. Informacje o wydaniu aplikacji desktopowej ownCloud opisują wstrzymywanie synchronizacji, gdy portal uwierzytelniający powoduje niezgodność certyfikatów, a następnie ponowne uruchomienie synchronizacji po wyczyszczeniu portalu. Przechwycenie protokołu HTTPS przez stronę portalu nie jest powodem do zaufania nieoczekiwanemu certyfikatowi.
Poproś administratora serwera o weryfikację certyfikatu TLS na publicznym punkcie końcowym, w tym na serwerze WWW lub odwrotnym serwerze proxy, który kończy protokół HTTPS. Certyfikat powinien być aktualny, zawierać dokładną nazwę DNS używaną przez klienta i być obsługiwany z wymaganymi certyfikatami pośrednimi. Częstym błędem wdrażania jest konfigurowanie tylko certyfikatu liścia zamiast pełnego łańcucha. Jeśli certyfikat został niedawno odnowiony, upewnij się, że odwrotny serwer proxy prezentuje nowy certyfikat, a nie nieaktualny.
W systemie z OpenSSL możesz sprawdzić uzgadnianie TLS i nazwę hosta za pomocą tego polecenia. Zastąp przykładową nazwę nazwą hosta ownCloud bez ścieżki URL:
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/nullSprawdź wynik weryfikacji i daty certyfikatów. Ten test sprawdza punkt końcowy z komputera, na którym jest uruchamiany; nie odtwarza on wszystkich szczegółów magazynu zaufanych certyfikatów klienta stacjonarnego. Jeśli wynik wskazuje na wygasły certyfikat, niezgodność nazwy hosta, brak wystawcy lub niezaufany urząd certyfikacji, popraw certyfikat lub łańcuch w punkcie końcowym TLS i powtórz test. Nie próbuj naprawiać problemu z nazwą hosta lub łańcuchem po stronie serwera, instalując niepowiązany certyfikat na każdym komputerze stacjonarnym.
W przypadku usługi ownCloud z dostępem do internetu, najprostszym rozwiązaniem jest zazwyczaj certyfikat wydany przez publiczny urząd certyfikacji, któremu ufają obecne systemy operacyjne. Skonfiguruj punkt końcowy HTTPS z certyfikatem i pełnym łańcuchem dla publicznej nazwy hosta i sprawdź, czy odnawianie działa. Jeśli odwrotny serwer proxy obsługuje HTTPS, certyfikat należy do tego serwera proxy; zmiana samej konfiguracji aplikacji ownCloud nie zmieni certyfikatu otrzymywanego przez klientów.
Po zaktualizowaniu punktu końcowego przez administratora, przetestuj dokładną nazwę hosta z tej samej sieci, co komputer, którego dotyczy problem. Przeglądarka i sprawdzanie w wierszu poleceń nie powinny już zgłaszać ostrzeżenia o certyfikacie, a klient ownCloud powinien ponownie nawiązać połączenie po ponownej próbie lub restarcie. Jeśli tylko niektóre komputery nadal ulegają awarii, porównaj ich aktualizacje systemu operacyjnego, magazyny zaufanych certyfikatów, ustawienia proxy i kompilacje klienta.
Organizacje często korzystają z wewnętrznego urzędu certyfikacji (CA) dla prywatnych usług ownCloud. W takim przypadku należy uzyskać certyfikat głównego urzędu certyfikacji organizacji za pośrednictwem uwierzytelnionego kanału i zweryfikować jego odcisk palca u administratora. Zainstaluj główny urząd certyfikacji na każdym komputerze klienckim, którego dotyczy problem, korzystając z procesu zarządzania certyfikatami w systemie operacyjnym lub zasad zarządzania urządzeniami w przedsiębiorstwie. Nie należy dodawać certyfikatu pobranego ze strony ostrzegawczej jako głównego tylko dlatego, że oferuje go klient synchronizacji; najpierw należy sprawdzić, czy należy on do właściwego urzędu certyfikacji.
.crtplik w pliku /usr/local/share/ca-certificates/i uruchomić sudo update-ca-certificates. Spowoduje to zaktualizowanie systemowego magazynu zaufanych certyfikatów dla aplikacji, które go używają. Ubuntu ostrzega, że aplikacje Snap mogą nie używać automatycznie certyfikatów dodanych do magazynu hosta, więc ograniczony pakiet może wymagać rozwiązania dotyczącego zaufania specyficznego dla danego pakietu.Uruchom ponownie klienta ownCloud Desktop po zaktualizowaniu zaufania. Pakiet klienta i system operacyjny mogą wpływać na to, który magazyn certyfikatów jest odczytywany. Jeśli urząd certyfikacji jest zainstalowany i przeglądarka ufa witrynie, ale aplikacja na komputerze nadal nie działa, sprawdź zachowanie i logi zaufania pakietu klienta zamiast importować wiele kopii certyfikatu serwera losowo.
Serwer ownCloud posiada occ security:certificatespolecenie dotyczące certyfikatów, którym sam serwer musi ufać, takich jak certyfikaty używane do federacji lub zewnętrznej pamięci masowej. Jest to serwerowy magazyn zaufanych certyfikatów. Nie naprawia on decyzji o zaufaniu podjętej przez klienta synchronizacji pulpitu użytkownika podczas łączenia się z witryną ownCloud. W przypadku błędu weryfikacji pulpitu należy naprawić punkt końcowy HTTPS lub konfigurację zaufania na komputerze, którego dotyczy problem.
Unikaj wyłączania walidacji certyfikatów jako trwałego obejścia. Klient wiersza poleceń ownCloud dokumentuje taką --trustopcję, ale zablokowanie lub zaakceptowanie błędu weryfikacji nie naprawia wygasłego certyfikatu, nieprawidłowej nazwy hosta, brakującego łańcucha urzędów certyfikacji ani niezaufanego połączenia. Używaj takich mechanizmów kontroli zaufania tylko w ramach przemyślanego, zweryfikowanego planu testów, a nie jako zamiennika poprawnej konfiguracji TLS na produkcyjnym koncie synchronizacji.
Jeśli strona internetowa otwiera się, ale synchronizacja nadal nie może nawiązać połączenia po pomyślnym sprawdzeniu TLS, przejdź do konfiguracji WebDAV i serwera. Aplikacja desktopowa ownCloud korzysta z WebDAV w przypadku ownCloud Classic; poradnik rozwiązywania problemów dostawcy zaleca sprawdzenie, czy punkt końcowy WebDAV jest dostępny, gdy wszystkie klienty nie działają, ale dostęp przez przeglądarkę działa. Jeśli błąd certyfikatu zniknął, ale logowanie lub synchronizacja nadal się nie uda, sprawdź oddzielny błąd uwierzytelniania, odwrotnego proxy lub WebDAV wyświetlany w dzienniku.
Certyfikat przedstawiony dla skonfigurowanej nazwy hosta jest aktualny, zawiera tę nazwę hosta i jest powiązany z urzędem certyfikacji zaufanym przez komputer kliencki. Klient stacjonarny łączy się ponownie bez monitu o certyfikat, a plik testowy synchronizuje się w obu kierunkach. Jeśli publiczny łańcuch certyfikatów jest poprawny, ale tylko jeden zarządzany klient nadal nie działa, skup się następnie na zegarze tego komputera, magazynie zaufanych certyfikatów, serwerze proxy sieciowym, portalu uwierzytelniającym i kompatybilnej wersji klienta.
Te kontrole rozwiązują problemy z weryfikacją certyfikatów. Nie mogą one rozwiązać niezwiązanych z nimi problemów z kontem, WebDAV, zaporą sieciową ani dostępnością serwera, a dokładne menu różnią się w zależności od systemu operacyjnego i wersji aplikacji desktopowej ownCloud. Użyj logów klienta i konfiguracji punktu końcowego TLS serwera, aby zidentyfikować stronę, która nadal ma odmienne zdanie.
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
