web-dev-qa-db-ja.com

証明書要求がどこから来たのかを知る方法

サーバー2012R2にCAをセットアップしました。サーバーを実行した人が会社を辞め、新しいCAサーバーをセットアップしました。

証明書の対象となるシステム/ URLを把握しようとしています。

発行済み証明書のリストには、次のものがあります。

リクエストID:71

リクエスター名:DOMAIN\UserName

証明書テンプレート:基本EFS(EFS)

シリアル番号:5f00000047c60993f6dff61ddb000000000047

証明書発効日:2015年11月5日8:46

証明書の有効期限:2016年11月4日8:46

発行国/地域:

発行組織:

発行された組織単位:組織ユーザー従業員

発行された一般名:従業員名<-従業員の実際の名前

発行された市:

発行国:

発行されたメールアドレス:

なぜ従業員が証明書を要求したのかを従業員に尋ねると、理由やシステムが何であったのか覚えていません。

要求されたすべての証明書と、それらが関連付けられているマシンを確認する方法を探しています。

私が試した/グーグルしたもの:

  1. Netstatに似たコマンドで、443のサーバーへのリスニング接続または確立された接続を通知できますが、論理と思考に基づいていない可能性があります。

  2. イベントビューアで「証明書の発効日:2015年11月5日8:46」のタイムスタンプを確認しましたが、何も表示されていないログが見つかりません。

  3. Certutilコマンドを使用してデータベースを確認しようとしましたが、データベースを表示する前にサービスを停止する必要があります。スキーマを確認すると、探している情報の多くがそこにあるように見えます。

サービスを停止してもSSL証明書は問題ありませんか、それともエンドユーザーにSSL警告が表示されますか?

データベースのバックアップを取る場合、ファイルを別のPCに移動して、読み取ることができますか。

私のCAで証明書を使用しているサーバー/ URLを見つけることができるかどうか誰かが知っていますか?

情報を見つけるための別のより良い方法はありますか?

13
Anthony Fornito

When I ask the employee why they requested the certificate they don't remember why or what system it was for.

それはほぼ正しいように聞こえます。 EFS証明書(および他の多くの証明書)は通常、自動的に発行および更新されます。ポリシーでEFSを無効にするか、発行の範囲をテンプレートの特定のセキュリティグループに制限することができます。

I am looking for a way to see all requested certs and what machines they are tied to

EFS証明書は通常、ユーザーに発行され、特定のコンピューターに暗黙的に限定されません。データ回復エージェント(DRA)など、他の種類のEFS証明書もあります。

I tried to look at the database using certutil

証明書は管理mmcに表示されている必要があります。 CA /テンプレートが証明書のコピーを保存しないように構成されている可能性がありますが、それはデフォルトの構成ではありません。

Does anyone know if I will be able to find what servers / URL's are using the certs on my CA?

CAから?いいえ。サブジェクトなど、コンピュータ名またはユーザー名と一致する情報が含まれている場合があります。コンピュータ名またはユーザー名と一致しない名前に対して発行された証明書もある場合があります。または、証明書がCAに保存されていない可能性があります。これは、証明書を使用するすべての人が一度に尋ねる質問であり、万能のソリューションはありません。証明書は、Windowsコンピューターの証明書ストア、Windowsユーザーの証明書ストア、レジストリ、アプリケーションが使用するファイルシステム上のファイル、SQLサーバーなどのアプリケーションに埋め込まれているファイルに存在できるため、証明書がある場所のインベントリはそれほど単純ではありません。考える。そして、それらが見つかったとしても、それはそれらが使用されているという意味ではありません。また、使用中であっても、さらに調査しないと、何が使用されているのかわからない場合があります。

最善のアプローチは、適切な追跡システムをすでに導入していることです。次善の策は、使用中のポート/証明書をネットワークで定期的にスキャンすることです。

3
Greg Askew