証明書を交換した後、OpenConnect がゲートウェイを拒否するのはなぜですか？
ゲートウェイの証明書を交換した後の検証失敗は、壊れたトンネルではなく信頼の判断です。発行元 CA と単一鍵の pin 留めのどちらかを選びます。
ゲートウェイは証明書を交換し、昨日まで接続できていたクライアントが最初の TLS 交換で止まり始める。メッセージはネットワーク障害ではなく検証の理由を挙げており、マシン自体が変わっていないことが有用な手がかりだ。壊れたのは、いま提示されている証明書と、クライアントが受け入れてよいと考えるルートとの関係である。これを直すのは信頼の判断なので、オプションを入力する前にその判断を下す。
信頼設定を変える前に失敗を読む
署名者が見つからないという種類のエラーは、チェーンがクライアントの受け入れない何かで終わっていることを意味する。内部認証局が更新した証明書、公開認証局からの差し替え、あるいは中間にいる機器が自分の証明書を提示している可能性がある。 文言だけではそのどれかを区別できない、だから決める前に発行者を見る。
接続を一度は前面で実行して失敗させる、対話的な出力にサーバー名、発行者チェーン、クライアントが計算したフィンガープリントが含まれるからだ。その発行者を、あなたの組織が実際に運用する認証局と比べる。発行者が同じままフィンガープリントが変わったなら、すでに信頼している経路で更新が確認できるまで疑わしいものとして扱う。この時点で推測するのは、結局は傍受者の鍵を固定してしまう道である。
同じメモにクライアントのバージョンを書く。信頼の問題に見える失敗の多くは、古いクライアントが新しいゲートウェイの交換に出会うことから来る。
発行者を信頼するか、一つの鍵を固定するかを選ぶ
どちらの選択肢でも接続は成功する。後になって逆の形で壊れるので、選ぶのは自分が許容できる失敗のほうだ。
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
証明書が独立に検証できる認証局から来ているなら、更新がクライアントの引数に触れずに機能し続けるのだから、CA ファイルに手を伸ばす。システムのルートを無効にするスイッチと組み合わせ、そうしないと公開認証局があなたの代わりに検査を満たしてしまう。代わりに固定するのは、ゲートウェイに入手できる CA がない場合や、可能な限り狭い例外が目的の場合だ。どちらの道も抽象的に安全なわけではない、というのも CA は更新をまたいで拡張でき、固定は見直しやすいからだ。
どちらを選んでも、信頼する値は変更が起きる前に信頼していた経路で届かなければならない。管理者、ゲートウェイ上のコンソールセッション、事前に取ったコピーのいずれでもよい。プロンプトが表示するフィンガープリントをそのままコピーするのは便利であり、まさに傍受者が望むことでもある。
実際に起動するコマンドに値を入れる
固定はサーバー証明書オプションで渡され、その接頭辞が符号化を決める：sha1 または sha256 の下では十六進の公開鍵ダイジェスト、pin-sha256 の下では base64 の鍵固定だ。これを与えるとその実行ではシステムの信頼も無効になるので、固定した鍵が判断のすべてになる。
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustクライアントは切り詰めたダイジェストに一致させ、接頭辞の後は四文字だけでも受け入れるが、これは便利ではなく罠だ。短くした値はローカルでは通るが、意図したゲートウェイを特定できない。メッセージから打ち直すのではなく、最初の試行でクライアントが表示した完全な文字列をコピーする。そのうえで完成したオプションを、接続を起動するラッパースクリプト、ユニットファイル、プロファイルに移し、そうすれば信頼の判断が見直せ、後の編集は意図的になる。
デスクトップのランチャーと NetworkManager プラグインは接続引数の独自のコピーを保存する。ディスク上で編集したスクリプトは以前に取り込んだプロファイルには届かないので、保存された値が勝ち続ける。
自分を締め出さずにロールオーバーを扱う
オプションは複数回与えられるので、計画的な変更は出ていく鍵と入ってくる鍵を同時に受け入れられる。ゲートウェイが切り替わる前に新しい固定を加え、セッションが移行する間は両方を並べておき、古い鍵が消えたら引退したほうを外す。その窓には所有者が要る、忘れられた二重の固定は誰も見張らないまま鍵を信頼したままにするからだ。新しい鍵ペアを作る再構築は純粋な固定を壊し、復旧は逆方向の同じ手順だ。
変更日を固定の横に書く。見直し日のない固定は、紛らわしいエラーメッセージを伴う将来の障害だ。
信頼を編集する前にクライアントのバージョンを除外する
古いクライアントは、ゲートウェイがその後変更した認証応答を解析するときに失敗することがあり、表向きのメッセージは今も解析器ではなく接続について語る。インストールされたバージョンをゲートウェイが文書化しているものと比べ、信頼設定を変える前に使い捨てのプロファイルで現行パッケージを試す。
openconnect --version修復の後は一つではなく二つを確認する：ポータルがトンネル経由で読み込まれること、そして普通の内部アドレスが応答することだ。完了したハンドシェイクは、信頼の判断が受け入れられたことしか証明しない。