X509証明書の理解がある方は手を上げてください。誰も手を上げていないことがわかったので、それを変えましょう。
証明書は複雑なトピックであり、理解されていないことが多いです。このチュートリアルでは、X509証明書の例を示し、PKI証明書などを説明します。
この記事では、X509証明書の概要を把握することができます。記事の最後まで、専門家にはなれませんが、少なくとも適切な用語にはなじんでいるでしょう。
関連記事：Windows証明書マネージャーとPowerShellで証明書を管理する方法
公開鍵と秘密鍵：資産の保護
X509証明書を説明するためには、まず鍵について触れることが不可欠です。おそらく、鍵という概念を聞いたことがあり、秘密鍵や公開鍵などの用語が出てきたことがあるかもしれません。しかし、具体的には何が鍵であり、それが証明書とどのように関連しているのでしょうか。
関連を理解しやすくするために、古風なドアの鍵を例に説明しましょう。
新しいドアの鍵を購入すると、その鍵にはドアに対応した専用のものが付属しています。他の人がそれを開けることはできないように、その鍵はそのドアに対して固有のものです。
ロック自体を公開鍵と考えてください。インストールされると、あなたや家族、通行人はドアに取り付けられたロックを見ることができます。誰でも見ることができ、開けようとすることもできますが、成功することはありません。ロックを開けるには、元々ロックと一緒に付属していたユニークなドアキーを挿入する必要があります。ロックと一緒に付属していたユニークなキーを秘密鍵と呼びます。
秘密鍵と公開鍵は一緒にキーペアとして参照されます。
キーの交換
ドアキーがロックに挿入されると、それはキーの交換と考えることができます。ドアキー（秘密鍵）は公開鍵（ロック）と交換される必要があり、それによってドアが開けられます。
暗号化の世界では、公開鍵は自由に公開し、秘密鍵は自分自身だけが保持するものとします。結局のところ、誰がロックを見るかは気にしませんが、ロックを開けることができる人（キーを交換する人）には気を付けます。
キーの交換にはいくつかの異なる方法があり、キー交換アルゴリズムと呼ばれます。キー交換アルゴリズムは、独自の共有秘密を派生させ、安全に送信することに焦点を当てています。
あなたが聞いたことがあるかもしれない2つの人気のあるキー交換アルゴリズムはディフィーヘルマン(DH)と楕円曲線ディフィーヘルマン(ECDH)です。
キーの信頼性
誰かにドアを通って入るようにする必要がある場合、彼らに鍵（または元のユニークな鍵のコピー）を渡します。鍵はあなたが信頼している人にだけ与えます。秘密鍵（ドアキー）を持つ人は、ドアロック（公開鍵）を信頼されているとされます。
キーの使用
キーの使用法は、X509証明書の目的を定義し、証明書が使用するアルゴリズムに合致します。拡張キーの使用法（EKU）は、キーの使用法を超えた公開キーの意図された目的を定義します。
X509証明書：公開キーの「コンテナ」
秘密鍵と公開鍵は、X509 証明書の概念とどのように関連していますか？証明書は単純に公開鍵と考えてください。証明書は、公開鍵と公開鍵が発行された相手、公開鍵を署名した者など、キーに関する他の情報を含む「囲い」です。証明書はファイルとして保存されます。
後でいくつかの良いX509証明書の例を説明します。
PEMやCERの証明書ファイル拡張子を持つファイルを見たことがありますか？それらは証明書（公開鍵）です。これらの形式については、後で詳しく説明します。
単体の公開鍵自体は、定義上証明書ではありません。公開鍵と関連する属性データが組み合わさることで、証明書が定義されます。
A certificate provides a standardized and secure format to communicate with specific systems along with the attributes to help validate a key pair trust. How certificates are built are defined within the X.509 standards, as you will read about later.
サムプリント：証明書の一意の識別子
各X509証明書は、単一の主体の識別を提供することを意図しています。証明書は、各公開鍵が一意に識別可能であることを確保する必要があります。
A certificate thumbprint or fingerprint is a way to identify a certificate, that is shorter than the entire public key. Technically, a serial number is as well but you’ll learn about that when it comes to certification authorities (CAs). The thumbprint is a hash of a DER-encoded certificate in Windows.
より大きなデータセットを、より小さな一意の識別子によって識別する概念は、指紋認識という一般的なコンピューティングのトピックです。 Morgan Simonsonのブログでは、さらに詳しく説明されています。
件名：重要なX509証明書属性の定義
すべてのX509証明書には、固有の識別子だけでなく、以下のような質問に答える必要があります。証明書のサブジェクトはまさにそのためのものです。
- この証明書を使用するのは誰ですか？
- どの組織が信頼されるべきですか？
- どのユーザーがこの証明書を提示する必要がありますか？
サブジェクトは、証明書の最も重要な部分と言えます。サブジェクトは、証明書が発行される対象を表すX.500によって定義された属性を持つことが意図されています。これは、識別名（DN）形式で表されます。
A certificate subject is a string value that has a corresponding attribute type. For example, the DN for State or Province is st. This attribute type contains the full name of the state or province the subject resides in (e.g. ST=California).
これらの属性タイプと値の形式は、ITU-T X.520の勧告によって定義されています。特定の属性タイプと値の形式に関する具体的な勧告については、RFC 4519も参照してください。
X509証明書の標準はルールではなく、強力な提案ですので、多くの人々はサブジェクトを定義する際に自分自身の判断を用います。サブジェクトは、信頼するエンドエンティティを特定することが求められています。もしサブジェクトがこれを表していなければ、提示された公開鍵を使用して何を信頼できるでしょうか？
別の言い方をすれば、複数の人が同じユーザー名を使用してシステムにアクセスすることを許可すると、特定の人物に責任を負わせることはできません。このような慣行は、証明書が整合することを目指している信頼モデルを複雑にします。
WindowsがX509証明書、特に証明書のサブジェクトをどのように表現しているかは、以下のスクリーンショットで確認できます。
Cryptext.dllを使用して証明書の属性を表示します。
サブジェクトの代替名（SAN）
A SAN is a certificate extension that allows you to use one certificate for multiple subjects that’s typically identified with a Subject Key Identifier (SKI). The example below shows some of the SANs Google uses. Adding more domains to a certificate essentially tells the certificate to trust each subject to use the same private key.
A SAN can also have several types other than DNS names called GeneralNames. GeneralNames require the client reading the certificate to support SANs using GeneralNames. Most clients such as web browsers only focus on the DNS name SAN.
次のX509証明書の例でSANを確認できます。
Googleの証明書に関連付けられているいくつかのSAN属性。
エンコーディングの理解
私たちはお互いとコミュニケーションするために多くの言語を使用していますが、同様にコンピュータにも独自の言語があります。この言語はバイナリであり、異なるエンコーディング方法を使用してバイナリを他の人が利用できる形式に変換しています。まるで英語を他の言語に翻訳するようにです。
エンコーディングには特定の目的があります。エンコーディングにより、人が読める形式の拡張値をコンピュータも使用できるように保存することができます。エンコーディング形式により、コンピュータがX509証明書を簡単に保存および転送できるだけでなく、その内容を読むこともできます。
コンピュータは整数での処理に適していますが、エンコーディングを使用すると、数値を英数字またはバイナリのブロブに変換できます。この変換はコンピュータとの作業において重要であり、証明書はエンコーディングを利用して正しい情報をコンピュータに適切に伝えるために依存しています。エンコーディング形式は、これらの変換を実行するための標準を定義しています。
- ASN.1 – Abstract Syntax Notation One（ASN.1）は、証明書内の各フィールドのシリアライズ形式です。
- ASCII – アメリカンスタンダードコード for情報交換（ASCII）は、ほとんどの人間が読める通信に使用されるコンピュータ制御文字と印字可能文字のために、各バイナリ値を定義しています。
- Base64 – Base64は、ASCII文字集合内でバイナリコンテンツをエンコードするための方式を定義しています。これらは、テキストエディタで開くことができ、”BEGIN CERTIFICATE”または他の参照テキストが表示される証明書です。
- DER – Distinguished Encoding Rules（DER）は、ASN.1データのための別のエンコーディング方式を定義しています。DERの重要な考慮事項は、エンコードされた出力がASCIIとして表示できないことです。
以下では、エンコーディング方式の違いが見られます。最初に表示されるcertificate.crtファイルは、——-BEGIN CERTIFICATE——-というテキストで始まり、いくつかのランダムな文字と数字が続き、——-END CERTIFICATE——-で終わります。すべての文字は人間が読めます。最初の証明書はBase64でエンコードされています。
次に、certificate.cerファイルの2番目の例を見てみましょう。このファイルの内容は、Base64証明書とはかなり異なっています。このX509証明書はDERでエンコードされています。
Base64とDERでエンコードされたファイルの違い。
X509証明書ファイルタイプの理解
証明書は、ファイルとして表されるメタデータを持つ公開鍵にすぎません。さまざまな種類の証明書を表すさまざまな種類のファイルが存在します。各種類のファイルは、拡張子によって区別されます。たとえば、KEYファイルという場合、その拡張子を指しています。
以下に、よく使用される証明書の一般的な種類とその目的が示されています。
以下のリストでは、PKCSという用語がさまざまな場所で使用されていることに注意してください。PKCSまたはPublic Key Cryptography Standardsは、さまざまな証明書の作成方法を定義するための一連の標準です。詳細については、この情報提供のウィキペディア記事をご覧ください。
- PFX – これらはWindows環境で最も一般的に見つかりますが、オペレーティングシステムに関係なく標準形式です。PFXファイルには、証明書、公開鍵および拡張機能、およびパスワードで暗号化された秘密鍵が含まれています。PFXはPKCS＃12標準で定義されています。
- P12 – PFXと同様、P12もPKCS＃12標準で定義されています。形式的には、PKCS＃12はPFX形式の後継ですが、どちらのファイルタイプも現代の暗号化実装で同じ形式を表します。
- P7B – ASN.1証明書のコンテナであり、以下で説明する証明書機関チェーンのすべての階層の公開鍵を提供します。PKCS＃7ファイルは、複数の公開鍵を分散するための単一のファイルを提供し、プライベートPKI内のCAとの信頼関係を手動で設定するためによく使用されます。
- P7C – P7Cファイルタイプは、機能的にはP7Bと同じですが、PKCS＃7ファイルを表すために使用されるもう一つの一般的な拡張子です。
- DER – DERファイルはDERエンコードされた公開鍵です。
- CER – 公開鍵はDERまたはBase64でエンコードされます。CERファイルは通常DERエンコードされます。
- CRT – CRTは通常Base64でエンコードされますが、保証はありません。
- KEY – KEYファイルは、暗号化されているかどうかに関係なく、通常Base64でエンコードされた秘密鍵です。
- PEM – Base64でエンコードされた証明書への参照です。ただし、複数のキーを1つのPEMファイルに含めることもあります。通常、PEMファイルには秘密鍵が含まれていることが想定されます。最も一般的には、PEM Base64でエンコードされた秘密鍵ファイル（暗号化されているかどうかに関係なく）に使用されます。
- CSR – 公開鍵をCAに送信して署名され、シリアル番号などの追加フィールドが含まれるようにするために使用されるもので、PKCS＃10で定義されています。ほとんどの場合、CSRにはBase64エンコードされたリクエストのASN.1構造が含まれます。
- REQ – Windows内で使用され、CSRを生成する際に使用される登録ポリシー設定を指定するために使用されます。
- CRL – CRLは、CAによって失効された証明書、その失効状態、および失効の理由をリスト化した特定のファイルです。
公開鍵インフラストラクチャ（PKI）：X509証明書エコシステム
以前、誰かがドアロックの鍵を持っていたときを思い出してください。その場合、あなたは単一のドアしか持っていませんでした。しかし、突然数十、数百のアパートの大家になった場合はどうなるでしょうか？すべてのドアの鍵を管理するのは大変です！
また、入居者は永遠にそのアパートに滞在するわけではありません。鍵を持ち続けたり、不正なコピーを作ったりする人もいるでしょう。アクセスを防ぐためにドアロックを変更する必要があります。以前の入居者を信頼できなくなったのです。
数百のアパートを常に出入りする入居者で管理する必要がある場合、どのようにそれを管理しますか？その答えが公開鍵基盤（PKI）です。
PKIは、公開鍵を管理するために構築された役割、ポリシー、手順など、すべてを包括するエコシステムです。PKIは、X509証明書を配布、使用、管理、削除するために必要なすべての要素を提供します。つまり、証明書を適切に処理し管理するために必要なすべての要素を提供します。
次のセクションでは、PKIの最も一般的なコンポーネントの多くを分解し、各コンポーネントの役割を説明します。
証明機関（CAs）：あなたの親
A PKI is primarily built around the concept of managing trust. But since it’s not economical to directly manage hundreds or thousands of trust relationships, you need a mediator.
元の当事者によって保証された第三者が必要です。これらの第三者仲介者は証明機関（CAs）と呼ばれ、与えられた証明書に署名するために使用される公開鍵から派生した権限キー識別子（AKI）拡張子によって識別されます。証明機関（CAs）
あなたが子供の頃、X509証明書として考えてみてください。おそらく、あなたの両親から見知らぬ人を信用しないように教えられたでしょう。しかし、もし両親（あなたが信頼している人々）があなたを見知らぬ人に紹介し、「その人を信頼してもいい」と言ったらどうでしょうか？おそらくあなたはそれに従い、その見知らぬ人を信頼するでしょう。なぜなら、両親がその人を信頼しているのなら、あなたも信頼できるからです。
A CA plays the role of your parents. You trust your parents (a CA) and they introduce you to strangers. They do so by signing the stranger’s public key to let you know that you can trust them.
CAの主な役割は、信頼できる調停者としての役割です。
X509証明書の発行：信頼の確立
知られた信頼できる存在であることにより、CAは間接的な関係者間の信頼を可能にします。パーティ間の信頼を実現するために、CAは「証明書」を「発行」します。ここでの「発行」とは、CAが要求された拡張を検証し、CAが生成した拡張を証明書に追加することを意味します。
CAがX509証明書を発行する際には、独自の秘密鍵を使用して証明書の公開鍵にデジタル署名をします。署名プロセスを通じて、CAはこの公開鍵を信頼していることを示すように証明書にマークを付けます。DocuSignは、この特定の概念について良い概要と良い図を提供しています。こちらを参照してください。
CAによって生成される拡張の別の例は、各証明書のシリアル番号であり、各シリアル番号はRFCの設計仕様によれば、そのCAに対して一意である必要があります。
現代のニュースにおける意図せぬ信頼の例として、マルウェアを悪用した公開鍵証明書の悪用があります。作成者は有効な証明書を受け取り、ほとんどのシステムで暗黙的に信頼されるため、あなたのシステムがマルウェアバイナリを悪意のあるものとして識別するのがより困難になります。
X509証明書の失効：信頼の削除
CAは、信頼できなくなったX509証明書の失効も責任を持っています。これらの失効はCAによって証明書失効リスト（CRL）に公開されます。失効は、CAが証明書を有効期間が終了するまで待つのではなく、積極的に無効化する方法です。
証明書が設計通りに機能するためには、信頼が重要な要素です。配布ポイントは、証明書と失効リストを発行元からダウンロードし、使用している証明書と比較するための参照ポイントを提供することで信頼を確保するのに役立ちます。
A CRL Distribution Point (CDP) supplies the protocols and locations to obtain CRLs. Updating CRLs is a passive revocation validation method, with pulling updates at scheduled intervals. Online Certificate Status Protocol (OCSP) actively requests the revocation status of a specific certificate by maintaining caches of the CRLs.
CRLやOCSPを介した失効の検証は利用可能ですが、クライアントがサポートして強制する必要があり、常にそのようなケースではありません。
階層化
A PKI can be made up of multiple CAs or a single CA, these are commonly referred to as tiers.
X509証明書チェイニング
前述したように、証明書を使用する際に信頼は重要な焦点です。関係者は信頼できるCAによって発行された証明書を信頼または検証できる必要があります。
A great example of how this scales is the The United States Federal PKI public documents. These provide a great reference into maintaining an inter-organization trust relationship using CAs.
X509証明書の署名
証明書の署名という概念をよく耳にしますが、それは具体的に何を意味するのでしょうか？先に学んだ通り、証明書は信頼に関するものです。信頼を確立するために、X509証明書はCAによって署名されます。証明書に署名することは、証明書に一意の暗号ハッシュを割り当て、それを読むすべての関係者に対して信頼できることを伝えるものです。それは信頼できるCAによって署名されました。
PKIの階層では、証明書はCAによって署名されますが、それらの証明書がどのように使用されるかは、どの種類のCAがそれらに署名するかによります。
PKIに単一のCAが存在する場合、そのCAがルートとなります。他のCAが存在しないため、そのCAは自己署名証明書を生成する必要があります。そのCAは、自分自身の証明書に署名して証明書を発行します。
PKIに複数のCAがある場合、すべてのCAはルートCAまたはルートCAに遡る中間CAによって署名されます。
通常、デバイスがX509証明書を生成する際に、公開鍵に対応する秘密鍵を使用する場合、これは自己署名証明書として知られています。ただし、CAに自身の秘密鍵を使用して証明書に署名してもらうこともできます。
署名アルゴリズム
署名アルゴリズムは、リモートの相手からのメッセージの信頼性を検証することに焦点を当てています。デジタル署名は、ハッシュ関数からのメッセージダイジェストを送信者の秘密鍵で暗号化したものです。受信者は、送信者の公開鍵のコピーを使用してデジタル署名を復号化します。受信者は、受信したメッセージのダイジェストとデジタル署名から復号化したダイジェストを比較することができます。ダイジェストが一致する場合、メッセージの信頼性は有効です。
非対称暗号化は、事前に知られている秘密を使用せずに暗号文を生成する能力です。鍵交換アルゴリズムと署名アルゴリズムの組み合わせが非対称暗号化の基礎です。
以下はデジタル署名に使用される主要なアルゴリズムです。
- Rivest–Shamir–Adleman (RSA)
- Digital Signature Algorithm (DSA)
- Elliptic Curve DSA (ECDSA)
Certificate Signing Requests (CSRs)
発行CAは、クライアントが公開鍵をCAに提出できるようにするために、証明書署名リクエスト（CSR）を使用します。CAはCSRを受け入れ、設定された発行ポリシーに基づいて署名されたX509証明書を発行します。つまり、信頼するCAは、その署名する公開鍵にも信頼を含むことを意味します。
ハッシング
ハッシングは複雑なトピックであり、この投稿では正確に説明することはできません。ComputerphileチームのYouTubeチャンネルには、良い概要があります。ハッシングは、入力オブジェクトを取り、そのユニークな入力に対して一意の出力ハッシュを作成することに焦点を当てています。出力ハッシュはダイジェストとして知られています。つまり、入力オブジェクトをわずかに変更すると、異なる一意で関連のないダイジェストが作成されます。
現代の実装では、セキュアハッシュアルゴリズム（SHA）2アルゴリズムに焦点を当てます。注意点として、SHA 256、SHA 384、SHA 512はSHA 2として知られています。
以下は、よく見かける一般的なハッシュアルゴリズムのリストです。
- SHA 256
- SHA 384
- SHA 512
- メッセージダイジェスト（MD）5
証明書ポリシー
証明書ポリシー（CP）拡張子は、CAを維持する組織への参照を提供し、与えられたPKIの実際のポリシーを記録し、与えられたPKIの維持に関する組織のポリシーを提供する認証実践声明（CPS）として整合されるべきです。
配布ポイント
証明書内で識別される配布ポイントの別のタイプは、Authority Information Access（AIA）です。これらのAIAは、証明書発行者の情報のコピーを取得するためのプロトコルと場所を提供します。最も一般的には、発行CAの公開鍵を指します。
概要
おそらく、この記事の冒頭で質問されたような質問に対して、手をゆっくりと上げることがより自信を持ってできるようになったでしょう。しかし、率直に言って、この記事がX509証明書の複雑さやWindowsの実装について理解を深めるのに役立ったことを願っています。これにより、証明書を扱う際に役立つ基本的なコンポーネントのいくつかを理解できるようになります。
少なくとも、今では誰かが証明書の公開鍵を求めるときに、DER形式またはBase64エンコード形式のいずれかが必要であることを確認できます。相手にはわからないので、両方を送信することになります。