AWS Client VPN：サーバー証明書とクライアント証明書の役割

Client VPN のエンドポイントには、常に TLS サーバー証明書が必要です。これは、クライアントが接続したときにマネージドエンドポイントが提示する識別情報です。相互認証を使うときに個々のクライアントが提示する証明書とは別のオブジェクトです。この二つを取り違えることが、それ以外は正しい ACM の設定が最初の接続で失敗する最も一般的な理由です。

ここでは、接続が実際にたどる順序に沿って、コンソールから外側へと見ていきます。

二つの役割、一つのエンドポイント

エンドポイントはサーバーの識別情報を持ち、必要に応じてクライアントの識別情報を検証する手段も持ちます。これらは別々に設定します。一方は クライアントがサービスを信頼できるかどうか を決め、もう一方はサービスがクライアントを受け入れるかどうかを決めます。

表は一つの証明書ではなく、三つの独立した要件として読んでください。サーバー証明書とその秘密鍵はサービス側に残ります。クライアント証明書と対応する秘密鍵は端末上にあります。CA の素材は、検証者がチェーンを確認するために使うものです。ノートパソコンに置くのは中央の行だけです。

ACM のサーバー証明書が担うこと

エンドポイントを作成するとき、サーバー証明書はエンドポイントと同じリージョンの ACM に用意されている必要があります。コンソールは ARN を求め、その ARN はそこで解決できなければなりません。ACM には、ドメイン検証で取得した証明書も、鍵とチェーンとともにインポートした証明書も置けます。どちらもこの役割で機能しますが、更新の方法と秘密鍵を誰が持つかが異なります。

証明書を更新できる人がどちらかに合わせて取得方法を選んでください。たまたま有効に見えるファイルができた方ではありません。

相互認証が加えるもの

証明書ベースのクライアント認証を選ぶと、二つ目の問いが加わります。どのクライアントが接続を許されるかという問いです。各クライアントは自分の証明書を提示し、対応する秘密鍵を保有していることを証明します。識別情報が分かれているからこそ、後から選択的に失効させられます。一つのクライアント鍵をすべての端末にコピーすると、サーバー証明書を完璧に取得していても、その性質を静かに捨ててしまいます。

エンドポイントの認証方法は選択であり、普遍的な要件ではありません。

Active Directory やフェデレーション認証は、別の手段で同じ問いに答えます。相互証明書の手順は、そうした配備のログイン設計に自動的になるわけではなく、利用者をどう受け入れるかにかかわらず、サーバーの TLS 検証はそのまま残ります。

同じ CA の ARN が鍵の共有ではない理由

AWS は、サーバー証明書とクライアント証明書が同じ CA から発行されている場合、サーバー証明書の ARN をクライアント証明書の選択にも使えると記しています。その一文は、検証のときにエンドポイントがどのチェーンを信頼するかについて述べたものです。クライアントにサーバーの秘密鍵を使えと言っているのではありません。ノートパソコンには、依然として自分のクライアント証明書と対応する鍵が必要です。

クライアントの CA が別の発行者である場合 は、その CA を ACM にインポートし、クライアントの役割に選ぶのが記された手順です。

失敗を段階までさかのぼる

何かを交換する前に、どの段階で失敗しているかを見極めてください。クライアントがエンドポイントを拒否するなら、疑うべきはサーバーの ARN かそのチェーンです。エンドポイントがクライアントを拒否するなら、クライアント証明書とその発行者、選んだ認証方法を見ます。トンネルが立ち上がって通信がまだ失敗するなら、証明書の話はもう終わっています。

一度に一つずつ交換してください。両端を同時に変えると、最初の曖昧さをそのまま再現することになります。

その役割に求められる鍵アルゴリズムと拡張も確認してください。公開ウェブサイトを満たす証明書は、Client VPN の識別情報の要件をすべて満たした証拠にはなりません。

各フィールドがどの ARN を持つか、どの CA がクライアント証明書を発行したか、エンドポイントが実際にどの認証方法を使うかを書き留めてください。三行の記録が、次の更新を調査ではなく作業に変えます。