キー、ディスカバリ、URLを確認してWOPI認証エラーを修正する
Collabora WOPI 認証の失敗を、鍵の不一致、古い検出データ、クロックのずれ、プロキシ URL の変更などが原因で発生する場合でも、検証の信頼性を損なうことなく追跡できます。
キー、ディスカバリ、URLを確認してWOPI認証エラーを修正する
WOPI ホストが「証明検証失敗」または「無効な WOPI 証明」を報告した場合、まずどのシステムが拒否をログに記録したかを確認してください。ストレージ ホストが Collabora の署名付きリクエストを拒否している場合は、WOPI ホストの許可リストを変更したり、証明チェックを無効にしたりする前に、証明キー ペアと検出応答を確認してください。パッケージのインストールの場合、通常 Collabora がキー ペアを生成します。Docker、Kubernetes、およびマルチ レプリカ デプロイメントの場合は、キー ペアを別途提供し、一貫して永続化する必要があります。
キーを変更する前に、失敗したチェックを特定してください。
WOPI の証明検証では、署名付きリクエストと、WOPI クライアントが検出メタデータで公開する公開鍵を使用します。これは、Collabora の信頼できる WOPI ホストのリスト、TLS 証明書の検証、およびストレージ ホストのアクセス トークン チェックとは別個のものです。秘密鍵が見つからない場合や、公開鍵と一致しない場合は、鍵の再生成が有効ですが、レプリカが 1 つだけ変更された場合や、ホストにキャッシュされた検出データが残っている場合は、新たな不一致が発生する可能性があります。
| ログに証拠あり | 確認すべき可能性のあるエリア |
|---|---|
| ストレージホストがCheckFileInfoまたは別のWOPIリクエストを受信中に「無効なWOPI証明」と表示する | Collaboraの証明キー、ホストの検出データ、URLの再構築、またはタイムスタンプ |
| Collaboraは「許可されていないWOPIホスト」または「受け入れ可能なWOPIホストがありません」と表示します。 | WOPIホストの許可リスト/ドメイン設定であり、証明キーではない。 |
| トークンが無効、期限切れ、または証明なしでのアクセス拒否エラー | ホストが発行したアクセストークン、権限、またはトークンの有効期限切れ |
Collaboraとストレージホストの両方のログで、失敗したリクエストを1つずつ確認してください。ブラウザのスピナーだけでは、証明鍵の失敗を特定できません。
展開に適した修理を選択してください
まずは、最も影響の少ない方法から始めましょう。パッケージベースのインストールの場合、まず既存のキーファイルとサービスログを確認してください。Collaboraの最新ドキュメントによると、RPMおよびDebianパッケージのインストールでは、WOPI認証キーペアが自動的に生成されます。これらのファイルが存在し、安定している場合は、通常、ローテーションは不要です。
| デプロイメント | 推奨されるアクション | トレードオフ |
|---|---|---|
| シングルパッケージ管理サーバー | 生成されたキーペアを保持します。権限が欠落しているか一致しない場合にのみ、権限を修復または再生成します。 | 変更点は最小限ですが、パッケージのバージョンと設定済みのパスを確認してください。 |
| 単一のDockerコンテナ | ペアを一度生成し、コンテナに永続的にマウントする | coolwsdには永続ボリュームと正しい読み取りアクセスが必要です |
| Kubernetesまたは複数のレプリカ | Collaboraインスタンスごとに、共有シークレット/キーペアを1組マウントします。 | レプリカ間で一貫した署名。ローテーションはホストの検出ビューも更新する必要がある。 |
| プロキシ経由でホストURLが変更されました | 署名検証に使用される公開スキーム、ホスト、パス、およびクエリ文字列を確認します。 | キーを回転させるよりも手間はかかるが、不要な認証情報の変更を回避できる。 |
Collaboraの24.04マニュアルによると、公開されているDockerイメージには証明鍵ペアが含まれていないため、生成して永続的にマウントする必要があります。公式のHelmチャートは証明鍵Secretをサポートしています。レプリカごとに個別のペアを生成しないでください。負荷分散によって障害が断続的に発生する可能性があります。
キーペアを安全に点検・修理する
- 設定済みのキーパスを探してください。Collaboraホスト上またはコンテナ内で、
coolwsd.xmlproof-keyパスの設定を確認し、秘密鍵と公開鍵の両方が利用可能かどうかを確認してください。一般的な場所は です/etc/coolwsd/が、パッケージやコンテナのレイアウトによって異なる場合があります。秘密鍵をログ、チケット、チャットに貼り付けないでください。 - キーが一致していることを確認してください。一般的なデフォルトパスの場合、秘密鍵を表示せずにフィンガープリントを比較します。
sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumとopenssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum。結果として得られるハッシュは一致するはずです。パスが異なる場合は、実際に設定されているパスに置き換えてください。秘密鍵が読み取れない場合は、サービスのセキュリティモデルに従って所有権と権限を修正してください。誰でも読み取れるようにしないでください。 - 必要な場合にのみ再生成してください。秘密鍵がない場合、またはペアが一致しない場合は、
sudo coolconfig generate-proof-keyそのユーティリティがインストールされている場所で使用してください。Docker の場合は、適切な永続的な場所にペアを生成し、Collabora が想定する場所に両方のファイルをマウントして、coolwsd プロセスが秘密鍵を読み取れることを確認してください。管理対象プラットフォームでは、実行中のポッドを手動で編集する代わりに、サポートされている Secret メカニズムを使用してください。 - すべてのインスタンスの一貫性を確保します。レプリカの場合、各インスタンスに同じキーペアをデプロイし、Collaboraを再起動または展開してファイルを読み込めるようにします。その後、ストレージホストでサポートされているメカニズムを使用して、WOPI検出を更新または再取得します。キーローテーションによって公開キーが変更されますが、キャッシュまたは以前のキーを使用している別のレプリカによって障害発生時にもサービスが維持される可能性があります。
キーが一致しても証明検証が失敗する
両システムの時刻同期を確認してください。WOPI の証明要求にはタイムスタンプが含まれます。ホストは古いタイムスタンプや期間外のタイムスタンプを拒否できます。NTP またはプラットフォームの時刻サービスが正常に動作していること、およびサーバーが妥当な UTC 時刻を報告していることを確認してください。時計の問題を回避するためにタイムスタンプのチェックを緩めないでください。
次に、ホストが署名付きリクエストを再構築するために使用する公開URLを調べます。証明は、関連するクエリパラメータを含むリクエストURLに紐づいており、WOPI仕様では、検証に使用されるURL表現が署名済みフォームと一致することが求められています。HTTPSを終端するリバースプロキシを使用すると、Collaboraが公開HTTPS URLに署名した場合でも、アプリケーションは内部HTTP URLを参照する可能性があります。信頼できるプロキシヘッダーとアプリケーションの外部URL設定は、WOPIホストの公式ガイダンスに従って構成してください。証明ロジックを書き換えたり、クエリパラメータを削除したりしないでください。
証明がキーローテーション後にのみ失敗する場合は、検出を更新し、すべての Collabora レプリカが同じ公開キーを公開していることを確認してください。1 つのプロキシまたは 1 つのレプリカを経由するリクエストのみが失敗する場合は、キーを再度ローテーションするのではなく、そのパスのログと構成を比較してください。証明検証を無効にするとセキュリティチェックが弱まる可能性があるため、本番環境での修正には使用しないでください。
修理を確認する
- ストレージホストのネットワークからCollaboraの検出エンドポイントを取得し、最新の証明鍵メタデータが返されることを確認します。
- テスト文書を開き、ストレージホストがCheckFileInfoリクエストとそれに続く文書リクエストを、無効性エラーなしで受け入れることを確認してください。
- 各プロキシルートまたはレプリカに対してこの手順を繰り返し、コンテナの再起動またはポッドの交換後もキーペアがマウントされたままであることを確認します。
ドキュメントのオープンが成功した場合、そのパスのみが検証されます。運用している各WOPIホストおよびプロキシルートに対して、このチェックを繰り返してください。
公式資料
Collabora Onlineのフォントサイズドロップダウンの表示ミスを修正する
ブラウザのズームをリセットし、クリーンなセッションをテストし、サイズが不正なメニューにCollaboraサーバーのアップデートが必要なタイミングを特定します。
Nextcloudをセルフホスト型のCollabora CODEコンテナに接続する
Collabora CODEをDockerでデプロイし、Nextcloud Officeに安全に接続し、実用的なWOPIおよびプロキシチェックでドキュメント編集を検証します。
coolwsdログを使用してCollabora接続障害を追跡する
一時的にcoolwsdをデバッグモードに上げ、オープンに失敗したログを1つキャプチャし、ログシーケンスを使用してWebSocket、WOPI、プロキシ、およびコンテナの問題を分離します。
Collabora管理コンソールに安全なパスワードを設定する
Collabora OnlineのDockerまたはLinux用の管理者ログインを設定し、適切なサービスを再起動し、新しいパスワードを公開せずに検証してください。
Collaboraのcoolwsdまたはloolwsdを使用してCPU使用率が高い場合の診断を行う
Collaboraの設定を変更したりサービスを再起動したりする前に、CPU負荷の原因がアクティブなドキュメント、アイドル状態のワーカープロセス、またはサーバー容量のいずれにあるかを確認してください。
推測せずにCODEコンテナのメモリ上限を引き上げる
DockerがCollabora CODEのメモリ使用量を制限しているかどうかを確認し、Composeのメモリ制限を安全に引き上げ、実行中のコンテナが新しい制限値を受け入れたことを確認します。
Collabora CODEのツールバーをソースコードを編集せずにカスタマイズする方法
Collabora CODEをコンパクトモードまたはタブモードとWOPI PostMessageコントロールで簡素化し、選択したボタン、コマンド、タブを安全に非表示にできます。
Collabora CODEをTLS終端処理付きでNginxの背後で実行する
Collabora CODEコンテナのHTTPSをNginxに任せ、WebSocketのフォワード編集を正しく行い、ポート9980を公開せずにパブリックエンドポイントを検証します。
Collaboraモバイルキーボードを開いたときにテキストを表示したままにする
Collabora Onlineでモバイルブラウザのキーボードがテキストを覆い隠してしまう問題のトラブルシューティング。ブラウザ、埋め込みWebView、ホストページそれぞれについて、迅速な回避策と個別のチェック方法を紹介します。