ownCloud 데스크톱 동기화 클라이언트에서 발생하는 "SSL 인증서 확인 실패" 오류 해결
ownCloud Desktop 동기화 인증서 오류를 해결하려면 서버 URL, 인증서 이름 및 체인, 시스템 시계, 클라이언트 버전 및 신뢰할 수 있는 CA 저장소를 확인하십시오.
ownCloud 데스크톱 클라이언트가 동기화를 중지하고 SSL 인증서 확인 실패 메시지를 표시할 수 있습니다. 이는 브라우저에서 서버에 접속할 수 있는 것처럼 보이더라도 발생할 수 있는 오류입니다. 해당 메시지는 클라이언트가 HTTPS 서버 인증서가 서버 주소에 대해 유효하고 클라이언트 환경에서 신뢰할 수 있는 인증서인지 확인할 수 없음을 의미합니다. 이는 비밀번호 오류가 아니라 TLS ID 확인 문제이며, 확인되지 않은 인증서를 반복적으로 수락하면 계정 자격 증명 및 파일이 유출될 위험이 있습니다.
먼저 서버 주소, 인증서 유효성 및 인증서 체인을 확인하십시오. 가능한 경우 서버 또는 역방향 프록시에서 해당 정보를 수정하십시오. 서버가 의도적으로 사설 인증 기관(CA)을 사용하는 경우 해당 CA의 검증된 루트 인증서를 컴퓨터의 신뢰 저장소에 추가하십시오. 그런 다음 데스크톱 클라이언트를 다시 시작하고 인증서 경고 없이 동기화가 재개되는지 확인하십시오.
ownCloud는 현재 ownCloud Classic Server(버전 10 및 11)와 ownCloud Infinite Scale(oCIS)을 모두 제공합니다. 두 버전 모두 데스크톱 앱의 모든 릴리스를 상호 교환하여 사용할 수 있는 것은 아닙니다. 2026년 9월 1일 기준 ownCloud 다운로드 페이지에 따르면 데스크톱 앱 7.1.1은 Infinite Scale용이며, ownCloud Classic은 6.x 클라이언트에서 지원됩니다. 페이지에는 Classic용 데스크톱 앱으로 6.0.3 버전이 명시되어 있습니다. 클라이언트를 최근에 업그레이드했고 백엔드가 ownCloud Server 10 또는 11인 경우, 연결 실패를 인증서 오류로 간주하기 전에 호환성을 확인하십시오.
동기화 계정에 구성된 정확한 URL도 확인하십시오. 해당 URL의 호스트 이름은 서버 인증서의 이름과 일치해야 합니다. 경로에 설치된 클래식 서버의 경우 계정은 다음과 같은 형식일 수 있습니다 https://cloud.example.com/owncloud. oCIS 설치의 경우 기본 URL이 다를 수 있습니다. 호스트 이름, IP 주소, 대체 도메인을 번갈아 사용하지 말고 관리자가 구성한 주소를 사용하십시오.
컴퓨터의 날짜, 시간 및 시간대가 올바른지 확인하십시오. 시계가 심하게 잘못 설정되어 있으면 현재 유효한 인증서가 만료되었거나 아직 유효하지 않은 것처럼 보일 수 있습니다. 다음으로, 동일한 컴퓨터의 브라우저에서 동기화 계정의 ownCloud URL을 엽니다. 호스트 이름, 만료일 및 발급자를 포함한 인증서 세부 정보를 검사합니다. 경고 없이 페이지가 로드되는 것은 유용한 단서이지만, 데스크톱 클라이언트가 동일한 인증서 저장소를 사용하거나 모든 WebDAV 요청이 동일한 프록시 경로를 따른다는 것을 증명하는 것은 아닙니다.
호텔, 공항, 학교 또는 공용 Wi-Fi에서만 오류가 발생하는 경우 해당 네트워크의 로그인 포털을 완료하고 다시 시도하십시오. ownCloud 데스크톱 앱 릴리스 노트에는 캡티브 포털에서 인증서 불일치가 발생하면 동기화를 일시 중지한 다음 포털이 초기화된 후 동기화를 다시 시작한다고 설명되어 있습니다. HTTPS를 가로채는 포털 페이지는 예상치 못한 인증서를 신뢰할 이유가 되지 않습니다.
서버 관리자에게 웹 서버 또는 HTTPS 연결을 종료하는 리버스 프록시를 포함한 공용 엔드포인트의 TLS 인증서를 확인하도록 요청하십시오. 인증서는 최신 상태여야 하며, 클라이언트가 사용하는 정확한 DNS 이름을 포함하고, 필요한 중간 인증서와 함께 제공되어야 합니다. 일반적인 배포 오류는 전체 인증서 체인 대신 최하위 인증서만 구성하는 것입니다. 인증서가 최근에 갱신되었다면 리버스 프록시가 만료된 인증서가 아닌 새 인증서를 제공하고 있는지 확인하십시오.
OpenSSL이 설치된 시스템에서는 다음 명령어를 사용하여 TLS 핸드셰이크를 검사하고 호스트 이름을 확인할 수 있습니다. 예시 이름 대신 URL 경로를 제외한 ownCloud 호스트 이름을 입력하십시오.
openssl s_client -connect cloud.example.com:443 \
-servername cloud.example.com \
-verify_hostname cloud.example.com \
-verify_return_error </dev/null
검증 결과와 인증서 날짜를 검토하십시오. 이 테스트는 테스트를 실행하는 컴퓨터의 엔드포인트를 검사하는 것이며, 데스크톱 클라이언트의 신뢰 저장소의 모든 세부 정보를 재현하는 것은 아닙니다. 출력에서 만료된 인증서, 호스트 이름 불일치, 발급자 누락 또는 신뢰할 수 없는 CA가 발견되면 TLS 엔드포인트에서 인증서 또는 인증서 체인을 수정하고 다시 테스트하십시오. 서버 측 호스트 이름 또는 인증서 체인 문제를 해결하기 위해 모든 데스크톱에 관련 없는 인증서를 설치하지 마십시오.
인터넷에 연결된 ownCloud 서비스의 경우, 가장 간단한 해결책은 일반적으로 최신 운영 체제에서 신뢰하는 공용 CA에서 발급한 인증서를 사용하는 것입니다. 공용 호스트 이름에 대한 인증서와 전체 인증서 체인을 사용하여 HTTPS 엔드포인트를 구성하고 갱신이 제대로 작동하는지 확인하십시오. 리버스 프록시가 HTTPS를 처리하는 경우, 인증서는 해당 프록시에 있어야 합니다. ownCloud 애플리케이션 구성만 변경하면 클라이언트가 받는 인증서는 변경되지 않습니다.
관리자가 엔드포인트를 업데이트한 후, 문제가 발생한 컴퓨터와 동일한 네트워크에서 해당 호스트 이름을 테스트하십시오. 브라우저 및 명령줄 검사에서 더 이상 인증서 경고가 표시되지 않아야 하며, ownCloud 클라이언트는 재시도 또는 재시작 후 다시 연결되어야 합니다. 일부 컴퓨터에서만 여전히 문제가 발생하는 경우, 해당 컴퓨터의 운영 체제 업데이트, 신뢰 저장소, 프록시 설정 및 클라이언트 빌드를 비교하십시오.
조직에서는 종종 자체 CA를 사용하여 프라이빗 ownCloud 서비스를 운영합니다. 이 경우, 인증된 채널을 통해 조직의 루트 CA 인증서를 발급받고 관리자에게 해당 인증서의 지문을 확인하십시오. 운영 체제의 인증서 관리 프로세스 또는 기업의 관리 장치 정책을 사용하여 영향을 받는 각 클라이언트 컴퓨터에 루트 CA를 설치하십시오. 동기화 클라이언트에서 제공한다는 이유만으로 경고 페이지에서 다운로드한 인증서를 루트 인증서로 추가하지 마십시오. 먼저 해당 인증서가 의도된 CA에 속하는지 확인해야 합니다.
.crt파일을 해당 위치에 놓고 `git status` 명령 /usr/local/share/ca-certificates/을 실행하세요 sudo update-ca-certificates. 이렇게 하면 해당 인증서를 사용하는 애플리케이션에 대한 시스템 신뢰 저장소가 업데이트됩니다. Ubuntu는 Snap 애플리케이션이 호스트 저장소에 추가된 인증서를 자동으로 사용하지 않을 수 있으므로, 제한된 패키지의 경우 패키지별 신뢰 솔루션이 필요할 수 있다고 경고합니다.신뢰 설정을 업데이트한 후 ownCloud 데스크톱 클라이언트를 다시 시작하세요. 클라이언트 패키지와 운영 체제에 따라 클라이언트가 읽는 인증서 저장소가 다를 수 있습니다. CA가 설치되어 있고 브라우저에서 해당 사이트를 신뢰하지만 데스크톱 앱에서 여전히 오류가 발생하는 경우, 서버 인증서를 임의로 여러 개 가져오는 대신 클라이언트 패키지의 신뢰 설정 동작과 로그를 확인하세요.
ownCloud 서버에는 occ security:certificates페더레이션이나 외부 저장소에 사용되는 인증서와 같이 서버 자체에서 신뢰해야 하는 인증서를 관리하는 명령어가 있습니다. 이는 서버 측 신뢰 저장소입니다. 이 기능은 사용자의 데스크톱 동기화 클라이언트가 ownCloud 웹사이트에 연결할 때 내린 신뢰 결정을 수정하는 기능은 아닙니다. 데스크톱 인증 오류가 발생하는 경우, HTTPS 엔드포인트 또는 해당 컴퓨터의 신뢰 구성을 수정하십시오.
인증서 유효성 검사를 비활성화하는 것을 영구적인 해결 방법으로 사용하지 마십시오. ownCloud 명령줄 클라이언트에는 관련 --trust옵션이 있지만, 검증 실패를 무시하거나 수락하는 것은 만료된 인증서, 잘못된 호스트 이름, 누락된 CA 체인 또는 신뢰할 수 없는 연결 문제를 해결하지 못합니다. 이러한 신뢰 제어는 의도적이고 검증된 테스트 계획 하에서만 사용해야 하며, 프로덕션 동기화 계정의 올바른 TLS 구성을 대체하는 용도로 사용해서는 안 됩니다.
웹사이트는 열리지만 TLS 검사 후에도 동기화 연결이 되지 않으면 WebDAV 및 서버 구성을 확인하십시오. ownCloud 데스크톱 앱은 ownCloud Classic에 WebDAV를 사용합니다. 공급업체의 문제 해결 가이드에서는 모든 클라이언트에서 오류가 발생하지만 브라우저에서는 접속이 가능한 경우 WebDAV 엔드포인트에 연결할 수 있는지 확인하도록 권장합니다. 인증서 오류가 사라졌지만 로그인 또는 동기화가 여전히 실패하는 경우 로그에 표시된 별도 인증, 역방향 프록시 또는 WebDAV 오류를 조사하십시오.
구성된 호스트 이름에 대해 제공된 인증서는 유효하고 해당 호스트 이름을 포함하며 클라이언트 컴퓨터에서 신뢰하는 CA로 연결됩니다. 데스크톱 클라이언트는 인증서 프롬프트 없이 다시 연결되고 테스트 파일이 양방향으로 동기화됩니다. 공개 인증서 체인이 올바르지만 특정 관리 클라이언트에서만 계속 오류가 발생하는 경우, 다음으로 해당 컴퓨터의 시계, 신뢰 저장소, 네트워크 프록시, 캡티브 포털 및 호환되는 클라이언트 버전을 확인하십시오.
이러한 검사는 인증서 확인 실패 문제를 해결합니다. 계정, WebDAV, 방화벽 또는 서버 가용성 문제와 같은 관련 없는 문제는 해결할 수 없으며, 정확한 메뉴는 운영 체제 및 ownCloud 데스크톱 앱 버전에 따라 다릅니다. 클라이언트 로그와 서버의 TLS 엔드포인트 구성을 사용하여 어느 쪽에서 여전히 문제가 발생하는지 확인하십시오.
ownCloud Desktop 동기화 인증서 오류를 해결하려면 서버 URL, 인증서 이름 및 체인, 시스템 시계, 클라이언트 버전 및 신뢰할 수 있는 CA 저장소를 확인하십시오.
PhpRedis, APCu, 루프백 전용 Redis 서비스를 사용하여 Ubuntu 24.04에서 Nextcloud용 Redis 파일 잠금 및 분산 캐싱을 설정하고 실제 검증 단계를 안내합니다.
메시지 기록을 손상시키지 않고 장치 인증, 키 백업, 복구 키 및 누락된 룸 키를 확인하여 Element Web 암호 해독 오류를 해결하세요.
Nextcloud 2FA 공급자를 활성화하고, 사용자 또는 그룹에 대한 2단계 인증을 적용하고, 복구를 준비하고, 로그인 및 클라이언트 앱을 확인하는 방법을 알아보세요.
zimbraMtaMyNetworks를 사용하여 Zimbra에서 인증되지 않은 아웃바운드 메일 릴레이를 신뢰할 수 있는 IP 주소로 제한하세요. 허용 목록을 안전하게 검사, 업데이트, 다시 로드 및 확인하는 방법을 알아보세요.
Nextcloud의 PHP memory_limit을 최소 512M로 설정하고, 올바른 웹 PHP 구성을 찾은 다음, Apache 또는 PHP-FPM을 다시 시작하고 경고가 사라졌는지 확인하십시오.
Synapse를 사용하여 Matrix WebRTC 통화를 위한 Coturn 설정을 구성합니다. 공유 자격 증명, NAT, 방화벽 포트, TLS 옵션을 구성하고 기존 TURN과 MatrixRTC 및 LiveKit을 구분합니다.
Nextcloud 메일을 Gmail 또는 Microsoft 365용 OAuth2로 구성하고, IMAP/SMTP 액세스를 확인하고, 리디렉션 문제를 해결하고, 제한 사항을 파악하세요.
Element의 "ID 확인 불가" 세션 경고를 해결하려면 다른 신뢰할 수 있는 장치 또는 복구 키를 사용하여 인증하고, 재설정이 안전한 시점을 알아보세요.
Kopano 마이그레이션과 grommunio 및 Zammad 마이그레이션을 비교해 보세요. 각 마이그레이션 경로에서 보존할 수 있는 사서함 데이터, 테스트 및 결과 검증 방법, 그리고 IMAP 또는 사용자 지정 가져오기가 적합한 경우를 알아보세요.