AnyConnect の信頼できないサーバー警告：受け入れるか、インポートするか

AnyConnect にゲートウェイのホスト名を貼り付けると、ウィンドウが赤か白になり、クライアントが証明書を検証できないサーバーを信頼するかどうかをダイアログが尋ねます。ついクリックして作業を続けたくなりますが、それはまさに間違った反射です。答えはその端末のクライアント設定に書き込まれ、以降の接続にも適用されます。つまりこのダイアログは、一度きりの警告の衣装を着た構成上の判断です。クライアントが表示する順序どおりに、私がたどる手順を示します。

実際に見えている警告から始める

赤と白は見た目の違いではありません。赤い警告は、プロファイルまたは設定が信頼できないサーバーをブロックするように設定されているという意味で、その設定が変わるまでクライアントは続行を拒否します。白い警告は、明示的に答えれば続行を許可するという意味です。よく似て見えるのに振る舞いが違う第三のケースがあります。期限切れの証明書で、これはインポートしても有効にならないため、クライアントはインポートを一切提案しません。この三つを切り分けるのに一秒かかり、その後のすべてが決まります。

そのすべての背後には短い原因の一覧があります。自己署名のゲートウェイ証明書、エンドポイントが信頼していないプライベート CA、または証明書の subject alternative names に欠けているホスト名です。どれも同じダイアログを出し、それぞれ別の対処を必要とします。

ダイアログに答える前に証明書を読む

警告から証明書の詳細を開き、ボタンに触れる前に三つの項目を見ます。subject と SAN は本当に到達したいゲートウェイを示しているべきで、発行者は組織が運用する CA であるべきで、有効期間は今日を含むべきです。次に SHA-256 の指紋を、この接続とは別の場所で入手した控え、社内ドキュメントのページやチケットと照合します。同じダイアログから読んだ指紋は何も証明しないからです。独立した控えが見つからないなら、例外を受け入れる根拠はありません。

これが実験環境と本番ゲートウェイを分ける手順です。昨日作った自己署名証明書の試験機なら、クリックして進むのは妥当です。利用者がこの後で認証情報を入力する社内ゲートウェイでは、検証できない証明書は傍受の仕掛けである可能性があり、まだ問いを立てているのはクライアントだけです。

それぞれの答えが信頼ストアに何を書くかを知る

インポートの問いに「はい」と答えると、その端末のクライアントの信頼ストアにゲートウェイの証明書が追加されます。セッションごとの例外ではありません。以降の接続は同じ問いなしで完了でき、それが狙いであり同時に危険でもあります。画面のどこにも、例外が存在することを誰かに思い出させないからです。「いいえ」と答えれば、ログインはこのセッションだけ続きます。どちらの道でも接続はできますが、端末を変えるのは片方だけです。

赤い道にいる場合、最初の試行はログインですらありません。文書化されている入力順は connect の行と二つの確認で、設定を変えて終了します。これを成功とみなすスクリプトは設定を保存しただけで、認証は一度もしていません。証明書のインポートの問いは次の試行で初めて現れます。だから人々はこの問いが不定期だと結論づけるのです。

この順序は指だけでなく自動化にとっても重要です。常にはいと答えるスクリプトの応答は、ゲートウェイが変わった後も動き続け、次に現れる証明書をそのまま信頼し続けます。

クライアントが尋ねる順に答えを書く

クライアントが警告しつつ接続を許可する場合、答えは決まった順で来ます。connect、続行するためのはい、次にインポートの問い、次にグループ、ユーザー名、パスワードです。問いのタイミングを推測するのではなく、入力ファイルに別々の行として書きます。インポートを断るのは同じファイルの一文字の変更で、無人で動くものにとってはより安全な既定値です。

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

組織の CA をエンドポイントに配布するほうが、すべてのスクリプトにリーフ証明書を受け入れるよう教えるより望ましい方法です。正しい SAN を持つ適切に発行された証明書は、全員にとって問いをなくし、検証の意味を保ち、一つのエンドポイントの記憶に依存しません。ルート CA の導入はリーフのインポートより重い変更なので、ヘルプデスクの近道ではなく管理された展開として扱ってください。

ゲートウェイより長生きする例外を片づける

AnyConnect はこれらの設定を端末ごとに保存するため、拠点を移ったノート PC には古い答えがたまります。管理対象のエンドポイントで保存された設定とインポートされた証明書を見直し、所有者が変わったホスト名を例外がまだ指していないか確認します。あらゆる信頼できないサーバーを受け入れる設定は、それが作られた証明書より広い範囲を持ちます。

残す価値のある型は狭いものです。通常利用のための信頼された証明書、一時的な例外のための文書化された帯域外の指紋確認、移行が終わったらそれを外す名前のある担当者です。管理している端末で、どのサーバーでも受け入れる包括的な設定を見つけたら、便利さではなく発見として扱ってください。