🤔

Apacheアップデート後に「421 Misdirected Request」が発生した話

に公開
Apache
nagios
RHEL
AlmaLinux
CVE
tech

はじめに

ある日、定例のOSアップデートを実施したところ、これまで正常だったNagiosのWebサイト監視が突然WARNINGになりました。

エラーメッセージを確認すると、そこには見慣れない「421 Misdirected Request」の文字が。

本記事では、このエラーの原因調査から解決までの道のりを備忘録としてまとめました。

何が起きたか？

  • 環境OS: Red Hat Enterprise Linux 8.10
  • Webサーバー: Apache (httpd)
    • アップデート後のバージョンhttpd-2.4.37-65.module+el8.10.0+23369+11a81384.5.x86_64
  • 監視ツール: Nagios

⚠️ 記事中のコマンド実行出力は、手元のAlmaLinux8.10で再確認した際のコマンド出力で掲載しています。

事象

dnf updateでApacheを含むいくつかのパッケージをアップデートした後、特定のHTTPSサイトに対するNagiosの監視（check_httpプラグインを使用）がWARNING状態になりました。

検知されたエラー内容は以下の通りです。

HTTP WARNING: HTTP/1.1 421 Misdirected Request

アップデート以外に設定変更は行っておらず、ブラウザから対象のWebサイトへは正常にアクセスできる状態でした。

調査の道のり

1. ログの確認

Apacheのエラーログを確認すると、どうやらSSL関係のエラーであることが分かりました。

ww.example.com-error.log
AH02032: Hostname localhost.localdomain (default host as no SNI was provided) and hostname www.example.com provided via HTTP have no compatible SSL setup

といっても、Apacheの設定は特に変更していない。

2. Apacheの変更点を追う

設定ファイルにも変更がないことから、原因はApacheのアップデートそのものにあると確信し、変更履歴を追うことにしました。

[root@alma8 ~]# rpm -q --changelog httpd | head
* Mon Jul 28 2025 Luboš Uhliarik <luhliari@redhat.com> - 2.4.37-65.5
- Resolves: RHEL-99944 - CVE-2025-49812 httpd: HTTP Session Hijack via a TLS upgrade
- Resolves: RHEL-99969 - CVE-2024-47252 httpd: insufficient escaping of
  user-supplied data in mod_ssl
- Resolves: RHEL-99961 - CVE-2025-23048 httpd: access control bypass by trusted
  clients is possible using TLS 1.3 session resumption

* Tue Apr 22 2025 Luboš Uhliarik <luhliari@redhat.com> - 2.4.37-65.4
- Resolves: RHEL-87641 - apache Bug 63192 - mod_ratelimit breaks HEAD requests

どうやら、今回のアップデートでSSLが絡みそうな脆弱性への対応が複数含まれていることがわかりました。

この脆弱性の対応とみられる、SNIによるバーチャルホスト選択と、その後のHTTPリクエストで指定されたホスト名とのSSL設定の互換性チェックに関するロジックが修正されたのが、どうやら関係していそうでした。

原因の核心

原因は、Apacheのセキュリティ強化と、それに追従できていなかったNagiosのcheck_httpプラグインの設定の組み合わせでした。

  • Apache側: SNIのホスト名とHostヘッダーのホスト名が一致しないリクエストを 421 エラーとして弾くようになった。
  • Nagios側: check_httpの実行時、SNIが適切に設定されていなかった。そのため、Apache側で不一致と判断されてしまった。

解決策

check_httpプラグインに、SNIで送信するホスト名を明示的に指定するオプションを追加することで解決しました。

具体的には、--sniオプションを追加します。

修正前のコマンド定義（イメージ）

check_http -S -I 192.0.2.1 -H www.example.com -u /healthz
  • -S: SSLで接続する。
  • -I: IPアドレス
  • -H: Hostヘッダーへの値
  • -u: URI
[root@alma8 ~]# /usr/lib64/nagios/plugins/check_http -S -I 127.0.1.1 -H www.example.com -u /healthz
HTTP WARNING: HTTP/1.1 421 Misdirected Request - 530 bytes in 0.004 second response time |time=0.004273s;;;0.000000 size=530B;;;0

修正後のコマンド定義

--sni を追加します。

check_http -S --sni -I 192.0.2.1 -H www.example.com -u /healthz

[root@alma8 ~]# check_http -S --sni -I 127.0.1.1 -H www.example.com -u /healthz
HTTP OK: HTTP/1.1 200 OK - 278 bytes in 0.004 second response time |time=0.004494s;;;0.000000 size=278B;;;0

この設定変更により、TLSハンドシェイク時に正しいホスト名がSNIとして送信されるようになり、Apacheのチェックをパスして、無事に監視が正常な状態（OK）に戻りました。

まとめ

今回は、Apacheのセキュリティアップデートに起因する監視エラーでした。一見するとWebサーバー側の問題に見えますが、実際にはクライアント（監視プラグイン）側の設定を見直すことで解決できました。

  • 監視ツールの仕様を正しく理解することが重要。 特にTLS/SSL関連のオプションは挙動を把握しておく必要がある
  • アップデート内容の確認は大事。 リリースノートやCVE情報を確認する習慣が、トラブルシューティングの近道になる。

日々の運用の中で発生した予期せぬエラーでしたが、Webサーバーとクライアント間の通信の仕組みを再確認する良い機会となりました。

この記事の調査過程は、Zennスクラップでも記録しています。

Discussion