SSTP と IKEv2 は異なる RRAS 証明書制御を使用する

「VPN 証明書」を置き換えると、別のサービスの設定を変えてしまうことがあります。RRAS は少なくとも 三つの証明書制御を保持しており、それぞれが異なるプロトコルと異なる接続の役割に属します。先にプロトコルを特定すれば、危険な推測が 一度の元に戻せるバインド変更になります。以下のすべてはその 一文にかかっています。

証明書より先にプロトコルを特定する

SSTP リスナーは、HTTPS のように振る舞うクライアントに TLS 証明書を提示します。受信側のサイト間 IKEv2 接続はサーバー ID を通知し、ピアの証明書を信頼されたルートに対して検証します。インターフェースごとのサイト間定義は、独自のマシン ID を持ちます。

これは 三つのスコープを持つ 三つの制御です。これらを混同すると、一方のプロトコルでは動くように見え、もう一方にはまったく効かない変更になり、明らかな失敗より悪い結果になります。何かに触れる前に、どのプロトコルが失敗したのか、どちら側が証明書を提示したのか、どちら側が拒否したのかを書き留めてください。

SSTP は HTTPS バインドである

サポートされている Remote Access の展開では、Set-RemoteAccess が SSTP 接続と HTTPS 関連の DirectAccess ロールに使われる SslCertificate パラメーターを公開します。

その検証と展開のスコープは Remote Access の構成に従うため、一度のバインド変更が複数の接続やノードに及ぶことがあります。負荷分散された展開では、そのスコープは構成が対象とするすべてのノードを含みます。一つのノードだけを変更して 一つのクライアントだけをテストすると、残りは古いリーフを提示し続けます。これは保守作業の時間帯を越えて残る半端な変更です。

更新の前に、想定されるサービス名、チェーン、有効期間、意図された用途、秘密キーの可用性を確認してください。証明書はクライアントが確認する名前に一致している必要があり、アダプターのラベルはその名前ではありません。

受信側 IKEv2 には専用のパラメーターがある

Set-VpnAuthProtocol は受信側のサイト間 IKEv2 認証を構成し、CertificateAdvertised はトンネル認証モードがそれらを使う場合に証明書を提供します。これはホスト上の任意のサーバー証明書を選ぶための一般的なコマンドではありません。

二つのオブジェクトを分けて扱ってください。サーバーが自身の ID として提示するリーフと、ピアの証明書を受け入れるために使うルートです。どの発行元を信頼するかの選択は、サーバーがどのリーフを提示するかについて何も語りません。

個々のサイト間インターフェースの ID は Set-VpnS2SInterface で設定します。同じマシンの同じストアに両方あっても、自動的に SSTP 証明書になるわけではありません。

まず候補を調べる

ローカル コンピューターのストアを対象にした表示では、非公開のものをエクスポートせずに公開メタデータを確認できます。

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

この一覧は出発点であり、適格性のテストではありません。構成するプロトコルについて、SAN エントリ、拡張キー使用法、チェーン、サービス アカウントの秘密キーへのアクセスを調べてください。

無関係なクラウド クライアント ID 用にインストールされた証明書は、同じストアに現れるというだけでは適格ではありません。可視性は適格性ではなく、スクリーンショットの拇印は、サービス アカウントがキーを読めるかどうかを何も証明しません。そのアクセスを明示的に確認してください。キーのアクセス許可が欠けている場合、サービスが再起動して証明書を使おうとしたときに初めて失敗します。

現在のバインドを記録し、変更する前に別の方法でホストに到達できることを確認してください。復旧経路は変更の一部であり、その後に起きるインシデントの一部ではありません。

更新は有効化ではない

証明書を再発行することは、実行中のサービス用にそれを選択することとは別の操作です。新しいリーフは意図された DNS ID を保ったまま別の拇印を持つことがあるため、バインドが更新されるまで何もそれを指しません。更新はオブジェクトを変え、有効化はそのオブジェクトへの参照を変えます。この 二つを混同すると、正しく更新された証明書が何週間も未使用のまま残ります。

サポートされている変更を適切な時間帯に、文書化された再起動も含めて適用し、その後、意図したプロトコルの新しい接続から証明書を調べてください。キャッシュされたクライアント セッションは古いリーフを表示し続け、正しい変更を壊れているように見せることがあります。

前の証明書は、その確認が通った後にのみ通常の手順で廃止してください。Set-RemoteAccess のリファレンスには、負荷分散された展開での影響を含む SSL パラメーターのスコープが記載されており、バインド変更の前に読む価値があるのはその部分です。