証明書のキー 公開キーの暗号化

証明書のキー 公開キーの暗号化では、異なるキーを使用して、情報の暗号化および暗号化の解除を行います。
最初のキーは秘密キーで、所有者しか知らないキーです。2 つ目のキーは公開キーで、ネットワークの他のエンティティに公開したり、他のエンティティが使用できます。
2 つのキーは、機能的に補完しています。
たとえば、ユーザーの公開キーを任意のディレクトリに保存した証明書内で公開すると、組織内の他のユーザーがそのキーにアクセスできます。メッセージの送信者は、Active Directory からユーザー証明書を取得し、証明書から公開キーを入手して、受信者の公開キーを使用してメッセージを暗号化します。
公開キーで暗号化された情報は、秘密キーの所有者、つまりメッセージの受信者が手元に持っているセットの、公開キーに対応する秘密キーを使用しなければ解読できません。 証明書のファイル形式 使用する証明書のファイル形式の種類は、セキュリティと互換性の両方を考慮して決定できます。
Windows 8 と Windows RT では、証明書を次の形式でインポートおよびエクスポートできます。

Personal Information Exchange (PKCS #12) <
Personal Information Exchange 形式 (PFX、または PKCS #12) では、証明書とそれに対応する秘密キーを、あるコンピューターから別のコンピューターに、またはコンピューターからリムーバブル メディアに転送できます。 秘密キーをエクスポートすると、意図していない相手にキーが公開される場合があるため、PKCS #12 形式は、Windows 8 で証明書とそれに関連する秘密キーのエクスポート用にサポートされている唯一の形式です。

Cryptographic Message Syntax Standard (PKCS #7) PKCS #7 形式
証明書とその証明書パス内のすべての証明書を、あるコンピューターから別のコンピューターに、またはコンピューターからリムーバブル メディアに転送できます。
DER Encoded Binary X.509 ASN.1 用の DER (Distinguished Encoding Rules)
ITU-T 推奨 X.509 で定義されていて、Windows Server 2003 を実行しているコンピューターにインストールされていない証明機関が相互運用性を確保するために使用できます。DER 証明書ファイルの拡張子は .cer です。
Base64 Encoded X.509
このエンコード方式は、S/MIME (Secure/Multipurpose Internet Mail Extensions) で使用するように開発されました。
S/MIME は、インターネット上でバイナリ添付ファイルを転送する際によく使用されている標準方式です。
S/MIME 対応のすべてのクライアント コンピューターは Base64 ファイルをデコードできるため、この形式は、Windows オペレーティング システムを実行していないコンピューター上の証明機関が相互運用性を確保するために使用できます。Base64 証明書ファイルの拡張子は .cer です。 クロス証明書は、別々のネットワークやネットワークの一部など、異なる証明階層間で信頼を確立するために使用します。このような状況では、クロス証明書は一般的に次のように構成されます。
1 つの証明階層で発行された証明書の名前空間が、2 つ目の階層で使用され受け入れられるように名前空間を定義します。
クロス証明された証明機関 (CA) が発行する証明書の受け入れ可能な使用方法を指定します。
他の階層で有効と見なされるために、クロス証明された CA によって発行された証明書について、従う必要がある発行方法を定義します。
個々の証明階層の間に管理されている信頼を作成します。 管理者は [EV (Extended Validation)] タブを使用して、グループ ポリシーによって配布されるルート証明書に、Extended Validation 証明書ポリシーを追加できます。

EV 証明書ポリシーをルート証明書とイントラネット Web サイトに発行された証明書に追加することで、サイトが信頼できることを視覚的に示すインジケーターを提供できます。 管理者がオンライン証明書ステータス プロトコル (OCSP) レスポンダーの URL を発行元の証明機関 (CA) 証明書に追加するために[OCSP] タブを使用します。
この証明書は、グループ ポリシーによって Active Directory ドメイン メンバーに配布されます。これにより、CA 証明書や以前 CA によって発行された証明書を再発行せずに、OCSP レスポンダーを既存の公開キー基盤 (PKI) に追加できます。この方法で提供された OCSP レスポンダーの URL は、CA によって発行された証明書の証明書失効状態の確認に使用されます。

グループ ポリシー クライアント サービス (gpsvc)
Windows RT では既定で無効になっており、ローカル管理者が有効にすることができます。 ソフトウェア発行者およびアプリケーション開発者は、ソフトウェアの署名を使用して、そのアプリケーションの発行元が信頼できることを確認します。しかし、多くのユーザーは、自分がインストールするアプリケーションに関連付けられている署名証明書について理解していないか、ほとんど関心がありません。

管理者は証明書パスの検証ポリシーの [信頼された発行元] タブにあるポリシー設定を使用して、信頼できる発行元の証明書として許可する証明書を制御できます。 資格情報の移動を使用すると、アプリケーションの状態や構成情報とは別に、証明書と秘密キーを Active Directory に保存できます。 資格情報の移動では、既存のログオンと自動登録メカニズムを使用します。資格情報の移動は、Windows Server 2012 を実行しているサーバー上に構成する必要があります。これらのメカニズムにより、証明書とキーをローカル コンピューターに安全にダウンロードすることが可能になります。さらに、証明書を更新した場合や、ユーザーが複数のコンピューターにログオンした場合など、どのような状況でもこれらの資格情報の整合性が維持されます。 証明書の登録ポリシー Web サービスは、ユーザーとコンピューターが証明書の登録ポリシー情報を取得することを可能にする Active Directory 証明書サービス (AD CS) の役割サービスです。

証明書の登録

Web サービスと合わせて使用することで、クライアント コンピューターがドメインのメンバーでない場合や、ドメイン メンバーが自身のドメインに接続していない場合に、ポリシー ベースの証明書の登録を可能にします。 証明書の登録ポリシー Web サービスは、HTTPS プロトコルを使用して、ネットワーク上のクライアント コンピューターに証明書のポリシー情報を伝達します。証明書の登録 Web サービスは、LDAP プロトコルを使用して、Active Directory ドメイン サービス (AD DS) から証明書ポリシーを取得し、そのポリシー情報をクライアント コンピューターからのサービス要求に対してキャッシュします。
AD CS の旧バージョンでは、証明書のポリシー情報は、LDAP プロトコルを使用するドメイン上のクライアント コンピューターだけがアクセスできました。
これにより、ポリシー ベースの証明書の発行は、AD DS フォレストによって確立された信頼境界に限定されます。
企業の証明機関 (CA) の数を減らすためのフォレスト境界を越えた証明書の登録。
モバイル ユーザーとビジネス パートナーに証明書を発行するためのエクストラネットHTTPS を介した登録ポリシーの発行は、この展開シナリオを可能にしました。

カテゴリー: 未分類

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。