Puppetでの代替CA（Microsoft証明書サービスのような）の利用

どういうわけか、パペットエコシステムに、独自のCAではなく、既存のMicrosoftエンタープライズCAを利用させることができるかどうかを調査しています。

パペットはすべてのシステムが「標準SSL」であると宣伝しているので、パペットをあまり変更せずにこれを完全に実行できると思いますが、パペットを編集して企業に適切な呼び出しを行わない限り、手動による大きな頭痛の種になる可能性があります。 CA。

これまでに誰かがこれを試しましたか？「こっちはドラゴンよ、背を向けろ！」状況？

パペットでの証明書の検証と階層の動作は確かに標準のSSLですが、これは標準の部分的な実装の一種です。より複雑なデプロイメントのサポートを改善するために、長年にわたって機能要求が出されています。

証明書の発行と承認をAD証明書サービスシステムに移すこと（そして、二度と入力puppet cert signしないこと）を目的とする場合は、ソフトウェア開発作業がなければ、運が悪いでしょう。

クライアントはPuppet独自のREST APIを使用して、証明書リクエストの作成、署名済み証明書のフェッチ、AIAおよびCRLアクセスなどを処理します。これらのAPI呼び出しとAD証明書サービスRPCアクセスポイントの間に接着剤を実装する必要があります。

しかし、Puppet証明書がAD CSルートの下の信頼チェーンにあることだけを探している場合は、sysadmin1138の推奨事項が適切に機能するはずです（私はそれをテストしていませんが、それを実行して更新するための時間が見つかるでしょう君は）。

Puppetクライアントは、中間のPuppet CAをルートCAであるかのように扱い（ルートCAの知識がなくても有効な検証ができる）、実際のルートCAの有効な子孫であり続けます。