Access Server の Web 証明書エラー: 空の CA バンドルを修正する

ca_bundle が空、または PEM が壊れていると管理画面が止まります。再起動の前に証明書・鍵・チェーンを一組として検証し、VPN の PKI には触れないでください。

DNS が正しく解決しているのに Web のログイン画面が読み込まれない場合、通常は DNS の問題ではありません。サービスのログに証明書バンドルのパスが空である、あるいは Web 証明書と秘密鍵の PEM 解析失敗が記録されていれば、HTTPS リスナーには使える材料がなく、名前解決をいくら行っても解決しません。修復は 三つの設定キーの中にあり、VPN クライアント証明書を 一枚も再発行する必要はありません。

三つのキーが実際に指すもの

カスタム Web 証明書の組は cs.cert、cs.priv_key、cs.ca_bundle で記述されます。それぞれがファイルへのパスを保持し、三つは Web サービスがまとめて使用します。鍵が違う証明書や、実際にはリーフ証明書であるチェーン用ファイルは、空の値と同じように失敗します。リスナーはブラウザーが受け入れるチェーンを構築できないのです。

これらのキーは Admin と Client の Web UI に属します。VPN クライアントに証明書を発行する PKI とは 別系統です。したがって置き換えても、クライアントプロファイル、サーバー鍵、認証局に触れる必要はありません。Web の TLS 障害を PKI 全体の再構築の理由にするのは、ここで最も高くつく誤りです。

一つの区別が時間を節約します。明示的に空のカスタム値は、上書きがまったく無い状態と同じではありません。前者は解析器に空のパスを渡し、ログ行がそう告げています。後者は Access Server を自身の材料のままにします。だからアップグレード後に正常に起動するホストと、そうでないホストに分かれます。

存在するファイルが解析できない理由

解析器はファイル名ではなく、ファイル内のラベル付きブロックを読みます。秘密鍵を含む .crt、一つの証明書を期待する場所に 一つの連結ブロックとして書かれたチェーン、最終行が切り詰められたファイルは、いずれも拒否されます。RFC 7468 がこれらの可読ラベルを定めているのは、続くオブジェクトの種類を伝える唯一の手段だからです。

拡張子ではなくオブジェクトを調べます。Linux ホストでは openssl x509 -noout -subject -issuer -in server.pem と openssl pkey -noout -check -in key.pem が重要な 二つの問いに答え、両者のモジュラスや公開鍵を比較すれば対になっていることが証明できます。秘密鍵の出力はチケットやチャットログに残さないでください。検査に必要なのは指紋であって鍵ではありません。

空のパスは壊れたファイルと同じ疑いを持つべきです。どちらも下流で曖昧なエラーを生むからです。ログがバンドルのパスを空と言うなら、そのファイルを調べる前に保存値を読んでください。

意図的にフォールバックへ戻す

Access Server の CLI には、三つのパスを引数に取り、その組が使用可能かを報告する検証があります。以下のパスは例です。ホスト上の保護された場所に置き換えてください。

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

稼働中のサービスに触れる前に結果を読み、その後に値を取り込んで、導入済みバージョンの文書化された操作で適用します。公式 CLI チュートリアル は検証、設定データベースへの取り込み、適用の手順を扱っており、そのバージョンの方が要約より重要です。

利用者が実際に入力する名前を検証する

カスタム材料が壊れていて、有効な組み込みのフォールバックが残っている場合、文書化された復旧は 三つの上書きを削除して Access Server にそのフォールバックを使わせることです。先にコンソールアクセスと現在の設定のバックアップを用意してください。再起動するサービスは管理画面を提供しているものです。

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

設定データベース全体を消すことは証明書の修復ではありません。その 三つのキーを対象に適用し、Web UI が応答することを確認します。web-ssl ディレクトリの自己署名ファイルはフォールバックの資源であり、作業領域ではありません。上書きや再生成は、唯一動作していた材料を失わせる可能性があります。

フォールバックが有効になった後、ブラウザーが別の証明書を示すことを想定してください。それが正しい結果であり、信頼できる管理手順で確認するのが答えです。以後の警告をすべて素通りするよう利用者に教えることではありません。

復旧はサインイン成功で初めて完了する

TCP リスナーが現れただけでは復旧は終わりません。DNS 名、証明書の身元、その名前のチェーンを検証し、Admin と Client の両方の Web UI を読み込んでサインインを完了します。ポート検査はそのいずれも証明しません。

Access Server 3.1 以降は SNI ホスト名ごとに異なる Web 証明書を提供できます。それが設定されている場合、既定のキーとホスト名固有の項目は別の組であり、IP アドレスでの確認は利用者が受け取るものと違う証明書を示しがちです。失敗した名前の組を直して検証し、インシデントを閉じる前にサインインの確認を繰り返してください。

関連記事