SSTP 証明書の不一致：サーバーが提示すべき名前

SSTP クライアントは TLS 検証が成功した後にだけサーバーを受け入れ、その検査は名前・チェーン・用途を比較します。名前は接続プロファイルから来るのであって、たまたま ping が通るアドレスからではありません。三つのうち一つでも一致しなければ、クライアントは証明書の問題を報告し、ログインのプロンプトまで到達しません。

プロファイルの名前が検査対象を決める

SSTP は TCP 443 上で TLS を実行するため、クライアントは他の TLS クライアントと同じように振る舞い、プロファイルからホスト名を取り、その名前を要求し、証明書をそれと比較します。プロファイルに IP アドレスを入力すると比較は IP アドレスの比較になり、ほとんどのサーバー証明書はそれを満たしません。

ブラウザーがプロファイルとは別の名前を使った結果、ブラウザーでの確認は成功しても VPN は失敗することがあります。同じ分裂は、split-horizon DNS が VPN のホスト名を内部アドレスに解決する一方、ブラウザーは公開アドレスに到達した場合にも現れます。まずプロファイルを文書化されたホスト名に合わせ、それから証明書を比較してください。その前に変えるものはすべて推測です。

サーバー証明書が備えるべきもの

現代のクライアントは subject alternative name 拡張と照合するため、ホスト名はそこに DNS エントリとして存在しなければなりません。common name だけでは現在の検証スタックに足りず、ワイルドカードは一つのラベルを覆うだけで、思いついた任意のサブドメインを覆うわけではありません。三つの証明書が境界を示します—正しい名前で用途が違うものは身元を検証した後に用途の検査で失敗し、正しい名前と用途でも中間証明書が欠けていればチェーンで失敗し、common name にしか現れない名前はそのどちらよりも前に失敗します。

証明書には、Microsoft の SSTP 仕様 に記された拡張鍵用途の値、すなわちオブジェクト識別子 1.3.6.1.5.5.7.3.1 を持つ serverAuth というサーバー認証の用途も必要です。鍵用途と有効なチェーンが集合を完成させます。サーバーに存在し、正しい名前で発行されていてもクライアント認証専用の証明書は、やはり失敗します。

認証情報より先にチェーンと時計を確認する

時刻と信頼の失敗 は名前の不一致と同じ見える結果を生み、どちらもパスワードの問題より安く診断できます。サーバーの時計とクライアントの時計を確認し、次にクライアントが見るままにチェーンを読みます:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

最初のコマンドは名前、有効期間、そしてクライアントが比較する代替名を出力します。二番目は提示されたチェーンとともに検証エラーを報告し、中間証明書の欠落はそこに現れます。Windows では時刻サービスの問い合わせが、時計が補正されているのか単にずれているのかを教えます。

内部 CA は、クライアントがその CA を信頼しているというもう一つの条件を加えます。組織のルートは承認された配布経路でインストールしてください—代替証明書を配るページからではなく、その判断こそが信頼モデルの縮図だからです。

サーバーの検証とユーザーの認証は別々の失敗を持つ連続した段階です。証明書エラーはクライアントがサーバーを信頼しなかったことを意味し、拒否されたパスワードはサーバーを信頼したが資格情報が違ったことを意味します。パスワードのプロンプトに到達するために証明書の検証を切るのは、保証を修復するのではなく取り除くことです。残りの経路が動くことを示すには、すでにチェーンを信頼しているクライアントから同じホスト名とポートを試し、配備済みのプロファイルはそのままにしてください。

名前か証明書を直してから再テストする

修復は三つの条件で決まります。プロファイルの名前が違うならプロファイルを直すか、欠けた名前を証明書に追加します。チェーンが不完全なら中間証明書をサーバーに入れます。用途が違うなら、その周りを継ぎ足すのではなく再発行します。

変更後は対応クライアントで再接続し、ログインのプロンプトが出ること、次にトンネルが上がることを確認します。使ったホスト名、発行者、有効期限をチケットに記録してください。その記録が次の更新を別の障害ではなく計画作業にし、三つの条件のどれが実際に壊れていたかを次の人に示します。