NextcloudのStrict-Transport-Security（HSTS）ヘッダー欠落警告を修正する

Nextcloudが「Strict-Transport-Security HTTPヘッダーが設定されていません」と報告した場合、修正が必要なのはHTTPSレスポンスを提供するレイヤー（Apache、Nginx、またはTLSを終端するパブリックリバースプロキシ）です。Nextcloudの現在の管理マニュアルでは、ヘッダーの欠落または指定された秒数max-age未満の15552000接続をセキュリティ警告として示しています。パブリックHTTPSエンドポイントにヘッダーが設定されると、ブラウザはホストが指定された期間HTTPSを使用する必要があることを認識します。

基本的な変更は小さいですが、その範囲は重要です。HSTS は、有効な証明書を持つ動作中の HTTPS エンドポイントにのみ適用してください。最初はホストのみに適用し、影響を受けるすべてのホスト名が HTTPS に対応できる状態になってからincludeSubDomains、またはを追加してください。このガイドは、セキュリティ警告ガイダンスおよびサーバー強化ガイダンスpreloadを含め、2026 年 10 月に公開された Nextcloud 管理ドキュメントを反映しています。

警告の意味

HTTP Strict Transport Security (HSTS) は、ホスト名への今後のリクエストに HTTPS を使用するようブラウザに指示するレスポンス ヘッダーです。有効な HTTPS 接続でポリシーを受信した後に、ブラウザがプレーンテキストの HTTP にフォールバックするのを防ぐのに役立ちます。Nextcloud は公開レスポンスをチェックし、推奨される最小有効期間のポリシーが見つからない場合は警告を発します。

HSTSは、TLSの有効化やHTTPからHTTPSへのリダイレクトの代替手段ではありません。ブラウザはHTTPS経由で配信されたHSTSポリシーのみを受け入れます。初回アクセス時、ブラウザがポリシーを学習する前は、ホスト名がブラウザのプリロードリストに登録されていない限り、最初の要求は脆弱なままです。通常のHTTPからHTTPSへのリダイレクトは依然として有効ですが、ヘッダーを置き換えるものではありません。

どのサーバーがヘッダーを送信すべきかを調べます

設定を変更する前に、公開リクエストをトレースしてください。ユーザーがHTTPS経由でApacheまたはNginxに直接接続する場合は、そのWebサーバーのTLS仮想ホストを設定してください。ロードバランサー、イングレス、CDN、またはリバースプロキシが公開TLSを終端する場合は、ブラウザにレスポンスを送信するレイヤーを設定してください。内部HTTP接続にのみヘッダーを追加しても、公開レスポンスには影響しない場合があります。

Nextcloud は、リバースプロキシをサポートするデプロイメントパターンとして文書化しており、管理者は該当する場合に信頼できるプロキシを定義する必要があります。プロキシの HSTS の役割は、Nextcloud の URL およびクライアント IP の処理とは別個のものです。特に、overwriteprotocol一部のプロキシレイアウトでは、外部スキームを Nextcloud が認識するのに役立ちますが、これを設定しても HSTS レスポンス ヘッダーが追加されるわけではありません。アプリケーションが HTTP リンクを生成したり、プロキシ関連のその他の警告を報告したりする場合は、公式のNextcloud リバースプロキシ構成ガイドを参照してください。

ポリシーを変更する前に

• https://cloud.example.com証明書エラーなしでロードされ、意図した証明書チェーンが使用されることを確認します。
• HTTPリクエストがHTTPS経由で同じホスト名にリダイレクトされるかどうかを確認してください。
• 検討する前に、同じ親ドメインの下にある他のサービスとサブドメインを特定してくださいincludeSubDomains。
• 管理ルートまたはサーバーコンソールを常に利用できる状態にしておいてください。HSTSをキャッシュしているブラウザは、ポリシー期間中、ユーザーが証明書エラーを回避することを拒否します。

cloud.example.com例の部分を実際のNextcloudホスト名に置き換えてください。サンプルホスト名を本番環境の設定にコピーしないでください。

ApacheでHSTSを設定する

Nextcloud をホストする Apache TLS 仮想ホストで、ヘッダー モジュールを有効にし、ポリシーを追加します。Nextcloud のセキュリティ強化ガイドでは、6 か月という値を示し、 を使用していますincludeSubDomains。以下のホストのみのバージョンは、慎重な出発点となります。

<VirtualHost *:443>
    ServerName cloud.example.com

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>

    # Existing Nextcloud and TLS directives
</VirtualHost>

ディストリビューションの Apache 設定で が有効になっていることを確認してくださいmod_headers。ディレクティブは、ポート 80 の仮想ホストではなく、HTTPS 仮想ホストに追加してください。インストールされているディストリビューションに適したコマンドを使用して設定を検証し、サービスマネージャを使用して Apache をリロードしてください。たとえば、多くの systemd ベースのディストリビューションsudo apachectl configtestでは の後に が続きます。sudo systemctl reload apache2一部のディストリビューションでは、サービス名は ですhttpd。パッケージ名とサービス名に一致するコマンドを使用してください。

NginxでHSTSを設定する

serverHTTPSをリッスンし、公開Nextcloudホスト名を提供するNginxブロックに、以下を追加します。

server {
    listen 443 ssl;
    server_name cloud.example.com;

    add_header Strict-Transport-Security "max-age=15552000" always;

    # Existing certificate and Nextcloud configuration
}

このalwaysパラメータにより、Nginx はレスポンスの状態に関係なくヘッダーを追加します。Nginx のドキュメントには、オペレーターを驚かせる可能性のある継承ルールが記載add_headerされています。下位設定レベルのディレクティブは、通常の継承動作を変更します。ネストされたlocationブロックが独自のadd_headerディレクティブを定義している場合、サーバーレベルの HSTS ヘッダーはそこで継承されなくなる可能性があります。アクティブな設定を確認し、ログイン ページや静的リソースなどの代表的な URL をテストしてください。Nginxの公式ヘッダー モジュールのドキュメントを参照してください。

変更を適用する前に、 を実行してくださいsudo nginx -t。検証が成功した場合は、システムに応じたサービスコマンド（多くの場合 ）を使用して Nginx をリロードしてくださいsudo systemctl reload nginx。構文テストに失敗した場合は、リロードする前に修正する必要があります。

リバースプロキシまたはTLSターミネータを設定する

パブリックHTTPSがリバースプロキシで終了する場合、そのプロキシのHTTPSレスポンスにHSTSヘッダーを追加してください。たとえば、プロキシはNextcloudバックエンドへの接続にHTTPを使用している場合でも、HSTSヘッダーを送信する可能性があります。暗号化されていないバックエンドレスポンスにのみHSTSを送信し、ブラウザがそれを認識すると想定しないでください。

プロキシとバックエンドの両方で同じヘッダーが追加されているかどうかを確認してください。HSTSフィールドが重複していると診断が困難になる場合があり、プロキシがバックエンドのヘッダーを上書きまたは隠蔽する可能性があります。ポリシーを所有する公開レイヤーを1つ選択するか、ブラウザが明確な値を1つだけ受信するようにレイヤーを意図的に構成してください。プロキシを変更した後、期待どおりのホストとスキームがNextcloudに転送され、HTTPSリンクが引き続き機能することを確認してください。

世論の反応を確認する

ローカルホストやバックエンドアドレスだけでなく、公開されているHTTPSホスト名へのリクエストを使用してください。

curl -sSI https://cloud.example.com
curl -sSIL http://cloud.example.com

最初のレスポンスで、次のようなヘッダーを1つだけ探してください。

Strict-Transport-Security: max-age=15552000

2番目のコマンドはリダイレクトを追跡します。HTTP URLが目的のHTTPSホスト名に到達していることを確認し、HTTPSレスポンスでHSTSを調べます。ブラウザは通常のHTTPで受信したHSTSを無視するため、最初のポート80リダイレクトではヘッダーを表示する必要はありません。ブラウザの開発者ツールを使用することもできます。ネットワークパネルを開き、HTTPSページを再読み込みし、ドキュメントレスポンスを選択して、レスポンスヘッダーを調べます。

構成にネストされたロケーション、複数のプロキシ階層、または個別の静的アセット処理がある場合は、複数の応答パスを確認してください。その後、Nextcloudの管理設定に戻り、セキュリティ概要を更新してください。警告の更新には時間がかかる場合や、Nextcloudがプローブする実際の公開URLが反映されている場合があるため、そのURLをテストしたURLと比較してください。

適用範囲と耐用年数を慎重に選択してください。

有効期間（秒）max-ageは155520006か月で、Nextcloudのドキュメントに記載されている警告しきい値と一致します。ポリシーは、ブラウザが新しい有効なHSTSヘッダーを受信すると更新されます。後でポリシーを短縮または削除するにはmax-age=0、影響を受ける各ホスト名にHTTPS経由で配信する必要があります。変更中に再訪問しないブラウザは、現在の有効期間が終了するまでキャッシュされたポリシーを保持します。

includeSubDomainsこのポリシーはホスト名配下のすべてのサブドメインに適用されます。現在および計画中のすべてのサブドメインが有効な証明書でHTTPSをサポートしている場合にのみ使用してください。準備が整っていない場合、別のサービス（例mail.example.com：）はブラウザからアクセスできなくなる可能性があります。legacy.example.com

トークンpreloadは、影響の大きい個別の決定事項です。Nextcloudのセキュリティ強化に関するガイダンスでは、ホスト名をブラウザのプリロードリストに追加する方法について説明しており、削除してもインストールされているブラウザに反映されるまでに数か月かかる場合があると警告しています。スキャナーの検出結果をすぐに解消するために追加しないでください。まず、必要なプリロード条件と各サブドメインへの影響をすべて確認してください。追加をリクエストする場合は、公式のHSTSプリロードサービスガイダンスに従ってください。

警告が続く場合

• curlにヘッダーがありません。仮想ホスト、プロキシ、またはNginxの場所を誤って編集した可能性があります。パブリックDNSターゲットとアクティブサーバーの設定を確認してください。
• ヘッダーが一部のページにのみ表示される場合は、ネストされたNginxadd_headerディレクティブ、エラー処理、静的アセットのパス、およびプロキシルールを確認してください。
• レスポンスには複数のポリシーがあります。どのレイヤーがフィールドを追加しているかを特定し、それらを1つの一貫した値に統合します。
• ヘッダーは存在しますが、警告が解消されない場合は、 Nextcloudの外部設定URLが同じHTTPSエンドポイントに解決されることを確認し、プロキシスキームの処理を確認してから、管理画面の概要を再読み込みしてください。
• HTTPSまたは証明書が準備できていません。まずTLSとHTTPからHTTPSへのルーティングを修正してください。HSTSは、破損した証明書を修復したり、HTTPSを有効にしたりすることはできません。

パブリックHTTPSレスポンスに意図したHSTS値が常に含まれ、NextcloudがパブリックHTTPS URLに正しくアクセスでき、ブラウザが証明書エラーやリダイレクトエラーなしでインスタンスを読み込めるようになれば、修正は完了です。HSTSは、再訪問するブラウザに対するトランスポートポリシーの適用性を向上させますが、証明書の保守、セキュアプロキシの設定、またはテスト済みの復旧パスに取って代わるものではありません。