1.3. 証明書および認証
1.3.1. 証明書は誰または何を識別
証明書とは、個人、サーバー、会社、または他のエンティティーを特定し、そのアイデンティティーを公開鍵に関連付けるために使用される電子ドキュメントです。運転免許または乗車のように、証明書は、一般的にユーザーのアイデンティティーを証明する証明を提供します。公開鍵暗号では、証明書を使用してなりすましの問題に対処します。
運転免許申請などの個人 ID を取得するには、そのユーザーが本人であることを検証する、他の形式の識別が必要です。証明書はほぼ同じように機能します。認証局 (CA) は ID を検証し、証明書を発行します。CA は、独立したサードパーティー、Certificate System などの独自の証明書発行サーバーソフトウェアを実行している組織のいずれかです。アイデンティティーの検証に使用される方法は、要求する証明書のタイプの特定の CA のポリシーによって異なります。証明書を実行する前に、CA は標準検証手順を使用してユーザーの ID を確認する必要があります。
CA によって発行された証明書は、特定の公開鍵を、従業員やサーバーの名前など、証明書が識別するエンティティーの名前にバインドします。証明書は、なりすましのための偽の公開鍵の使用を防ぐのに役立ちます。証明書で認定された公開鍵のみが、証明書で識別されたエンティティーが所有する対応する秘密鍵で機能します。
公開鍵の他に、証明書には常に識別するエンティティーの名前、有効期限、証明書を発行した CA 名、シリアル番号が含まれます。証明書には、発行する CA のデジタル署名が常に含まれます。CA のデジタル署名により、証明書は CA を把握して信頼しているが、証明書で識別したエンティティーを認識しないユーザーの有効な認証情報として機能できます。
CA のロールの詳細は、「CA 証明書による信頼の仕組み」を参照してください。
1.3.2. 認証によるアイデンティティーの確認
認証 は、アイデンティティーを確認するプロセスです。ネットワークの対話については、認証には、別の当事者による識別が必要です。ネットワーク上で認証を使用する方法は複数あります。証明書はその方法の 1 つになります。
通常、ネットワークの対話は、Web ブラウザーやサーバーなどのクライアント間で行われます。クライアント認証 とは、サーバーによりクライアント (ソフトウェアの使用を前提としたユーザー) を特定することを指します。サーバーの認証 とは、クライアントによりサーバー (ネットワークアドレスでサーバーの実行を想定している組織) を特定することを指します。
クライアントおよびサーバーの認証は、証明書がサポートする認証形式ではありません。たとえば、送信者を特定する証明書とともに、電子メールメッセージ上のデジタル署名は、メッセージの送信者を認証できます。同様に、HTML フォームのデジタル署名は、署名者を識別する証明書と組み合わせて、その証明書によって識別された人がフォームの内容に同意したという証拠を提供できます。認証に加えて、どちらの場合もデジタル署名はある程度の否認防止を保証します。デジタル署名は、署名者が後で電子メールまたはフォームを送信していないと主張することを困難にします。
クライアント認証は、ほとんどのイントラネットまたはエクストラネット内のネットワークセキュリティーの重要な要素です。クライアント認証には、主に 2 つの形式があります。
- パスワードベースの認証
- 証明書ベースの認証
1.3.2.1. パスワードベースの認証
図1.4「パスワードを使用したクライアントのサーバーへの認証」 は、ユーザー名とパスワードを使用してユーザーを認証するプロセスを示しています。この例では、以下を前提としています。
- ユーザーは、認証なしで、または SSL/TLS によるサーバー認証のベースとして、すでにサーバーを信頼しています。
- ユーザーがサーバーが制御するリソースを要求しました。
- 要求されたリソースへのアクセスを許可する前に、サーバーの認証が必要です。
図1.4 パスワードを使用したクライアントのサーバーへの認証
この認証プロセスの手順は次のとおりです。
- サーバーがクライアントから認証を要求すると、クライアントはそのサーバーのユーザー名およびパスワードを要求するダイアログボックスが表示されます。
- クライアントは、プレーンテキストまたは暗号化された SSL/TLS 接続を使用して、ネットワーク全体で名前とパスワードを送信します。
- サーバーは、ローカルパスワードデータベースで名前とパスワードを検索し、一致する場合は、ユーザーの ID を認証するエビデンスとして受け入れます。
- サーバーは、識別されたユーザーが要求されたリソースへのアクセスを許可されているかどうかを判断し、許可されている場合は、クライアントがそのリソースにアクセスできるようにします。
この方法では、ユーザーがアクセスする各サーバーに新しいパスワードを提供する必要があり、管理者は各ユーザーの名前とパスワードを追跡する必要があります。
1.3.2.2. 証明書ベースの認証
証明書ベースの認証の利点の 1 つは、認証の最初の 3 ステップを、ネットワークを越えて送信されない 1 つのパスワードを供給する仕組みに置き換えることができ、管理者がユーザーの認証を一元的に制御できることです。これは シングルサインオン と呼ばれます。
図1.5「証明書を使用したクライアントのサーバーへの認証」 は、証明書と SSL/TLS を使用してクライアント認証がどのように機能するかを示しています。ユーザーをサーバーに認証するには、クライアントが無作為に生成されたデータの一部に署名し、ネットワーク全体で証明書と署名済みデータの両方を送信します。サーバーは、証明書および署名されたデータのデータに基づいてユーザーのアイデンティティーを認証します。
図1.4「パスワードを使用したクライアントのサーバーへの認証」、図1.5「証明書を使用したクライアントのサーバーへの認証」 と同様に、ユーザーがすでにサーバーを信頼し、リソースをリクエストしたこと、および要求されたリソースへのアクセスを付与する前にクライアント認証が要求されていることを前提としています。
図1.5 証明書を使用したクライアントのサーバーへの認証
図1.4「パスワードを使用したクライアントのサーバーへの認証」 の認証プロセスとは異なり、図1.5「証明書を使用したクライアントのサーバーへの認証」 の認証プロセスには SSL/TLS が必要です。また、図1.5「証明書を使用したクライアントのサーバーへの認証」 は、クライアントがサーバーに対してクライアントを識別するのに使用できる有効な証明書を持っていることを前提としています。証明書ベースの認証は、秘密鍵を所有し、パスワードを知っているユーザーの両方に基づいているため、パスワードベースの認証よりも優先されます。ただし、これら 2 つの仮定は、権限のない担当者がユーザーのマシンまたはパスワードにアクセスできず、クライアントソフトウェアの秘密鍵データベースのパスワードが設定されており、ソフトウェアが適度な頻度でパスワードを要求するように設定されている場合にのみ当てはまります。
注記
パスワードベースの認証または証明書ベースの認証は、個々のマシンまたはパスワードへの物理的なアクセスに関連するセキュリティーの問題に対応します。公開鍵暗号は、一部のデータの署名に使用される秘密鍵が証明書の公開鍵に対応していることを確認することしかできません。マシンの物理的なセキュリティーを保護し、秘密鍵のパスワードを秘密にしておくことは、ユーザーの責任です。
図1.5「証明書を使用したクライアントのサーバーへの認証」 に記載されている認証手順は以下のとおりです。
- クライアントソフトウェアは、そのクライアントに対して発行された証明書に発行される公開鍵に対応する秘密鍵のデータベースを維持します。クライアントは、証明書ベースのクライアント認証を必要とする SSL/TLS 対応サーバーに初めてアクセスしようとしたときなど、特定のセッション中にクライアントが初めてデータベースにアクセスする必要があるときに、このデータベースのパスワードを要求します。このパスワードを一度入力すると、他の SSL/TLS 対応サーバーにアクセスする場合でも、残りのセッションに対して再度入力する必要はありません。
- クライアントは秘密鍵データベースのロックを解除し、ユーザーの証明書の秘密鍵を取得し、その秘密鍵を使用してクライアントとサーバーの両方からランダムなデータに署名します。このデータとデジタル署名は、秘密鍵の有効性について証明されています。デジタル署名はその秘密鍵でのみ作成でき、SSL/TLS セッションに固有の署名済みデータに対して、対応する公開鍵で検証できます。
- クライアントは、ユーザーの証明書とランダムに生成されたデータの両方をネットワーク経由で送信します。
- サーバーは、証明書と署名済みデータを使用してユーザーのアイデンティティーを認証します。
- サーバーは、クライアントが提示する証明書が LDAP ディレクトリー内のユーザーのエントリーに保存されていることを確認するなど、他の認証タスクを実行できます。その後、サーバーは、指定のユーザーが要求されたリソースにアクセスできるかどうかを確認します。この評価プロセスでは、LDAP ディレクトリーまたは企業のデータベースで追加情報を使用すると、さまざまな標準的な承認メカニズムを使用できます。評価の結果が正である場合、サーバーは、要求されたリソースにクライアントがアクセスすることを許可します。
1.3.3. 証明書に使用
証明書の目的は、信頼を確立することです。その使用法は、それが保証するために使用される信頼の種類によって異なります。提示した者の ID を確認するために、いくつかの種類の証明書が使用されたり、オブジェクトまたはアイテムが改ざんされていないことを確認したりするために使用されます。
1.3.3.1. SSL/TLS
SSL/TLS (Transport Layer Security/Secure Sockets Layer) プロトコルは、サーバーの認証、クライアント認証、サーバーとクライアント間の暗号化された通信を管理します。SSL/TLS はインターネット上で広く使用され、特にクレジットカード番号などの機密情報に関連する対話に使用されます。
SSL/TLS には、SSL/TLS サーバー証明書が必要です。最初の SSL/TLS ハンドシェイクの一環として、サーバーは証明書をクライアントに提示してサーバーのアイデンティティーを認証します。認証は公開鍵の暗号化とデジタル署名を使用して、サーバーが、そのサーバーであると主張するサーバーであることを確認します。サーバーが認証されると、クライアントとサーバーは、対称鍵の暗号化を使用して、残りのセッションに対して交換されたすべての情報を暗号化し、改ざんを検出します。
サーバーは、クライアント認証とサーバーの認証を必要とするように設定できます。この場合、サーバーの認証が正常に完了した後に、クライアントの証明書をサーバーに提示して、暗号化された SSL/TLS セッションが確立される前にクライアントのアイデンティティーを認証する必要があります。
SSL/TLS によるクライアント認証の概要と、パスワードベースの認証との相違点は、「認証によるアイデンティティーの確認」を参照してください。
1.3.3.2. 署名済みおよび暗号化電子メール
メールプログラムは、S/MIME (Secure Multipurpose Internet Mail Extension) と呼ばれる広く使用されているプロトコルを使用して、署名済みおよび暗号化された電子メールをサポートします。S/MIME を使用して電子メールメッセージに署名または暗号化するには、メッセージの送信者に S/MIME 証明書が必要です。
デジタル署名が含まれる電子メールメッセージは、メッセージヘッダーに名前が表示されるユーザーによって送信されたロールを果たすようにするため、送信者を認証します。電子メールソフトウェアがデジタル署名を検証できない場合には、ユーザーが警告されます。
デジタル署名は、それに付随するメッセージに固有のものです。受信したメッセージが送信したメッセージと何らかの形で異なる場合は、1 文字を追加または削除しても、デジタル署名を検証できません。そのため、署名された電子メールは、電子メールが改ざんされていないという保証も提供します。この種の保証は否認防止と呼ばれ、送信者がメッセージの送信を拒否することを困難にします。これはビジネス通信で重要になります。デジタル署名の動作方法は、「デジタル署名」を参照してください。
S/MIME を使用すると、一部のビジネスユーザーが重要な電子メールメッセージを暗号化することもできます。ただし、電子メールの暗号化を使用する場合は、注意して計画する必要があります。暗号化された電子メールメッセージの受信側が秘密鍵を失い、キーのバックアップコピーにアクセスできない場合は、暗号化されたメッセージが復号できなくなります。
1.3.3.3. シングルサインオン
ネットワークユーザーは、使用するサービスに複数のパスワードを覚えておく必要が頻繁にあります。たとえば、ユーザーがネットワークにログインするのに別のパスワードを入力してログインし、電子メールを収集して、ディレクトリーサービスを使用し、企業カレンダープログラムを使用して、さまざまなサーバーにアクセスしなければならない場合があります。複数のパスワードは、ユーザーおよびシステム管理者向けに継続されます。ユーザーはさまざまなパスワードを追跡するのが難しく、貧弱なパスワードを選択する傾向があり、わかりやすい場所にそれらを書き留める傾向があります。管理者は、各サーバー上の個別のパスワードデータベースを追跡し、パスワードがネットワークを介して定期的かつ頻繁に送信されるという事実に関連する潜在的なセキュリティー問題に対処する必要があります。
この問題の解決には、ユーザーが一度ログインして単一のパスワードを使用し、ユーザーがネットワーク経由でパスワードを送信できなくなるすべてのネットワークリソースへの認証アクセスが必要になります。この機能はシングルサインオンと呼ばれます。
クライアント SSL/TLS 証明書と S/MIME 証明書の両方が、包括的なシングルサインオンソリューションで大きなロールを果たすことができます。たとえば、Red Hat 製品がサポートするシングルサインオンの 1 つに、SSL/TLS クライアント認証を使用します。ユーザーは、ローカルクライアントの秘密鍵データベースに単一のパスワードを使用して一度ログインでき、ユーザーがネットワーク経由でパスワードを送信できなくなるすべての SSL/TLS 対応サーバーに認証されます。このアプローチでは、各新規サーバーにパスワードを入力する必要がないため、ユーザーのアクセスが簡素化されます。また、管理者はユーザーとパスワードのリストよりもはるかに長いリストではなく、認証局 (CA) のリストを制御することで、ネットワークの管理を簡素化できます。
証明書の使用に加え、ソリューションの完全なシングルサインオンは、パスワードやその他の認証形式に依存する基礎となるオペレーティングシステムなどのエンタープライズシステムとの対話を必要とする必要があります。
1.3.3.4. オブジェクトの署名
多くのソフトウェア技術は、オブジェクト署名 と呼ばれるツールセットをサポートします。オブジェクト署名は、公開鍵暗号化の標準的な手法を使用して、ユーザーがダウンロードしたコードに関する信頼できる情報を、パッケージソフトウェアに関する信頼できる情報を取得するのとほぼ同じ方法で取得できるようにします。
最も重要な点として、オブジェクト署名は、ユーザーとネットワーク管理者がイントラネットまたはインターネットを介して配布されるソフトウェアに関する決定を実装するのに役立ちます。たとえば、特定のエンティティーによって署名された Java アプレットが特定のユーザーのマシンで特定のコンピューター機能を使用できるようにするかどうかなどです。
オブジェクト署名テクノロジーで署名されたオブジェクトは、アプレットや他の Java コード、JavaScript スクリプト、プラグイン、または何らかのファイルです。署名はデジタル署名です。署名オブジェクトとその署名は、通常 JAR ファイルと呼ばれる特別なファイルに格納されます。
オブジェクト署名テクノロジーを使用してファイルに署名するソフトウェア開発者やその他の人は、最初にオブジェクト署名証明書を取得する必要があります。
1.3.4. 証明書の種類
Certificate System は、さまざまな用途、およびさまざまな形式で、さまざまな種類の証明書を生成できます。PKI インスタンスと Certificate System インスタンスの両方を管理するには、必要な証明書を計画し、必要な形式の決定や更新の計画方法など、証明書の管理方法を計画することが重要です。
LDAP ディレクトリー、ファイル署名証明書、およびその他のサブシステム証明書のデュアル用途証明書用の証明書登録フォームがあります。これらのフォームは、http
s://server.example.com:8443/ca/ee/ca の Certificate Manager のエンドエンティティーページから入手できます。
さまざまな Certificate System サブシステムがインストールされると、必要となる基本的な証明書とキーが生成されます。たとえば、 Certificate Manager を設定すると、自己署名ルート CA の CA 署名証明書と、内部 OCSP 署名、監査署名、SSL/TLS サーバー、およびエージェントユーザー証明書が生成されます。KRA 設定時に、Certificate Manager はストレージ、トランスポート、監査署名、およびエージェント証明書を生成します。追加の証明書を個別に作成してインストールできます。
表1.1 共通証明書
| 証明書の種類 | 使用 | 例 |
|---|---|---|
| クライアント SSL/TLS 証明書 | SSL/TLS 経由でサーバーへのクライアント認証に使用されます。通常、クライアントの ID は、従業員などの個人の ID と同じであると見なされます。SSL/TLS クライアント証明書がクライアント認証に使用される方法の説明は、「証明書ベースの認証」を参照してください。クライアント SSL/TLS 証明書は、シングルサインオンの一部として使用することもできます。 |
銀行は顧客に SSL/TLS クライアント証明書を提供します。これにより、銀行のサーバーはその顧客を識別し、顧客のアカウントへのアクセスを承認できます。
会社は、会社のサーバーがその従業員を識別してその会社のサーバーへのアクセスを承認できるようにする SSL/TLS クライアント証明書を新たに付与します。
|
| サーバー SSL/TLS 証明書 | SSL/TLS でクライアントへのサーバーの認証に使用されます。サーバーの認証はクライアント認証なしで使用できます。暗号化された SSL/TLS セッションには、サーバーの認証が必要です。詳細は、「SSL/TLS」を参照してください。 | 電子商取引を行うインターネットサイトは通常、証明書ベースのサーバー認証をサポートして、暗号化された SSL/TLS セッションを確立し、会社で識別される Web サイトを扱っていることを顧客に保証します。暗号化された SSL/TLS セッションは、クレジットカード番号などのネットワーク上で送信する個人情報を簡単に傍受できないようにします。 |
| S/MIME 証明書 | 署名および暗号化された電子メールに使用されます。SSL/TLS クライアント証明書と同様に、クライアントのアイデンティティーは従業員などのユーザーのアイデンティティーと同じであると仮定されます。1 つの証明書は S/MIME 証明書および SSL/TLS 証明書の両方として使用できます。「署名済みおよび暗号化電子メール」を参照してください。S/MIME 証明書はシングルサインオンの一部としても使用できます。 | S/MIME 証明書と SSL/TLS 証明書を組み合わせることで、従業員の ID 認証のみを許可するため、署名済み電子メールと SSL/TLS クライアント認証は許可されますが、電子メールは暗号化されません。別の企業が S/MIME 証明書を署名して暗号化し、機密や法規制を扱う電子メールに署名して暗号化します。 |
| CA 証明書 | CA を識別するために使用されます。クライアントおよびサーバーソフトウェアは CA 証明書を使用して、その他の証明書を信頼できるものを決定します。詳細は、「CA 証明書による信頼の仕組み」を参照してください。 | Mozilla Firefox に保存されている CA 証明書は、他の証明書を認証できるものを決定します。管理者は、各ユーザーの Firefox のコピーに保存されている CA 証明書を制御することで、企業のセキュリティーポリシーを実装できます。 |
| オブジェクト署名証明書 | Java コード、JavaScript スクリプト、またはその他の署名付きファイルの署名者を識別するのに使用されます。 | ソフトウェア会社は、インターネット上で配布されるソフトウェアに頻繁に署名して、そのソフトウェアがその会社の合法的な製品であることをユーザーに保証します。証明書とデジタル署名を使用することで、ユーザーはダウンロードしたソフトウェアが自分のコンピューターにアクセスできる種類を識別して制御することもできます。 |
1.3.4.1. CA 署名証明書
すべての Certificate Manager には、発行する証明書および証明書失効リスト (CRL) の署名に使用する公開鍵と秘密鍵のペアを持つ CA 署名証明書があります。この証明書は、Certificate Manager のインストール時に作成され、インストールされます。
注記
CRL の詳細は、「証明書の取り消しとステータスの確認」を参照してください。
Certificate Manager のステータスがルートまたは下位 CA として評価されるかどうかは、その CA 署名証明書が自己署名の証明書であるか、または別の CA により署名されているかにより決まります。自己署名ルート CA は、発行先名、発行可能な証明書のタイプ、証明書の発行先など、証明書を発行するのに使用するポリシーを設定します。下位 CA には、別の CA (通常は CA 階層の上位レベル (ルート CA である場合とそうでない場合があります)) によって署名された CA 署名証明書があります。Certificate Manager が CA 階層にある下位 CA の場合は、Certificate Manager を使用して証明書を発行する前に、ルート CA の署名証明書を個別のクライアントおよびサーバーにインポートする必要があります。
CA が発行するサーバーまたはユーザー証明書がそのクライアントにインストールされている場合は、その CA 証明書をクライアントにインストールする必要があります。CA 証明書は、サーバー証明書を信頼することを確認します。理想的には、証明書チェーンがインストールされています。
1.3.4.2. その他の署名証明書
OCSP (Online Certificate Status Protocol) レスポンダーサービスや CRL 公開などの他のサービスは、CA 証明書以外の署名証明書を使用できます。たとえば、別の CRL 署名証明書を使用して、CA 署名証明書を使用する代わりに CA によって公開される失効リストに署名できます。
注記
OCSP の詳細は、「証明書の取り消しとステータスの確認」を参照してください。
1.3.4.3. SSL/TLS サーバーおよびクライアント証明書
サーバー証明書は、SSL/TLS などの安全な通信やその他の安全な機能に使用されます。サーバー証明書は、操作中に自身を認証し、データを暗号化するために使用されます。クライアント証明書は、サーバーに対してクライアントを認証します。
注記
サードパーティーが署名証明書を発行した CA はサーバー証明書を発行できない可能性があります。サードパーティーの CA には、部下がサーバー証明書を発行することを禁止するルールが設定されている場合があります。
1.3.4.4. ユーザー証明書
エンドユーザー証明書は、サーバーまたはシステムにユーザーを識別するために使用されるクライアント証明書のサブセットです。ユーザーは、SSL/TLS などのセキュアな通信に使用する証明書や、電子メールの暗号化やシングルサインオンに使用するその他の機能に割り当てることができます。Certificate System エージェントなどの特別なユーザーには、特別なサービスにアクセスするためのクライアント証明書を指定できます。
1.3.4.5. デュアルキーペア
デュアルキーペアは、2 組の秘密鍵と公開鍵で、もう 1 つは署名用のセットで、もう 1 つは暗号化に使用されます。これらのデュアルキーは、デュアル証明書の作成に使用されます。デュアル証明書の登録フォームは、Certificate Manager のエンドエンティティーページにリストされている標準形式です。
デュアルキーペアを生成する場合には、署名と暗号化用に別の証明書を生成する際に、証明書プロファイルが正しく機能するように設定します。
1.3.4.6. クロスペアの証明書
Certificate System は、クロスペアの CA 証明書を発行、インポート、および公開できます。クロスペアの証明書では、1 つの CA が署名し、2 番目の CA に対してクロスペアの証明書を発行します。2 番目の CA は署名し、最初の CA にペアの証明書を発行します。その後、どちらの CA も crossCertificatePair エントリーとして両方の証明書を保存または公開します。
ブリッジ証明書は、ルート CA にチェーンされない CA が発行する証明書を許可するために実行できます。クロスペアの CA 証明書で、Certificate System CA と他の CA との間で信頼を確立することで、クロスペアの証明書をダウンロードして、他の CA が発行する証明書を信頼するために使用できます。
1.3.5. 証明書の内容
証明書の内容は、国際標準化団体である国際電気通信連合 (ITU) によって推奨されている X.509v3 証明書仕様に従って編成されています。
通常は、証明書の正確な内容について懸念する必要はありません。ただし、証明書を操作するシステム管理者は、証明書に含まれる情報にある程度精通している必要がある場合があります。
1.3.5.1. 証明書データの形式
証明書要求と証明書を作成し、保存して、いくつかの形式でインストールできます。これらの形式はすべて X.509 標準に準拠します。
1.3.5.1.1. バイナリー
以下のバイナリーフォーマットが認識されます。
- DER でエンコードされた証明書。これは、単一のバイナリーの DER でエンコードされた証明書です。
- PKCS#7 証明書チェーンオブジェクト。これは、PKCS #7 SignedData オブジェクトです。SignedData オブジェクトの唯一の重要なフィールドは証明書で、署名およびコンテンツなどは無視されます。PKCS #7 形式を使用すると、複数の証明書を一度にダウンロードできます。
- Netscape 証明書シーケンス。これは、PKCS #7 ContentInfo 構造で証明書チェーンをダウンロードする簡単な形式で、証明書のシーケンスをラップします。contentType フィールドの値は netscape-cert-sequence で、content フィールドには以下の構造があります。
CertificateSequence ::= SEQUENCE OF Certificate
この形式により、複数の証明書を同時にダウンロードできます。
1.3.5.1.2. テキスト
バイナリー形式はどれでもテキスト形式でインポートできます。テキストフォームは、次の行で始まります。
-----BEGIN CERTIFICATE-----
この行に従う証明書データで、上記のバイナリー形式のいずれかになります。このデータは、RFC 1113 で説明されているように base-64 でエンコードされる必要があります。証明書情報の後に以下の行を指定します。
-----END CERTIFICATE-----
1.3.5.2. 識別名
X.509 v3 証明書は、識別名 (DN) を公開鍵にバインドします。DN は、エンティティーを一意に識別する uid=doe などの一連の名前と値のペアです。これは、証明書の サブジェクト名 とも呼ばれます。
以下は、Example Corp の従業員の DN の例です。
uid=doe, cn=John Doe,o=Example Corp.,c=US
この DN では、uid はユーザー名、cn はユーザーの共通名、o は組織または会社名で、c は国です。
DNS には、さまざまな名前と値のペアを含めることができます。LDAP (Lightweight Directory Access Protocol) をサポートするディレクトリーの証明書サブジェクトとエントリーの両方を識別するために使用されます。
DN を構築するルールは複雑です。DN に関する包括的な情報は、http://www.ietf.org/rfc/rfc4514.txt の『A String Representation of Distinguished Names』 を参照してください。
1.3.5.3. 典型的な証明書
すべての X.509 証明書は、以下の 2 つのセクションで設定されます。
- データセクション
- 本セクションでは、以下を説明します。
- 証明書でサポートされる X.509 標準のバージョン番号。
- 証明書のシリアル番号CA が発行するすべての証明書には、その CA が発行した証明書間で一意のシリアル番号があります。
- 使用されるアルゴリズムや鍵自体の表現など、ユーザーの公開鍵に関する情報。
- 証明書を発行した CA の DN。
- 証明書が有効である期間。たとえば、2004 年 11 月 15 日の午後 1 時から、2020 年 11 月 15 日 午後 1 時まで。
- 証明書サブジェクトの DN。サブジェクト名とも呼ばれます。たとえば、SSL/TLS クライアント証明書では、これはユーザーの DN です。
- 任意の 証明書エクステンション。クライアントまたはサーバーによって使用される追加データを提供できます。以下に例を示します。
- Netscape Certificate Type 拡張は、SSL/TLS クライアント証明書、SSL/TLS サーバー証明書、メール署名用の証明書などの証明書のタイプを示します。
- SAN (Subject Alternative Name) 拡張が、証明書を 1 つ以上のホスト名にリンクします。
証明書拡張機能は、別の目的でも使用できます。
- 署名セクション
- 本セクションでは、以下を説明します。
- 独自のデジタル署名を作成するために CA の発行に使用される暗号化アルゴリズムまたは暗号。
- 証明書内のすべてのデータを一緒にハッシュし、CA の秘密鍵で暗号化することによって取得された CA のデジタル署名。
読み取り可能な pretty-print (整形表示) 形式で表示される証明書のデータセクションと署名セクションは次のとおりです。
Certificate:
Data:
Version: v3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Example Certificate Authority, O=Example Corp, C=US
Validity:
Not Before: Fri Oct 17 18:36:25 1997
Not After: Sun Oct 17 18:36:25 1999
Subject: CN=Jane Doe, OU=Finance, O=Example Corp, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Modulus:
00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
91:f4:15
Public Exponent: 65537 (0x10001)
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
TLS Client
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
26:c9
Signature:
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
d:c4
以下は、base-64 でエンコードされた形式と同じ証明書です。
-----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== -----END CERTIFICATE-----
1.3.6. CA 証明書による信頼の仕組み
証明書をサポートするクライアントまたはサーバーソフトウェアは、信頼できる CA 証明書のコレクションを維持します。これらの CA 証明書は、ソフトウェアが信頼または検証できる証明書の発行者を決定します。最も単純なケースでは、ソフトウェアは、証明書を持っている CA の 1 つによって発行された証明書のみを検証できます。信頼できる CA 証明書を CA 証明書のチェーンの一部にすることもできます。各証明書は、証明書階層の上位にある CA によって発行されます。
以下のセクションでは、証明書階層と証明書チェーンを使用して、信頼できる証明書ソフトウェアを決定する方法を説明します。
1.3.6.1. CA 階層
大規模な組織では、証明書を発行する責任を複数の CA に委任できます。たとえば、必要な証明書の数が多すぎて、単一の CA が維持できない場合があります。組織単位が異なれば、ポリシー要件も異なる場合があります。または、CA は、証明書を発行している人と同じ地理的領域に物理的に配置する必要がある場合があります。
これらの証明書発行の責任は、下位の CA 間で分割できます。X.509 標準には、CA の階層を設定するモデルが含まれています (例: 図1.6「認証局の階層の例」)。
図1.6 認証局の階層の例
ルート CA は階層の上部にあります。ルート CA の証明書は 自己署名証明書 です。つまり、証明書は、証明書を識別する同じエンティティーによってデジタル署名されます。ルート CA に直接従属する CA には、ルート CA によって署名された CA 証明書があります。階層内の下位 CA の下にある CA には、上位レベルの下位 CA によって署名された CA 証明書があります。
組織は、CA 階層の設定方法に多くの柔軟性を備えています。図1.6「認証局の階層の例」 では、例を 1 つだけ示します。
1.3.6.2. 証明書チェーン
CA 階層は証明書チェーンに反映されます。証明書チェーン は、連続する CA により発行された一連の証明書です。図1.7「証明書チェーンの例」 は、図1.6「認証局の階層の例」 に示される CA 階層に基づいて、2 つの下位 CA 証明書を介してルート CA の CA 証明書へのエンティティーを識別する証明書からそれに続く証明書チェーンを示しています。
図1.7 証明書チェーンの例
証明書チェーンは、階層のブランチから階層のルートへの証明書のパスを追跡します。証明書チェーンでは、以下が発生します。
- 各証明書の後に、その発行者の証明書が追加されます。
- 各証明書には、その証明書の発行者の名前 (DN) が含まれており、チェーン内の次の証明書のサブジェクト名と同じです。図1.7「証明書チェーンの例」 では、エンジニアリング CA 証明書には、その証明書を発行した CA (USA CA) の DN が含まれます。USA CA の DN はチェーン内の次の証明書のサブジェクト名でもあります。
- 各証明書は、発行者の秘密鍵で署名されます。この署名は、発行者の証明書内の公開鍵 (チェーン内の次の証明書) で検証できます。
1.3.6.3. 証明書チェーンの確認
証明書チェーンの検証では、特定の証明書チェーンが適切な形式で、有効で、適切に署名され、信頼できるものであることを確認します。以下のプロセスの説明は、認証用に提示される証明書から、証明書チェーンを形成および検証する最も重要な手順を示しています。
- 証明書の有効期間は、検証者のシステムクロックによって提供される現在時刻に対してチェックされます。
- 発行者の証明書が位置しています。ソースは、クライアントまたはサーバーのローカル証明書データベース、または SSL/TLS 接続と同様に、サブジェクトが提供した証明書チェーンのいずれかになります。
- 証明書の署名は、発行者の証明書の公開鍵を使用して検証されます。
- サービスのホスト名は、SAN (Subject Alternative Name) 拡張と照合されます。証明書にそのような拡張がない場合、ホスト名はサブジェクトの CN に対して比較されます。
- システムは、証明書の基本制約要件、つまり、証明書が CA であるかどうか、および署名が許可されている子会社の数を確認します。
- 発行者の証明書が検証者の証明書データベース内の検証者によって信頼されている場合、検証はここで正常に停止します。それ以外の場合は、発行者の証明書をチェックして、証明書タイプ拡張に適切な下位 CA 表示が含まれていることを確認し、チェーン検証をこの新しい証明書からやり直します。図1.8「ルート CA への証明書チェーンの確認」 は、このプロセスの例を示しています。
図1.8 ルート CA への証明書チェーンの確認
図1.8「ルート CA への証明書チェーンの確認」 は、ルート CA のみが検証機能のローカルデータベースに含まれる場合に何が発生するかを示しています。エンジニアリング CA など、中間 CA のいずれかの証明書が検証者のローカルデータベースにある場合は、図1.9「証明書 Chain の中間 CA の確認」 に示されているように、検証はその証明書で停止します。
図1.9 証明書 Chain の中間 CA の確認
有効期限が切れている、署名が無効である、または証明書チェーンのいずれかの時点で発行元 CA の証明書がない場合は、認証が失敗します。図1.10「検証できない証明書チェーン」 は、root CA 証明書も中間 CA 証明書も検証者のローカルデータベースに含まれていない場合に、検証がどのように失敗するかを示しています。
図1.10 検証できない証明書チェーン
1.3.7. 証明書の状態
証明書失効リスト (CRL) の詳細は、「CRL」を参照してください。
オンライン証明書ステータスプロトコル (OCSP) の詳細は、「OCSP サービス」を参照してください。
