Clientul ownCloud Desktop poate opri sincronizarea și raporta că verificarea certificatului SSL a eșuat chiar dacă serverul pare accesibil într-un browser. Acest mesaj înseamnă că clientul nu a putut stabili dacă certificatul serverului HTTPS este valid pentru adresa serverului și este de încredere pentru mediul clientului. Este o verificare a identității TLS, nu o eroare de parolă, iar acceptarea repetată a unui certificat neverificat poate expune interceptării acreditărilor și fișierelor contului.
Începeți cu adresa serverului, validitatea certificatului și lanțul de certificate. Corectați-le pe cele de pe server sau de pe proxy-ul său invers, atunci când este posibil. Dacă serverul utilizează intenționat o autoritate de certificare (CA) privată, adăugați certificatul rădăcină verificat al acelei CA în depozitul de încredere al computerului. Apoi, reporniți clientul desktop și confirmați că sincronizarea se reia fără un avertisment privind certificatul.
ownCloud are în prezent atât ownCloud Classic Server (versiunile 10 și 11), cât și ownCloud Infinite Scale (oCIS). Nu utilizează fiecare versiune a aplicației desktop în mod interschimbabil. Începând cu listarea paginii de descărcare ownCloud din 1 septembrie 2026, aplicația desktop 7.1.1 este pentru Infinite Scale, în timp ce ownCloud Classic este acceptat de un client 6.x; pagina listează 6.0.3 pentru Classic. Dacă un client a fost recent actualizat și backend-ul este ownCloud Server 10 sau 11, verificați compatibilitatea înainte de a trata o eroare de conexiune ca o eroare de certificat.
De asemenea, confirmați adresa URL exactă configurată în contul de sincronizare. Numele de gazdă din adresa URL respectivă trebuie să corespundă unui nume din certificatul serverului. Pentru un server Classic instalat sub o cale, contul poate arăta astfel https://cloud.example.com/owncloud; o instalare oCIS poate utiliza o adresă URL de bază diferită. Utilizați adresa configurată de administrator în loc să comutați între un nume de gazdă, o adresă IP și un domeniu alternativ.
Asigurați-vă că data, ora și fusul orar al computerului sunt corecte. Un ceas complet greșit poate face ca un certificat valid în prezent să pară expirat sau nevalid. Apoi, deschideți adresa URL exactă ownCloud din contul de sincronizare într-un browser de pe același computer. Verificați detaliile certificatului pentru numele de gazdă, data expirării și emitentul. Un browser care încarcă pagina fără avertisment este un indiciu util, dar nu dovedește că clientul desktop utilizează același depozit de certificate sau că fiecare solicitare WebDAV urmează aceeași cale proxy.
Dacă eroarea apare doar pe un hotel, aeroport, școală sau pe o rețea Wi-Fi publică, finalizați portalul de conectare al rețelei respective și încercați din nou. Notele de lansare a aplicației desktop ownCloud descriu întreruperea sincronizării atunci când un portal captiv provoacă o nepotrivire de certificat, apoi reluarea sincronizării după ce portalul este șters. O pagină de portal care interceptează HTTPS nu este un motiv pentru a avea încredere în certificatul neașteptat.
Solicitați administratorului serverului să verifice certificatul TLS pe endpoint-ul public, inclusiv pe serverul web sau pe proxy-ul invers care termină HTTPS. Certificatul trebuie să fie actual, să includă numele DNS exact utilizat de client și să fie servit cu certificatele intermediare necesare. O eroare frecventă de implementare este configurarea doar a certificatului frunză în loc de lanțul complet. Dacă certificatul a fost reînnoit recent, asigurați-vă că proxy-ul invers prezintă noul certificat, nu unul învechit.
Pe un sistem cu OpenSSL, puteți inspecta handshake-ul TLS și verifica numele gazdei cu această comandă. Înlocuiți numele exemplu cu numele gazdei ownCloud, fără calea URL:
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/nullVerificați rezultatul verificării și datele certificatelor. Acest test examinează endpoint-ul de pe computerul pe care îl rulați; nu reproduce fiecare detaliu al depozitului de încredere al clientului desktop. Dacă rezultatul identifică un certificat expirat, o nepotrivire a numelui de gazdă, un emitent lipsă sau o CA neîncrezătoare, corectați certificatul sau lanțul la endpoint-ul TLS și testați din nou. Nu încercați să remediați o problemă de nume de gazdă sau lanț la nivelul serverului instalând un certificat fără legătură pe fiecare desktop.
Pentru un serviciu ownCloud conectat la internet, cea mai simplă soluție este de obicei un certificat emis de o autoritate de certificare publică (CA) în care sistemele de operare actuale au încredere. Configurați endpoint-ul HTTPS cu certificatul și lanțul complet pentru numele de gazdă public și verificați dacă reînnoirea funcționează. Dacă un proxy invers gestionează HTTPS, certificatul aparține acelui proxy; modificarea doar a configurației aplicației ownCloud nu va modifica certificatul pe care îl primesc clienții.
După ce administratorul actualizează endpoint-ul, testați numele exact al gazdei din aceeași rețea ca și computerul afectat. Verificările browserului și ale liniei de comandă nu ar trebui să mai raporteze un avertisment privind certificatul, iar clientul ownCloud ar trebui să se reconecteze după o reîncercare sau o repornire. Dacă doar unele computere încă nu reușesc, comparați actualizările sistemului de operare, depozitele de încredere, setările proxy și versiunile clientului.
Organizațiile utilizează adesea un CA intern pentru serviciile private ownCloud. În acest caz, obțineți certificatul CA rădăcină al organizației printr-un canal autentificat și verificați amprenta acestuia cu administratorul. Instalați CA rădăcină pe fiecare computer client afectat utilizând procesul de gestionare a certificatelor al sistemului de operare sau politica de dispozitive gestionate a întreprinderii. Nu adăugați un certificat descărcat de pe pagina de avertizare ca rădăcină doar pentru că clientul de sincronizare îl oferă; verificați mai întâi dacă aparține CA-ului intenționat.
.crtfișier în /usr/local/share/ca-certificates/și rulați sudo update-ca-certificates. Aceasta actualizează depozitul de încredere al sistemului pentru aplicațiile care îl utilizează. Ubuntu avertizează că aplicațiile Snap pot să nu utilizeze automat certificatele adăugate în depozitul gazdă, astfel încât un pachet limitat poate necesita o soluție de încredere specifică pachetului.Reporniți clientul ownCloud Desktop după actualizarea încrederii. Pachetul client și sistemul de operare pot afecta depozitul de certificate pe care îl citește. Dacă este instalat un CA și un browser are încredere în site, dar aplicația desktop tot eșuează, verificați comportamentul de încredere și jurnalele pachetului client în loc să importați mai multe copii ale certificatului serverului la întâmplare.
Serverul ownCloud are o occ security:certificatescomandă pentru certificatele în care serverul însuși trebuie să aibă încredere, cum ar fi certificatele utilizate pentru federație sau stocare externă. Acesta este un depozit de încredere pe partea serverului. Nu repară decizia de încredere luată de clientul de sincronizare desktop al unui utilizator la conectarea la site-ul web ownCloud. Pentru o eroare de verificare desktop, remediați endpoint-ul HTTPS sau configurația de încredere a computerului afectat.
Evitați dezactivarea validării certificatelor ca soluție permanentă. Clientul din linia de comandă ownCloud documentează o --trustopțiune, dar suprimarea sau acceptarea unei erori de verificare nu repară un certificat expirat, un nume de gazdă incorect, un lanț CA lipsă sau o conexiune neîncrezătoare. Utilizați astfel de controale de încredere numai în cadrul unui plan de testare verificat și deliberat, nu ca înlocuitor pentru configurația TLS corectă pe un cont de sincronizare de producție.
Dacă site-ul web se deschide, dar sincronizarea tot nu se poate conecta după ce verificările TLS trec, treceți la configurarea WebDAV și a serverului. Aplicația desktop ownCloud utilizează WebDAV pentru ownCloud Classic; ghidul de depanare al furnizorului recomandă verificarea faptului că endpoint-ul WebDAV este accesibil atunci când toți clienții eșuează, dar accesul prin browser funcționează. Dacă eroarea de certificat a dispărut, dar conectarea sau sincronizarea tot eșuează, investigați eroarea separată de autentificare, proxy invers sau WebDAV afișată în jurnal.
Certificatul prezentat pentru numele de gazdă configurat este actualizat, conține acel nume de gazdă și se leagă de o CA de încredere pentru computerul client. Clientul desktop se reconectază fără o solicitare de certificat, iar un fișier de test se sincronizează în ambele direcții. Dacă un lanț public de certificate este corect, dar doar un singur client gestionat continuă să eșueze, concentrați-vă în continuare pe ceasul computerului respectiv, depozitul de încredere, proxy-ul de rețea, portalul captiv și versiunea de client compatibilă.
Aceste verificări abordează erorile de verificare a certificatelor. Nu pot corecta problemele de cont, WebDAV, firewall sau disponibilitate a serverului care nu au legătură cu acestea, iar meniurile exacte variază în funcție de sistemele de operare și de versiunile aplicației desktop ownCloud. Folosiți jurnalele clientului și configurația endpoint-ului TLS al serverului pentru a identifica care parte nu este încă de acord.
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
