web-dev-qa-db-ja.com

MS証明書サービスはOpenSSLで作成されたCAの下位にできますか

ドメインのエンタープライズ証明機関をセットアップしたい。そのため、さまざまな目的で証明書を発行できます。ルートとしてオフラインCAを使用し、エンタープライズCAを下位としてセットアップするというベストプラクティスに従いたいと思います。しかし、このタスクのためにWindowsの完全なコピーをライセンスするのはばかげているようです。

私ができることを望んでいるのは、USBフラッシュディスクにライブディストリビューションをインストールしてから、opensslをインストールし、フラッシュドライブにCAをセットアップすることです。ルートキー/証明書を作成する準備ができたら、コンピューターをネットワークから切断し、ネットワークに接続されたコンピューターでそのUSBディスクを再び使用することはありません。

WindowsエンタープライズCAの下位CA証明書に適切に署名して作成できますが、これは使用可能になります。 CAを構築し、下位のCA証明書に適切に署名するために、OpenSSLでどのオプションを使用する必要がありますか。

私はウェブを検索してみましたが、この件については this だけが見つかりました。しかし、それは2008年より前のことであり、その人がすべての成功を収めたとは完全には確信していません。

ssl-certificatewindowsopensslcertificate-authority
16
Zoredache

うん、それはうまくいきます。 Windowsの認証局は、Windows以外のルートの下位として実行することに何の問題もありません。

OpenSSLルートとエンタープライズモードのWindows 2008 R2従属でテストされています。

MS CAがOpenSSL構成で期待していることでニースを演じる2つのこと：

  • 有効なAIAおよびCDPの場所は、自己署名ルートのx509_extensionsセクションの[req]プロパティによって構成されたセクションで、ルート証明書に適用する必要があります。これらの線に沿った何か：

    authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
crlDistributionPoints = URI:http://test-rootca.test.local/root.crl

  • 特定のOpenSSL構成では、おそらくデフォルトで下位CAを許可していません。署名付きリクエストの場合はこれを変更します（もちろん、これがCAであってはならないリクエストには適用されません）。これは、x509_extensionsセクションの[ca]プロパティによって構成されたセクションにあります。

    basicConstraints=CA:TRUE
certificatePolicies=2.5.29.32.0

したがって、テストのためにCAを実行します。

ルートを作成します。

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

設定をいじって、OpenSSL設定の[ca]セクションに必要なファイルとディレクトリを作成します。

マイクロソフト側の取り組みを開始する準備はすべて整いました。手動署名付きのWindows下位CAを作成します。

証明書要求をOpenSSLサーバーにアップロードします。そこにいる間に、ルート証明書をダウンロードします。ユーザーではなくコンピューターの信頼されたルートストアにインポートします。

下位証明書を発行します。

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

それでも機能しない場合は、CAの構成に問題がある可能性があります。新しい証明書ディレクトリ、インデックスファイル、シリアルファイルなどです。エラーメッセージを確認してください。

それが起こった場合、それはそれだけです。まだ作成していない場合は、CRLを作成して、上記で構成したCDPに配置します。 Apacheをインストールして、webrootにジャムしました：

openssl ca -gencrl -out /var/www/root.crl

証明書がまだない場合は、AIAの場所に配置します。

cp /etc/ssl/certs/root.pem /var/www/root.pem

新しく発行された下位証明書をダウンロードし、証明機関MMCスナップインを使用してCAにインストールします。信頼または検証に関する問題はすべて解決しますが、それを行うことに道徳的な異議はありませんそれ。

最終結果;エンタープライズPKIスナップインからの問題がなく、属性にOpenSSL Generated Certificateが記載された、機能しているWindowsCA。

working-ca

14
Shane Madden

あなたが何を手に入れているのかはわかりますが、OpenSSLがその仕事のためのツールとはまったく思えません。 [〜＃〜] ejbca [〜＃〜] などの Open Source Certificate Authorityプロジェクト を見て、OpenSSLよりもこの機能に重点を置いて、使用できる特定のドキュメント。

下位のCAの証明書に署名しているだけなので、この概念が機能しない理由はわかりません。これを行うために公的CAにお金を払っていたとしても、彼らが使用しているサーバーの種類を必ずしも知っていたり、気にする必要はありません。

あなたが気にする必要があるのは、

  • 部下によって生成されたCSRからの証明書に署名できます
  • 結果は部下自体にインストールできます
  • 対象としているクライアントに信頼できるものとしてインストールできるルート署名証明書がある
  • どこかに提供される失効リストを生成できます

私はこれを行ったとは言えませんが、ウィンドウズボックスからCSRを生成するためのドキュメントに従って、CSRから.p7k証明書を生成するためのCAドキュメントに従っているなら、きっと大丈夫です。

ちなみに、CAは、ブートディスクではなく、Hyper-VやVMwareなどの一般的なハイパーバイザーの仮想マシンとして作成し、後継者が見つけられる場所に非常に安全に保管し、スピンさせることをお勧めします定期的にオフラインで実行して、実行を確認するか、新しいメディア/テクノロジーに転送します。ルートCAの寿命は10年または20年です...

6
dunxd