公式が「対応できない」と書いていた設定が、.htaccess で入った（ConoHa WING の HSTS）

自分のサイトに HSTS（HTTP Strict Transport Security）を入れようとして、公式サポートに「対応できない」と書いてあるのを見つけました。諦めかけたのですが、確かめたら入りました。

公式が間違っていたわけではありません。答えている問いが違っていたという話です。

公式サポートに「ご対応いただけない項目」と書いてある

ConoHa WING には「ネットde診断」というサーバー診断の機能があります。その説明ページに、こう書かれていました。

「セキュリティヘッダ "HTTP Strict Transport Security (HSTS)" の未設定」
これらの対策はサービスの性質上、お客様にご対応いただけない項目となります

診断で指摘される項目でありながら、対応できないものとして名指しされているわけです。

コントロールパネルも実際に見ました。

場所	中身
サイト設定 → 基本設定	Webフォント / 動作確認URL / エラーページ / サイト転送
サイト設定 → 応用設定	.htaccess 編集 / PHP設定 / ads.txt
サイトセキュリティ	独自SSL / WAF / ネットde診断 / ディレクトリアクセス制限 / IPアクセス制限

HSTS の専用項目はどこにもありません。ここまでは公式の記述どおりでした。

「専用設定が無い」と「設定できない」は別だった

ここで手が止まったのですが、応用設定に .htaccess 編集があるのが目に入りました。

HSTS はレスポンスヘッダを1つ送るだけの仕組みです。専用のスイッチが無いことと、ヘッダを送れないことは、同じではないかもしれない。

試したら入りました。

$ curl -sI https://example.com/

HTTP/2 301
server: nginx
strict-transport-security: max-age=63072000
location: https://sub.example.com/

公式は正確だった。答えている問いが違う

書かれていたことを、問いの形に戻すとこうなります。

問い	公式の答え
コントロールパネルに HSTS の設定項目があるか	無い（正確）
HSTS を設定できるか	答えていない

公式ドキュメントを書いた人は、コントロールパネルの機能一覧を見て書いたのだと思います。その範囲では正確です。ただ読む側には「不可能」と読めてしまう。

一次情報は推測より強いのですが、「正しい」ことと「自分の問いに答えている」ことは別だと感じました。

安全に試す手順

ここが実用部分です。HSTS は他の設定より戻しにくいので、いくつか順序があります。

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

短い設定ですが、4箇所に理由があります。

	なぜ
<IfModule> で囲む	mod_headers が無効だと構文エラーになり、サイトが 500 で落ちます。囲んでおけば、モジュールが無い環境では丸ごと無視されます
always を付ける	Header set（always 無し）は成功レスポンスにしか付きません。リダイレクト（3xx）を返すページには付かない
まず max-age=300	HSTS は非可逆に近い設定です。2年で送ってしまうと、証明書事故のときに2年間アクセスできません
includeSubDomains を書かない	書くと他のサブドメインを全部巻き込みます。同じドメイン配下に HTTPS 化していないものがあると止まります

always は自分の環境では必須でした。トップが 301 リダイレクトを返す構成だったので、always が無いと 3xx には付きません。

max-age=300 で1回確認してから2年（63072000）に伸ばしました。2回目は値を変えるだけなので、<IfModule> の書き方や always の要否はもう検証済みの状態で進められます。

触る前後で見たもの

.htaccess は既にリダイレクトのルールが入っているファイルでした。同じファイルを触るので、確認を3つ足しています。

• 編集前に md5 を取る — 追記のみで削除ゼロだったことを、後から数字で示せます。実際は削除0行 / 追加10行（370B → 1132B）でした
• 既存のリダイレクトが生きているか — mod_rewrite（301）と mod_headers（HSTS）は別モジュールなので影響しないはずですが、別モジュールだから大丈夫、で済ませずに1回叩きました
• 他のサブドメインに HSTS が付いていないか — includeSubDomains を書いていないことの確認です

3つ目まで見ておくと、includeSubDomains を書き忘れたのか、書かない判断をしたのかが後から区別できます。

「できない」と書かれていたら、何ができないのかを分解する

今回いちばん残ったのは、記述の読み方でした。

書かれ方	実際の意味かもしれないもの
「対応いただけません」	専用設定が無い（別の経路は生きている）
「サポート対象外」	動かないとは言っていない
「非推奨」	動く

調べても出てこなかったので諦める、の手前に、何ができないと書いてあるのかを分解する段階があったな、と思いました。ここを飛ばしていたら、同じ判断を次のサーバーでも繰り返していたはずです。