今回は、ウェブサイトで SSL を強制する方法をご紹介いたします。つまり、すべてのユーザーの HTTP リクエストを対応する HTTPS にリダイレクトする方法です。

HTTP リクエストをリダイレクトするページルールの作成

いつものように、OpenResty Edge の Admin Web コンソールにアクセスしましょう。これはコンソールのサンプルデプロイメントです。各ユーザーには独自のローカルデプロイメントがあります。

今回も test-edge.com ドメインのサンプルアプリケーションを使用します。

test-edge.com ドメインで絞り込んだ OpenResty Edge のアプリケーション一覧

このアプリケーションに移動します。

OpenResty Edge で test-edge.com アプリケーションを開く

次に、ページルールのページに移動します。

インストール済みの SSL 証明書とページルールへの入口を示すアプリケーション概要

新しいページルールを作成します。

test-edge.com アプリケーションに新しいページルールを作成する

すべての HTTP リクエストに対してルール条件を有効にします。

すべての HTTP リクエストにマッチするルール条件を有効にする

まず、選択可能なすべての変数を確認しましょう。

OpenResty Edge のページルールで選択できる条件変数の一覧

Scheme を選択します。

ページルールの条件として Scheme 変数を選択する

文字列等号演算子はそのままにしておきます。

Scheme 条件の文字列等号演算子をそのまま使う

次に、値として http を選択します。

Scheme 条件の値として http を設定する

Scheme 条件値のドロップダウンで http を選択し HTTP リクエストのみにマッチさせる

これで条件が完成しました。すべての HTTP リクエストにマッチし、HTTPS リクエストは除外されます。

次に、ルールのアクション部分では、301 リダイレクトアクションを設定できます。

HTTP から HTTPS へのリダイレクトルールのアクション部分を設定する

ここには多くのアクションがあります。

OpenResty Edge のページルールアクションの一覧

そのため、Redirect アクションを直接検索するのが最適です。

ページルールアクションの中から Redirect アクションを検索する

これを選択します。

ページルールに Redirect アクションを選択する

現在のリクエスト URI はそのままにしておきます。

リダイレクト先で現在のリクエスト URI を保持する

また、現在のリクエストの URI パラメータまたはクエリ文字列も引き継ぎます。

リダイレクトで現在のリクエストの URI パラメータとクエリ文字列を引き継ぐ

ただし、新しいリクエストのスキームは変更する必要があります。

リダイレクト先のリクエストスキームを変更する

https を選択します。

リダイレクト先のスキームとして https を選択する

ここで 301 リダイレクトを代わりに選択できます。

Redirect アクションのステータスコードが既定の 302 Moved Temporarily になっている

これは「永続的リダイレクト」を意味します。

ステータスコードのドロップダウンで HTTPS リダイレクト用に 301 Moved Permanently を選択する

このルールが既存の通常ルールの前に実行されるようにする必要があります。

リダイレクトルールを既存の通常ページルールの前に挿入する

このルールがマッチした場合、後続のルールをスキップするようにします。

ルールの並び順オプションと後続ページルールをスキップするチェックボックス

このルールに関しては実際には必要ありませんが、リクエストの処理を即座に停止したい場合は、明示的に指定することが常に良い方法です。

これでルールを作成します。

HTTP から HTTPS へのリダイレクトページルールを作成する

ここで、すべての HTTP リクエストを対応する HTTPS リクエストにリダイレクトする新しいページルールが表示されます。

Scheme is http 条件がステータスコード 301 で HTTPS にリダイレクトすることを示すページルール一覧

いつものように、この新しいページルールをプッシュするにはリリースする必要があります。

ゲートウェイクラスターへのリリースを待つ保留中の変更

このボタンをクリックします。

リダイレクトページルールを配信する新しいリリースを開始する

リリースします!

HTTP から HTTPS へのリダイレクトルールのリリースを確定する

完全に同期されました。

リリースがゲートウェイサーバーに完全に同期された状態

これで、新しいページルールがすべてのゲートウェイクラスターとサーバーにプッシュされました。

リダイレクトページルールがすべてのゲートウェイクラスターとサーバーに配信された状態

この設定変更では、サーバーのリロード、再起動、またはサーバープロセスのバイナリアップグレードは必要ありません。そのため、非常に効率的でスケーラブルです。

設定変更が再読み込みや再起動なしでゲートウェイサーバーに反映される様子

ページルールのテスト

新しいブラウザのタブを開き、HTTP で test-edge.com ウェブサイトにアクセスしてみましょう。

実際に HTTPS に変更されていたことがわかります。ブラウザのアドレスバーの小さな鍵アイコンに注目してください。

ターミナルでも curl を使用してテストできます。

curl -Ss -I http://test-edge.com/

確かに 301 リダイレクトで、HTTPS プロトコルを使用しています。

HTTP/1.1 301 Moved Permanently と https://test-edge.com/ を指す Location ヘッダーを示す curl の出力

より複雑な URI とクエリ文字列も試してみましょう。

curl -Ss -I 'http://test-edge.com/foo/bar?a=32&b=56'

依然として HTTPS にリダイレクトされていることがわかります。

パスとクエリ文字列を含む HTTP URL への curl リクエストがリダイレクトを返す

また、URI とクエリ文字列も保持されています。

リダイレクトの Location ヘッダーが HTTPS で元の URI とクエリ文字列を保持している

よくある質問

HTTP から HTTPS へのリダイレクトは 301 と 302 のどちらを使うべきですか?

OpenResty Edge の Redirect アクションは既定で 302(Moved Temporarily) になっており、ステータスコードのドロップダウンには 301、303、307 も用意されています。HTTPS を強制する場合は 301(Moved Permanently) に変更してください。サイトを HTTP から HTTPS へ移すのは一時的な変更ではなく恒久的な変更なので、永続的リダイレクトが正しい表現です。

リダイレクトは元の URI とクエリ文字列を保持しますか?

はい。Redirect アクションで URIURI argumentscurrent のままにし、Scheme だけを https に変更します。すると http://test-edge.com/foo/bar?a=32&b=56 は HTTPS の同じパスとクエリ文字列にリダイレクトされます。本記事の curl -Ss -I テストでも、Location ヘッダーが両方をそのまま引き継いでいることが確認できます。

このルールは HTTPS リクエストもリダイレクトしますか?

いいえ。ルール条件は Scheme 変数を http と文字列等価で判定するため、すべての HTTP リクエストにマッチし、HTTPS リクエストは除外されます。すでに HTTPS で到達したリクエストは条件にマッチせず、通常のルールにそのまま渡されます。

リダイレクトを適用するにはゲートウェイの再起動や再読み込みが必要ですか?

いいえ。ルールを作成したあと新しいリリースを行えば、ルールはすべてのゲートウェイクラスターとサーバーにプッシュされます。OpenResty Edge の設定変更はサーバーの再読み込み、再起動、バイナリアップグレードを必要としません。これが大規模なクラスターにリダイレクトを展開しても効率的である理由です。

なぜこのリダイレクトルールを他のページルールより前に実行すべきなのですか?

既存の通常ルールより前に配置し、マッチした際に後続のルールをスキップするかどうかを決めます。このルールに関しては必須ではありませんが、リクエストの処理を即座に停止したい場合は、明示的に指定することが常に良い方法です。

著者について

章亦春(Zhang Yichun)は、オープンソースの OpenResty® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春(GitHub ID: agentzh)は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」 の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール)と OpenResty Edge(マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア)は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJITGDBSystemTapLLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。

翻訳

英文版の原文と日本語訳版(本文)をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます!