SafeLine WAF で HTTPS サイトの SSL 証明書を扱う：設定チェックリストとトラブルシューティング

SafeLine WAF で HTTPS サイトの証明書まわりを設定する、という検索意図に答えるため、まず公式ドキュメントに何が書いてあるかを整理します。

SafeLine は Web アプリケーションの手前に置かれて HTTP トラフィックを検査する、自己ホスト型の WAF です。クライアントは最初にこの WAF へ到達し、ポリシーが許可した通信だけがオリジンへ転送されます。これはリバースプロキシとしての動作です（https://docs.waf.chaitin.com/en/home）。製品紹介には、SQL インジェクション、XSS、コードインジェクション、OS コマンドインジェクション、CRLF インジェクション、LDAP インジェクション、XPath インジェクション、RCE、XXE、SSRF、パストラバーサル、バックドア、ブルートフォース、HTTP フラッド、ボット攻撃への防御が列挙されています。さらに、ボット悪用のプロアクティブ防御、HTML/JavaScript のコード暗号化、IP ベースのレート制限、Web アクセス制御リストも挙げられています。ただし、どの説明にも証明書の保存方法は含まれていません。

アプリケーション追加のガイドでは、SafeLine は nginx を基盤として開発された WAF であり、元の Web サイトへのトラフィックを受け取り、悪意のある攻撃トラフィックを除去し、安全なトラフィックを元のアプリケーションへ転送すると説明されています（https://docs.waf.chaitin.com/en/GetStarted/AddApplication）。入力項目として明記されているのは Domain、Port、Upstream の 3 つです。Domain にはドメイン名、ホスト名、または IP アドレスを指定できます。Port は SafeLine が待ち受けるポートで、例として 80 と 443 が挙げられています。HTTPS アプリの場合は「SSL オプションにチェックを入れる」という注意書きが、これらの資料に含まれる HTTPS 証明書に関する記述のすべてです。Upstream は元のアプリの実際のアドレスです。

つまり、証明書アップロードの手順はドキュメントに存在しないため、画面上で探し始める前に「この設定で運用要件を満たせるか」を判断する必要があります。

次に、番号付きで導入とアプリケーション設定の手順を示します。

1. ホストが製品要件を満たすことを確認します。Linux、x86_64 または arm64、Docker 20.10.14 以上、Docker Compose 2.0.0 以上、CPU 1 コア以上、メモリ 1GB 以上、ディスク 5GB 以上、そして ssse3 命令を持つ CPU が必要です（https://docs.waf.chaitin.com/en/GetStarted/Deploy）。確認コマンドは、uname -m、docker version、docker compose version、/proc/cpuinfo のプロセッサ情報の grep、free -h、df -h、ssse3 で絞り込む lscpu です。

2. ドキュメントに記載された方法でのみインストールします。推奨は自動デプロイで、root が必要です。デプロイページのコマンドは次のとおりです。

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

完了後、Web コンソールへアクセスします。手動デプロイでは、必要に応じて Docker を導入し、/data/safeline を作成して compose.yaml をダウンロードし、.env を書き込み、ドキュメントに記載された検出用トークンと管理用トークン、16 文字の英数字の検出用 AES キーを生成し、権限を制限し、ガイドに記載されたリソースディレクトリを作成し、ランタイムソケットをリンクして、docker compose up -d でスタックを起動します。ARM サーバでは ARCH_SUFFIX を -arm に設定し、ガイド記載の ARM 用 Postgres イメージを使用します。なお、ARM にインストールした SafeLine は Pro ライセンスが必要で、Personal Edition は ARM ではサポートされないとデプロイページに明記されています。これはプラットフォームに関する注意であり、証明書アップロードとは無関係です。

1. コンソールを開き、最初の管理者を作成します。https://:9443/ にアクセスし、docker exec safeline-mgt resetadmin を実行します。表示される初期ユーザ名とパスワードを保存してログインします。ポート 9443 のコンソール TLS を公開サイト用の証明書と混同しないでください。ドキュメントには、管理ポートの証明書がアプリケーションのリスナーで再利用されるとは書かれていません。

2. 3 つの項目でアプリケーションを追加します。Applications ページで Add Application を選び、Domain に公開ホスト名を入力し、SafeLine に待ち受けさせたいポートとして HTTPS サイトなら 443 を入力し、対象が HTTPS アプリである場合にのみ SSL オプションにチェックを入れます。Upstream にオリジンのアドレスを入力します。ここで証明書アップロード欄を探してもコンソールに見つからない場合は、そこで停止してください。これらの資料は、回避策やカスタム nginx スニペット、鍵のボリュームマウントを許可していません。

3. アプリケーションエントリが存在してから名前解決を変更します。入力したドメインを SafeLine サーバの IP に解決し、その名前でサイトへ到達します。DNS がまだオリジンを向いていると、クライアントはリバースプロキシを通らないため、SSL オプションは経路を変えられません。

4. 証明書の思い込みではなく、公開されているテストケースで検査を証明します。アプリケーションガイドには SQL インジェクション、XSS、パストラバーサル、コードインジェクション、XXE のサンプルクエリがあり、ブロックページが表示されたら攻撃が防御されたことを意味します。また、Web コンソールの攻撃一覧を開き、イベントの詳細をクリックして確認するよう書かれています。ブラウザの鍵アイコンだけでは、この攻撃一覧の確認の代わりになりません。

設定前のチェックリスト

識別子: Domain の値がクライアントの要求するホスト名と一致しているか。ドキュメントはドメイン名、ホスト名、IP アドレスを許可しますが、HTTPS のホスト名と IP リスナーは運用上の選択が異なります。SSL オプションが一方を他方へ書き換えるとは考えないでください。

リスナー: Port は SafeLine が待ち受けるポートです。443 は通常の HTTPS サイトに合う例です。HTTPS アプリに対して SSL オプションにチェックを入れることはドキュメントに記載されていますが、PEM ファイルのアップロード、チェーンの選択、パスフレーズの設定は記載されていません。

オリジン: Upstream は SafeLine がクリーンなトラフィックを転送する先です。2 つ目の公開リスナーではありません。SafeLine ホストから到達可能にしておいてください。

切り替え: アプリケーション保存後に DNS が SafeLine サーバを向く必要があります。新しいレコードが見えるリゾルバからテストしてください。

スコープ: レート制限、CAPTCHA、認証チャレンジ、動的保護は製品紹介では別機能です。証明書ワークフローが無いことの代用として有効化せず、これらのページがすべてのトグルを説明しているとも考えないでください。

証跡: 切り替え後にドキュメント記載の攻撃サンプルを 1 つ実行し、ブロックページと攻撃一覧の詳細表示を確認してください。リクエストが SafeLine に届いていなければ、証明書設定を探す前に DNS またはリスナーを修正してください。

具体的な誤設定と修正

よくある誤設定は「SSL オプションにチェックを入れたのに、DNS がオリジンを向いたまま」という状態です。アプリケーションを保存しても、ドメインの解決先が SafeLine サーバでなければ、クライアントの HTTPS 通信はオリジンへ直行し、WAF のリスナーも SSL オプションも経路に一切関与しません。結果として、設定したはずの検査が働かず、攻撃もブロックされません。

修正は、入力したドメインを SafeLine サーバの IP に解決させ、その名前でサイトへアクセスし直すことです。新しい DNS レコードが見えるリゾルバからテストしてください。

修正を確認する画面とログ

修正後は、アプリケーションガイド記載のサンプルクエリ（たとえば SQL インジェクションやパストラバーサル）を URL に付けてリクエストします。ブロックページが表示されれば、リクエストが SafeLine を通過し、攻撃が防御されたことになります。さらに、Web コンソールの攻撃一覧を開き、該当イベントの詳細をクリックします。この詳細画面にイベントが記録されていることこそ、WAF が実際にリクエスト経路上にあることの確認です。ポート 9443 の管理コンソールにログインできることや、ブラウザに鍵アイコンが表示されることは、この確認の代わりにはなりません。

まとめ

SafeLine のこれらの資料が定義する HTTPS 対応の範囲は「HTTPS アプリでは SSL オプションにチェックする」ことです。証明書のアップロード画面や更新フローは記載されていないため、運用で名前付きのアップロード操作、鍵のエクスポート、自動更新が必須なら、本記事の 3 ページだけでは設計を承認できません。不足している手順は本番切り替え前に最新の公式ドキュメントで確認してください。それまでは、正しく導入されたリバースプロキシ、Domain・Port・Upstream と HTTPS アプリ向けの SSL オプションを設定したアプリケーションエントリ、SafeLine ホストへ向けた DNS、そして攻撃一覧でのブロック確認が、ドキュメントに沿った成果です。

---

• Demo: https://demo.waf.chaitin.com:9443/statistics
• Official docs: https://docs.waf.chaitin.com/en/home
• GitHub: https://github.com/chaitin/SafeLine