ルート証明書に秘密鍵を含めるのはなぜですか？
最近のDellルート証明書の問題（ https://threatpost.com/Dell-computers-ship-with-root-cert-private-key/115455/ を参照）では、秘密鍵は証明書。これは私を困惑させ、そのような「エラー」が構造化された開発環境で発生する可能性があるとは信じられません。
ルート証明書に秘密鍵を含める正当な理由はありますか？
別の証明書に署名する場合は、CA証明書の秘密鍵が必要です。これは、さまざまなウイルス対策製品が提供するようなSSLインターセプトプロキシや、悪名高い Superfish 広告注入ソフトウェアの場合です。
主な問題は、秘密鍵が攻撃者によって簡単に取得できるため、中間者攻撃で（証明書と一緒に）使用できるかどうかです。これは通常、Superfishのように、同じソフトウェアの複数のインストールで同じ証明書とキーが使用されている場合に当てはまります。代わりに、SSLインターセプトアンチウイルス製品は、インストールごとに一意の証明書とキーを作成するため、問題の影響をそれほど受けません。
証明書をクライアント認証に使用する必要がある場合、つまりコンピューターがTLS/HTTPS接続内で安全な方法で自身を識別する必要がある場合にも、秘密鍵が必要です。ただし、この場合、通常、新しい証明書の発行に使用できないリーフ証明書しかありません。それとは対照的に、SuperfishおよびeDellRoot証明書で使用される証明書はCA証明書です。つまり、新しい証明書を発行するために使用できるため、中間者攻撃に使用できます。
場合によっては、秘密鍵を使用して証明書をエクスポートし、リムーバブルメディアに保存したり、別のコンピューターで使用したりすることができます。
デルに関しては、彼らは偶然にこれを行ったと思います。
サービスタグ読み出しメカニズムの一部のようです
その背後にある壮大なアイデアはよくわかりませんが、Dell FoundationServicesはHTTPサーバーをローカルで実行しているようです。そして、そのサーバーに（ JSON-API を介して）クエリを実行すると、コンピューターの「サービスタグ」で応答します。 （これは、Dellハードウェアの一意の識別子/シリアル番号です。）
そして ハッカーグループLizard Squadからのブログ投稿 （アーカイブ ここ ）は続きます：
Dell Foundation Servicesは、ポート7779でリッスンするHTTPdを開始します。通常、このHTTPdによって公開されるAPIへのリクエストは、RSA-1024キーを使用して署名され、SHA512でハッシュされたリクエストである必要があります。
そのため、pubkey/privkeyのペアが必要です。 （私think）しかし、これはまったく説明していません。何よりも、そのペアをCAとして保存する必要がある理由です。 Windowsの証明書マネージャーに保存する必要がある理由。
さらに説明をいただければ幸いです。