ownCloud同期証明書のTLSソースエラーを修正する

ownCloud Desktopの同期証明書エラーを修正するには、サーバーが提示するTLS証明書を修正するか、証明書を発行した信頼できるプライベートCAをインストールしてください。まず、証明書が正確なサーバーホスト名に対して有効であり、中間証明書チェーンが含まれていることを確認してください。証明書のチェックを無効にしたり、説明のない警告をクリックしたりしないでください。

変更を加える前に、クライアントのバージョンを確認してください。2026年10月現在、ownCloudのリリースノートにはデスクトップアプリ7.1.0と6.0.3が記載されています。7.xシリーズはInfinite Scaleのみをサポートし、ownCloud Server Classic 10または11は6.xシリーズを必要とします。また、同じリリースノートには、キャプティブポータルが証明書の不一致を引き起こし、同期を一時停止する可能性があることも説明されています。ownCloudデスクトップアプリのリリースノートを参照してください。

1. URLを確認し、証明書のエラーを特定します。

ownCloudデスクトップアプリに表示されるサーバーURLと、ブラウザで正常に動作するアドレスを比較してください。ホスト名とパスは同じものを使用してください。ブラウザは、不足している中間証明書を自動的に取得できる場合がありますが、デスクトップクライアントではそれができない場合があります。

証明書の詳細を確認し、サブジェクト代替名（SAN）（証明書が対象とするホスト名）に、入力したホスト名が含まれていることを確認してください。証明書が、両方のホスト名が同じサーバーに到達するからといって、必ずしもそのホスト名を対象とするとはfiles.internal.local限りませんcloud.example.com。有効期限と発行者を確認し、コンピューターの時計も確認してください。ローカルの日付が間違っていると、有効な証明書が期限切れまたは未有効と表示されることがあります。

ブラウザでもエラーが報告される場合、または複数のデバイスでエラーが発生する場合は、サーバーまたはリバースプロキシに問題がある可能性が高いです。コンピュータが1台だけエラーを起こす場合は、そのコンピュータのトラストストア、時計、プロキシ、およびクライアントバージョンを確認してください。ownCloudのデスクトップアプリのトラブルシューティングガイドでは、デスクトップクライアントが接続できない場合に、ブラウザのアクセスを確認し、サーバーのURLまたはプロキシを確認することを推奨しています。

2. サーバー証明書と証明書チェーンを修復する

サーバー管理者に、SAN（サブジェクトアドレス）にユーザーが入力する公開ホスト名が含まれ、有効期限が最新で、秘密鍵が証明書と一致する証明書をインストールするよう依頼してください。証明書は接続を暗号化できますが、ホスト名が間違っていたり、発行者が確認できない場合は、本人確認に失敗する可能性があります。

HTTPSエンドポイントは、サーバー証明書と必要な中間CA証明書を正しい順序で提示する必要があります。通常、ルートCA証明書は送信すべきではありません。クライアントは既にそのルート証明書を信頼している必要があるためです。ownCloudホストだけでなく、HTTPSを終端するリバースプロキシまたはロードバランサーも確認してください。バックエンドファイルの更新後も、プロキシが古い証明書や不完全な証明書チェーンを提供している可能性があります。

OpenSSLがインストールされているマシンで迅速な診断を行うには、以下のホスト名の例を置き換えてから、次のコマンドを実行してください。

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

-servername1 つのサーバーが複数の TLS サイトをホストしている場合、Server Name Indication にホスト名を送信します。チェーンと検証結果を確認してください。発行者エラーは、中間 CA が見つからないか信頼されていないことを示唆します。ホスト名または日付エラーの場合は、証明書または URL を修正する必要があります。これは、そのマシンとネットワーク パスから到達可能なエンドポイントのみをチェックします。OpenSSLリファレンスを参照s_clientしてください。

3. プライベート認証局を信頼するのは、それが期待される場合にのみ行う。

組織がプライベート認証局 (CA) を使用している場合は、認証済みチャネルを通じてルート証明書を取得し、管理者とフィンガープリントを確認してください。サーバーの秘密鍵ではなく、その CA 証明書をオペレーティングシステムのトラスト ストアにインストールし、ownCloud クライアントを再起動します。Debian または Ubuntu では、管理者は末尾が の PEM エンコードされた CA 証明書を の.crt下に配置して/usr/local/share/ca-certificates/を実行できますsudo update-ca-certificates。他のプラットフォームでは、異なるトラスト ストア ツールを使用します。

TLS の動作は、クライアントのビルドやプラットフォームによって異なる場合があります。Qt のドキュメントには、デフォルトの TLS 構成ではシステムの CA リストを使用すると記載されていますが、すべてのパッケージが必ずしも同じように構成されているとは限りません。CA を追加しても問題が解決しない場合は、管理者にクライアント パッケージとログを確認するよう依頼してください。検証されていないブラウザーの警告から証明書をインポートしないでください。Qtの CA 証明書構成に関するドキュメントを参照してください。ownCloud のサーバーの FAQ では、自己署名 SSL 証明書について管理者にセキュリティ ガイダンスを参照するよう指示しており、通常のクライアント検証を弱めることは推奨していません。

自己署名サーバー証明書は、信頼できるプライベート認証局（CA）が発行した証明書とは異なります。プライベートCAを使用する場合は、管理されたチャネルを通じてCAルートを配布して信頼し、そのCAによって署名されたホスト名に一致するサーバー証明書を提供してください。証明書の変更プロンプトを日常的な回避策として受け入れることは避けてください。中間者攻撃の際に、ユーザーがなりすましを承認するように学習してしまう可能性があります。

4. キャプティブポータルまたは傍受プロキシを除外する

公共Wi-Fi、ホテルネットワーク、または最近変更された社内ネットワークでのみ障害が発生する場合は、まずブラウザを開き、ネットワークサインインページを完了してください。キャプティブポータルはログイン前にリクエストを傍受し、ownCloudホスト名に属さない証明書を提示する可能性があります。ownCloudのリリースノートには、キャプティブポータルによって証明書の不一致が発生した場合、同期が一時停止し、ポータルがクリアされた後に再開されることが明記されています。

管理対象のワークデバイスでは、HTTPS検査プロキシによってサーバー証明書が組織の検査CAによって署名された証明書に置き換えられる場合があります。IT部門に、これが想定される動作かどうか、また承認済みのCAがデスクトップクライアントにインストールされているかどうかを確認してください。同期を機能させるために検証をバイパスしないでください。プロキシまたは信頼設定は管理者が修正する必要があります。

修正を確認してください

クライアントを終了して再度開き、アカウントが正確な HTTPS URL に接続されていることを確認し、同期ステータスが完了を報告するまで待ちます。同期フォルダーに小さなテストファイルを作成し、Web インターフェイスに表示されることを確認してから、クライアント ログで TLS 検証メッセージが繰り返し発生していないか確認します。証明書エラーが解消されない場合は、正確なホスト名、クライアント バージョン、オペレーティングシステム、エラー発生時刻、および特定の証明書エラーを管理者に送信してください。パスワードや秘密鍵は絶対に送信しないでください。ownCloud の Web インターフェイスは正常に動作するものの、互換性のあるデスクトップ アプリがすべて失敗する場合は、サーバー URL と TLS 診断出力を提供して、管理者がプロキシまたは証明書チェーンを調査できるようにします。