Docker 内の ONLYOFFICE Docs の HTTPS を設定する

ONLYOFFICE Docsに直接接続するには、コンテナのポート443を公開し、証明書ファイルをマウントされたデータディレクトリの下に保存し、コンテナをそれらのファイルに向けてください。リバースプロキシが既にHTTPSを提供している場合は、デフォルトで2つ目のTLSエンドポイントを有効にするのではなく、そのプロキシでTLSを維持し、元のホストとプロトコルをONLYOFFICEに転送してください。

例えば、パブリックホスト名が の場合docs.example.com、まずそれがドキュメントサーバーを直接指しているのか、プロキシを指しているのかを判断します。以下の該当する設定のみを使用してください。

1. HTTPSの終了場所を決定する

TLSはHTTPSが復号される場所（ONLYOFFICEコンテナ内、またはリバースプロキシ内）で終端します。パブリック接続を受信するコンポーネントを選択してください。

• 直接アクセス：https://docs.example.comクライアントはホストのポート443に接続します。このポートはコンテナのポート443にマッピングされています。ドキュメントサーバーコンテナには証明書とそれに対応する秘密鍵が必要です。
• プロキシアクセス：クライアントはHTTPS経由でプロキシに接続し、プロキシは内部ネットワーク経由でドキュメントサーバーにトラフィックを転送します。この構成では、証明書は通常プロキシに配置されます。ONLYOFFICEのプロキシに関するガイダンスでは、アプリケーションが公開リクエストスキームとホスト名を識別できるように、X-Forwarded-Protoおよびヘッダーを指定しています。X-Forwarded-Host

ポートマッピングは443:443HTTPSを生成するものではなく、ポートをマッピングするだけです。直接アクセスするには、コンテナが証明書と秘密鍵も読み取る必要があります。プロキシがパブリックURLを所有している場合は、ONLYOFFICEの公式リバースプロキシ手順を参照してください。

2. Docker Composeで直接HTTPSを設定する

コンテナがHTTPSを直接提供する場合は、このパスを使用してください。パブリックアクセスには、クライアントが信頼する証明書をパブリックホスト名に使用してください。自己署名証明書でもトラフィックを暗号化できますが、クライアントが別途信頼するように設定されていない限り、IDに関する警告が表示されます。

ONLYOFFICE Docs は/var/www/onlyoffice/Data/certsデフォルトで以下の証明書を保存します。現在の Docker 構成ではtls.crt、tls.keyデフォルトの証明書およびキーのパスとして と が指定されています。ドキュメントの例では必ずしも同じファイル名が使用されているわけではないため、この例では両方のパスを明示的に設定しています。

services:
  documentserver:
    # Keep your existing image, environment, networks, and other settings.
    ports:
      - "443:443"
    volumes:
      - ./documentserver-data:/var/www/onlyoffice/Data
    environment:
      SSL_CERTIFICATE_PATH: /var/www/onlyoffice/Data/certs/tls.crt
      SSL_KEY_PATH: /var/www/onlyoffice/Data/certs/tls.key

これは抜粋であり、サービス定義の置き換えではありません。既存のイメージ、JWT、ネットワーク、およびボリューム設定は./documentserver-data/certs/tls.crtそのままにしてください。Compose ファイルからの相対パスで、証明書を に、対応するキーを に配置します./documentserver-data/certs/tls.key。プロバイダから提供された証明書チェーンを含め、証明書が をカバーしていることを確認してくださいdocs.example.com。

バインドマウントは、ファイルを交換可能なコンテナの外に保持します。コンテナが秘密鍵を読み取れるようにしつつ、秘密鍵へのアクセスを制限してください。そうしないと、HTTPSの起動に失敗する可能性があります。サポートリクエストで秘密鍵を共有しないでください。

3. デプロイメントを誤って置き換えることなく変更を適用する

1. Composeファイルと証明書ディレクトリをバックアップしてから、証明書とキーがパブリックホスト名と一致するペアであることを確認してください。
2. ポート、ボリューム、パスの変更は既存のサービスで行ってください。TLSを適用するために、同じホストポートで2つ目のコンテナを起動したり、既存のボリュームを破棄したりしないでください。
3. ポート、マウント、または環境を変更した場合は、サービスを再作成してください。Compose を使用する場合は、docker compose up -d documentserverCompose ファイルを含むディレクトリから実行し、実際のサービス名に置き換えてください。既にマウントされているディレクトリ内の証明書ファイルのみを置き換えた場合は、既存のコンテナを再起動して、サーバーがファイルを再読み込みするようにしますdocker restart <container_name>。
4. HTTPSが起動しない場合は、起動ログを確認してくださいdocker logs <container_name>。無関係な設定を変更する前に、ファイルが見つからない、権限がない、または証明書/キーのエラーがないか確認してください。

再起動ではマウントポイントの追加や公開ポートの変更はできません。これらの変更を行うには、サービスを再作成してください。既存の永続マウント内のファイルを置き換える場合、Compose の変更は不要です。

4. 既にドメインにサービスを提供しているリバースプロキシでTLSを維持する。

リバースプロキシが既に終端している場合はhttps://docs.example.com、その秘密鍵をプロキシに保管してください。制御されたネットワーク経由でトラフィックを転送し、X-Forwarded-Proto: httpsプラス記号X-Forwarded-Hostをパブリックホスト名に設定してください。プロキシソフトウェアの公式サンプルを使用してください。

ブラウザの鍵マークは、クライアントとプロキシ間の接続をカバーしますが、必ずしもすべての内部ホップをカバーするわけではありません。管理されたDockerネットワーク上のHTTPは、一部のデプロイメントに適している場合があります。信頼できないネットワークを経由する場合は、プロキシとコンテナ間のホップを保護してください。

もう一つの制限事項として、TLSを変更しても、無効なJWT、ブロックされたファイアウォールポート、または統合設定における誤った公開ドキュメントサーバーアドレスは修復されません。証明書が有効であるにもかかわらず、ドキュメントの読み込みや編集が失敗する場合は、証明書を繰り返し再生成するのではなく、関連するアプリケーションログとプロキシログを確認してください。

結果を確認する

パブリックサービスにアクセスできるクライアントから、https://docs.example.comブラウザの証明書の詳細を開いて確認してください。ホスト名が一致していること、証明書の有効期限内であること、ブラウザが信頼できない発行者や名前の不一致を報告していないことを確認してください。また、ターミナルからTLSハンドシェイクを検査することもできますcurl -Iv https://docs.example.com。ページが読み込まれるかどうかだけに頼るのではなく、証明書と接続の出力を確認してください。

最後に、統合アプリケーションからドキュメントを開きます。ブラウザが成功した場合、パブリックエンドポイントが正しく動作していることが確認されますが、すべての統合設定や内部ルートが正しく動作しているとは限りません。証明書の警告が表示された場合は、ホスト名、証明書チェーン、パス、権限、TLS終端を再確認してください。HTTPSが検証されても編集が失敗する場合は、ログと認証またはルーティング設定を確認してください。

サポートされている Docker パス、証明書変数、および組み込みの Let's Encrypt オプションの詳細については、ONLYOFFICE の Docker インストールおよび HTTPS ドキュメントを参照してください。既存のデプロイメントを更新するための正確なコマンドは、そのデプロイメントがどのように作成されたかによって異なります。関連する TLS の変更を適用しながら、そのデプロイメントの現在のボリュームと統合設定を保持してください。