web-dev-qa-db-ja.com

サーバーまたはクライアントは、クライアント/サーバー証明書（既知のルートCAを持つ中間証明書チェーン）を検証できる必要がありますか？

次の設定をテストしようとしています。

RADIUSサーバーはEAP-TLSプロトコルで動作します。クライアントとサーバーには、次の証明書があります。

クライアント
公開鍵：clientcert_intermediatecert_chain.pem
CA証明書：rootcert.pem

サーバー
公開鍵：servercert_intermediatecert_chain.pem
CA証明書：rootcert.pem

クライアント証明書（clientcert.pem）とサーバー証明書（servercert.pem）はどちらも、ルート証明書（intermediatecert.pem）によって署名された同じ中間証明書（rootcert.pem）によって署名されています。
公開鍵として設定されている両方のチェーンは、次のようにまとめられます（シェルコマンドを使用）。
cat servercert.pem intermediatecert.pem > servercert_intermediatecert_chain.pem
cat clientcert.pem intermediatecert.pem > clientcert_intermediatecert_chain.pem

ここで、クライアントはサーバーへの接続を試みます。双方が公開鍵を送信し、受信した公開鍵をrootcert.pemで確認しようとします

「通常の」方法は、公開鍵がサーバーまたはクライアント証明書のみであったことを私は知っています。また、CA証明書はimcert-rootcert-chainになりますが、これも機能するかどうかを知る必要があります。

今私の質問：

  1. 公開鍵がサーバー/クライアント証明書と中間証明書で構成されるチェーンであることは正当ですか？
  2. もしそうなら、これは両方の側（サーバーとクライアント）に適用されますか？
  3. サーバー（FreeRADIUSなど）またはクライアントは、カウンターパートからチェーンを受け取った場合、ルート証明書を使用してこれらのようなチェーンを検証できる必要がありますか？

私の経験に基づくと、FreeRADIUSはそのような証明書チェーンの権利を検証していません。私が間違っていない場合、FreeRADIUSはOpenSSLライブラリを使用し、上記の状況で次のコマンドと同じことを行います。

openssl verify -CAfile rootcert.pem clientcert_intermediatecert_chain.pem

そして、私はこれがうまくいかないと確信しています。 OpenSSLは、このようなチェーンをルート証明書で検証できません。信頼の連鎖をまとめようとすると失敗します。
これは正しいです？

ちなみに、FreeRADIUSはverifyコマンドと同じエラーerror 20 at 0 depth: cannot find issuer certificateを返します。これは、信頼の連鎖をまとめることができないことを意味します。

sslauthenticationradiusfreeradiuskeychain
2
Jannis Kappertz
  1. はい、共通の中間CAでチェーンを使用することは問題ありません。
  2. はい。
  3. はい、そうです。 FreeRADIUSからのデバッグ出力を投稿する必要があります。 「エラー20」が返されると言っても役に立ちません。これはFreeRADIUSエラーではない可能性がありますが、OpenSSLからの出力です。
2
Arran Cudbard-Bell

私のセットアップの問題は、クライアントが完全なクライアント-中間チェーンを送信せず、クライアント証明書のみを送信したことであったようです（Wiresharkを使用してそれを理解しました）。逆に、サーバー中間チェーンを送信するRADIUSサーバーは正常に機能します。

だから、私の質問に答えるために：はい、このセットアップは両方向で機能するはずです。

0
Jannis Kappertz