次の状況では、3 つのルート CA、1 つのルート CA + 3 つの中間 CA、またはその他の PKI セットアップが必要ですか?
使用例は 3 つあります。
- HTTPS (サーバー証明書) 経由で Web API を公開する
- クライアントがユーザー名/パスワードの代わりにクライアント証明書で認証できるようにする (外部クライアント証明書)
- 内部サーバーをクライアントとして検証する(内部クライアント証明書)
すべてのキー ペアは、使用ケースの 1 つにのみ使用されます。
サードパーティの CA は必要なく、代わりにクローズド システムでカスタム PKI を使用していると仮定します。これをサポートするには、主に 2 つの方法があります。
- 1 つのルート CA と 3 つの中間 CA (各ケースに 1 つの中間 CA)
- 3 つのルート CA (ユースケースごとに 1 つのルート)
私は #1 を開始しようとしましたが、node.js HTTPS サーバーに対してクライアント証明書をテストするにはopenssl s_client
、中間だけでなく中間からルートまで検証する必要があることがわかりました。つまり、ルートが信頼アンカーであるため、ユースケース 2 と 3 の間のクライアント証明書は交換可能です。調べてみましたが、中間 CA を node.js HTTPS サーバーの信頼アンカーにする方法が見つかりません。
つまり、私は何かを大きく誤解しているので、実装 2 に移行するか、またはそれらの組み合わせに移行する必要があります。
答え1
X.509 証明書は機密性と認証を提供します。つまり、リンクの暗号化に使用でき、オプションでユーザーまたはサーバーの認証にも使用できます。
これらは承認を提供しません。代わりに、X.509 証明書で認証されたエンティティがリソースへのアクセスを許可されているかどうかを判断するのはアプリケーション次第です。
つまり、上記(1)で問題ありません。ルートを1つ使用し、認証は別の手段で行われるようにしてください。
ただし、X.509 証明書でも認証を提供する必要があると主張する場合は、次のいずれかを行う必要があります。
- 証明書ポリシーに依存して、アプリケーションが特定の証明書のみを信頼するようにします。ポリシーをチェックする独自のアプリケーションをコーディングする必要がある可能性が高いため、うまくいくことを祈ります。
- 上記(2)と同様に、アプリケーションごとに異なるルート証明書を使用します。