サイトが誤った証明書を表示する？リスナーを特定しよう

WebホストにVPNソフトウェアをインストールするとサービス構成が変わり得るが、想定外の証明書はApacheのファイルが書き換えられた証拠ではない。何かがその証明書をあなたのブラウザに提示したのであり、最初の作業はそれを名指しすることだ。リスナーと仮想ホストを特定するまで、あらゆる修復は誤った層に適用した推測にすぎない。以下の確認はすべて読み取り専用である。

事実を集めて判断する間、再起動も削除も上書きもしない。

ブラウザが実際に受け取った証明書を読む

ホスト名、各アドレスファミリーで解決されたアドレス、ポート、そしてブラウザが警告した証明書の詳細を記録する。AとAAAAの両方に解決する名前は二つの異なるフロントエンドに到達し得て、シェルアクセスを持つホストはその一方だけかもしれない。プロキシの背後にあるブラウザはさらに第三の経路を取り得る。どれが警告を生んだかを推測すると、唯一の観測を無駄にする。

次に、同じ経路にあるマシンからハンドシェイクを再現し、アドレスを明示して意図したサーバー名を送ることで、応答は既定のホストではなくサイトを反映する。

openssl s_client -connect 198.51.100.37:443 -servername www.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -fingerprint -sha256 -ext subjectAltName

サブジェクトの代替名とフィンガープリントを、期待する証明書と突き合わせる。なじみのある発行者と比べてはいけない、サーバー名なしで裸のアドレスに接続すると既定の証明書が選ばれ得て、そのとき本当は問いが誤っているのに、誤ったファイルのように見える。

そのポートに結び付いたプロセスを特定する

接続を受けるべきホストでリスナーを一覧し、バインドアドレス、アドレスファミリー、プロセスの所有者を記録する。ループバックアドレスに結び付いたサービスは全インターフェースに結び付いたものとは異なり、コンテナの公開は公開リスナーをまったく別の場所に置き得る。

sudo ss -ltnp 'sport = :443'
sudo ss -ltnp | grep -E ':(443|943)\b'

TLSを手前のロードバランサーやプロキシが終端しているなら、ここで止め、代わりにそのフロントエンドを調べる。背後のApacheインスタンスは公開ブラウザに証明書を一切提示しないかもしれず、その設定を編集してもブラウザが見るものは変わらない。ソケットの見え方と外部のハンドシェイクが同じ経路を説明している必要があり、この比較がそれを確かめる。

ファイルより先に仮想ホストを突き合わせる

Apacheが終端側なら、そのアドレスと名前でどの仮想ホストが勝つかを尋ねる。制御コマンドは実効レイアウトを出力し、各ソケットに対応するグループ、宣言されたサーバー名、既定として扱われるホストが分かる。その答えなしに証明書ファイルを編集するのが、正しいファイルから誤ったサイトが配信される形である。

sudo apachectl -S

ApacheのSSLに関するFAQは、サーバー名表示が証明書をどう選ぶかを説明している。HTTPのHostヘッダーはハンドシェイクの後に届くため、すでに提示された内容を遡って変えることはできず、一致しない名前や欠けた名前は既定のホストに落ちる。

ServerAliasに打ち間違いがある名前付き仮想ホストはまさにこの症状を生み、先にすべてを拾うホストを読み込む二つ目の設定ファイルも同じだ。どちらもそのレイアウト一覧に見える。

主張するすべての経路で修正を検証する

承認された変更の後、各アドレスファミリーについてホスト名固有の確認を繰り返し、回避フラグではなくブラウザの通常の検証で終える。共有のリスナー設定に触れる前に別の管理経路を確保しておく、そこでの誤りは元に戻すためのアクセスを奪うからだ。その後、どのリスナーが応答し、どの仮想ホストが一致し、前後でどの証明書が配信されたかを書き留める。

パッケージの削除はレイアウトを変え、元の不一致を説明のつかないまま残し得るため、その記録は修復より長く残る。

望むのは、意図した入口で意図したサイトが応答することだ。無関係なサービスの消失後に別の証明書が出ても、ブラウザが警告をやめるとしても、それはその結果ではない。