この記事の表現は原書を基に私個人の理解としてまとめたものなので正確な意味合いでは誤謬は含まれているかもしれません。

公開鍵基盤（PKI : Public Key Infrastructure)の目的

全世界に存在する数百万台、数十億の人・デバイス間で安全な通信ができるように、公開鍵を管理（保管、失効など）し共有する仕組みを提供することです。さらにこれらの人・デバイスは以前は通信したことが無い相手同士な場合（そのままでは信頼できない相手）を想定されています。

インターネットPKIとは

PKIは本来、SSL,TLSなどとは違う目的で開発された技術であるためより広い意味合いを持ちます。このため、TLSの基盤としてのPKIを指す場合はインターネットPKI、と呼ぶ のがより適切です。インターネットPKIはPKIXネットワーキンググループがPKIをインターネットに適用するために策定したものです。
似た用語で Web PKI というのはより特化してウェブブラウザ―における証明書の利用と検証という側面に注目した表現です。

インターネットPKIの構成要素

PKIの目的はお互いに知らないもの同士が安全な通信を実現する事です。このために全員が無条件に信頼する証明書の発行をCA(認証局)と呼ばれる信頼のある第三者機関に委ねるモデルとなっています。
以下が全体概要です。

証明書所有者（Subscriber）

証明書を必要とする安全なサービスを希望している主体を 証明書所有者（Subscriber）と呼びます。エンド・エンティティ（End-Entity）とも呼ばれます。

RA（Registration Authority 登録局）

RA（登録局）は証明書の発行に関連したマネージメントを実行する事です。 例として 証明書を発行する際の本人性の検証などです。
RAがユーザーにより近い場所（例えば個別の国）に設置した支局等をRA：Rocal RA（ローカル登録局）と呼ぶこともあります。
実際にはCAの多くがRAの役割も果たしています。

CA：Certification Authority 認証局

証明書所有者の本人性を保証するものとして扱われます。この証明書を発行するのが信頼されたCAA：Certification Authority（認証局）です。
CAの役割の一つに証明書の失効についての最新情報をオンラインで提供することもあります。これは証明書利用者が証明書の有効性を検証できるようにするためです。

証明書利用者（Relying Party）

証明書を実際に使う利用者を証明書利用者（Relying Party）と呼びます。具体的には、証明書を検証するブラウザー等のプログラムやOSを指します。
ブラウザーやOSは**ルート・トラストストア（root trust store）と呼ばれる場所に格納された証明書を利用します。**ルート・トラストストアに格納されている証明書は厳選された特定のCAにより発行された者でありブラウザーやOSによっては絶対的な信用の基となります。このような信用の基となるCAをトラストアンカー（trust anchor）と呼びます。
証明書利用者はインターネット上で証明書を信頼して安全に通史を行う広義のエンドユーザーといえます。

CT：Cirtificate Transparency(証明書の透明性)、CTログ

CT：Cirtificate Transparency(証明書の透明性)は、PKIエコシステム全体で発生するイベントを監視できるように設計された仕組み です。エコシステムに参加しているCAが発行した証明書をCTログとして登録し、監査の目的で公開利用できるものです。

インターネットPKIにおける証明書が保証するもの

ほとんどの証明書の場合、証明書が保証するのは正しいサーバーとやり取りしているという保証だけです。言い換えると証明書がルート・トラストストアに含まれるCAによって検証可能である、ということでしかありません。
ですので証明書の所有者が必ず信頼できる、という意味ではありません。

日常生活で言うところの信頼、というものより保証されるものが非常に限定的、個別的だという点は認識すべき点かと思います。

証明書の標準 X.509

インターネットPKIの根幹はX.509で規定されています。
X.509はX.500という電子ディレクトリーサービス向けに設計されていましたが、その後PKIXワーキングループによりインターネット上での利用に適する形に整備されました。
PKIXワーキンググルーブのよるインターネットPKIの主要文書はRFC 5280です。RFC 5280では証明書のフォーマットと信頼パス（trust path)の構築、CRL（Certificate Revocation List 証明書失効リスト）を規定しています。 (PKIXワーキングループの作業完了は2013年10月)

筆者は(PKIXワーキンググループが策定した）標準と現実の間には齟齬があり、その原因のいったんは仕様が曖昧で現実のニーズに対応していないことがある、としています。くわえて実装する人たちが独自解釈した実装がデファクトになっている場合に本来の仕様から見ると間違った判断やバグがある事で本来の仕様では可能な機能が制限されてしまう場合もある（意訳）、としています。本書後半の様々なセキュリティ事例で説明します、とあります。

その後、CA/Brouwserフォーラム（CAB Forum）がEV証明書の発行に関する標準規定を発表しました(2007年)。
**CAB Forumは、2012年にBaseline Requirements（Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates）を発表しました。CAB Forumに参加するCAは約50ですが（原書執筆時点）,Base Requirements は事実上すべてのCAに適用されています。というのもBase RequirementsはCA向けの監査プログラムであるWebTrustに組み込まれており、ルートトラストストアを運用している団体によってはBasement Requirementsを明示的に要求する団体もあるからです。（例 Mozzilla）

X.509の証明書

X.509証明書には公開鍵と、その公開鍵に紐づけられる主体につての情報、証明書が本物であることの検証に使われるデジタル署名が１つまたは複数含まれています。

以下がX.509証明書の例です。（証明書のバージョンは1）

※引用元：Wikipedia:X.509 に加筆。

余談ですがウィキペディアにはちょくちょく助けて頂いており時々寄付しています。感謝。

Version

証明書の形式（バージョン1, 2, 3 のいづれか）を示します。
バージョン2では一意となるようなフィールドを2つ追加しています(Issur Unique ID, Subject Unique ID)が、バージョン3ではこの2つは廃止されています。代わりにバージョン3では拡張フィールドが利用できます。バージョン2の前述の2つのフィールドに対応するものとしてバージョン3ではAuthority Key Identifire拡張、Subject Key Identifire拡張があります。
原書執筆時点でほとんどの証明書はバージョン3とのことです。

Serial Number

あるCAが発行した証明書を一意に識別するための番号。 元来は正の整数からなるシリアル番号を利用していました。しかし、証明書の署名に対する選択プレフィックス衝突攻撃が発生したため、シリアル番号にはその防御の役割も兼ねて、現在では連番ではなく、少なくとも20ビットのエントロピーを有する予測不能な値がシリアル番号にセットする事が要求されています。

Signature Algorithm（証明アルゴリズム）

証明書の署名に使用しているアルゴリズムを示します。証明書の内部のフィールドとして格納されており、この情報は署名で保護されています。

Issure（発行者）

証明書を発行した主体のDN名（Distinguished Name 識別名）です。
上図の例においては以下の様になっています。

C=ZA 国 （南アフリカ）
ST=Western Cape 州（西ケープ州）
L=Cape Town 市（ケープタウン市）
O=Thawte Consluting cc 企業
OU=Certification Service Division 組織
CN=Thawte Server CA/emailAddress=server-certs@thawte.com Common Name

Validity（有効期間）

この証明書の有効期間を記述。開始日時と終了日時を記載。開始日時・終了日時それ自体の時刻まで有効な期間に含まれます。
仮に開始日時と終了日時が同一の証明書がある場合、この証明書の有効期間は1秒になります。

Subject（主体者）

証明書の発行を受けた者の公開鍵に紐づくDN名（Distinguished Name）が格納されます。

SubjectフィールドのDNとIssureフィールドのDNが同一で、自身の鍵ペアによって署名されている証明書は自己署名証明書と呼ばれます。

また、以前はDN Distinguished Nameの一部である Common Name(CN) にサーバーのホスト名をセットしていました。例としてwww.ibm.comの有効な証明書はSubjectフィールドのDNに /CN=www.ibm.com が含まれていました。しかしこの方法は複数のホスト名に対して発行された有効な証明書で混乱を招いたため現在では使用されていないそうです。
代替として後述の SAN Subuject Alternative Name という拡張を利用します。

SubjectPublicKeyInfo SKPI 主体者の公開鍵

主体者の公開鍵はSKPI Subject Public Key Info フィールドに格納されます。
このフィールドはアルゴリズムの識別子、公開鍵、オプションのパラメーターから構成されます。

Baseline Requirementsではパブリックな公開鍵のアルゴリズムとしてはRSA,ECDSA,EdDSAが記載されています。

X.509証明書バージョン3での拡張

この章は以下のページを参考にさせて頂きました。感謝
電子証明書拡張情報のデータ形式　トラスト・ソフトウェア・システム

X.509 証明書の拡張情報はRFC 5280で規定されているものが多いようですが、それぞれの拡張のデータ形式は規定上の指定が無く、個々の実装に依存しています。RFCで決められている拡張情報のフォーマット例は以下です。

Extentions ::=SEQUENC SIZE (1..MAX) OF Extention

Extention ::= SEQUENCE {
    extntID    OBJECT IDENTIFIRE,
    critical  BOOLEAN DEFAULT FALSE,
    extntValue ... (ASN.1で構成されたデータ）

extntID　： OID（object identifier）と呼ばれる識別子
critical ：この値がTRUEの場合、この証明書を利用するシステムは
　　　　　　　必ずこの拡張を処理する必要がある。処理できない場合は
　　　この証明書ごと破棄しなければならない
extentValue ： ASN.1で構成されたデータ

以下、拡張の例です。

AIA：Authority Information Access（認証機関アクセス情報）

証明書を発行したCAにより提供されている付加的な情報やサービスへのアクセス方法を示す。例として証明書利用者が失効情報をリアルタイムに確認できるように OCSPレスポンダーの場所（URI）を示すために使われます。他には、発行者の証明書を取得できるURLを記載して不完全な証明書チェーンを再構築する際の情報として利用できるようにしている証明書もあります。

Authority key Identifier（認証局鍵識別子）

証明書の署名に使われた鍵を一意に特定する識別子を指定するために使う拡張。証明書チェーンを構築する際に親の証明書を識別するための情報として利用できます。
RFC3280に従った証明書はこの拡張を含むことを要求しています。ただし、この拡張は criticalであってはいけません。

Basic Constraints（基本制約）

この証明書のSubject（主体者）がCAであるか否かを示します。またSubjectがCAの場合証明書チェーンにおいてこの証明書の下位に何段階まで（中間証明書となる）CA証明書を発行できるかを指定します。

例はこちら

id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19}

BasicConstraints ::= SEQUENCE {
    cA                BOOLEAN DEFAULT FALSE
    pathLenConstraint INTEGER (0..MAX) OPTIONAL }

CA値は認証された公開鍵がCA発行のものかどうかを示します。CA値がTRUEの場合CAが発行した証明書であることがわかります。pathLenConstraint はこの証明書の下位に最大いくつのCA証明書を発行できるかを指定しています。

CA発行の証明書は本来、必ずこの拡張を含まなければなりませんが、実際にはこの拡張が含まれないバージョン1の証明書として発行されているルート証明書も依然として利用されています。（原著執筆の2016年頃の情報）

Certificate Policies（証明書ポリシー）

この拡張には1つまたは複数のポリシーを格納しまう。各ポリシーはOIDおよび限定子（こちらはオプション情報）で構成されます。限定子には通常ポリシーの全文を取得できるURIが指定されます。
Baseline Requirementsではエンドエンティティ用の証明書（リーフ証明書）には1つ以上のポリシーを必ず含めBaseline Requirementsに準拠して発行していることを示さなければならないとしています。また、この拡張で証明書の検証の種類を指定することもできます。

CRL Distribution Points（CRL配布点）

CRL（Certificate Revocation List 証明書失効リスト）の場所を示すための拡張。CRLの場所は通常はLDAPやHTTPのURLで示されます。Baseline Rquirementsでは証明書にはCRLまたはOCSPいずれかで失効情報を提示することとしています。

CT posion

CAがCTに準拠した証明書を発行する場合、一般にはプレ証明書（precertificate）を作成し、プレ証明書に対するCTログの署名をいくつか追加して本来発行したい証明書を作成します。プレ証明書にも本来の証明書とほぼ同等の内容がX.509と同じ構造でふくまれていることから誤ってプレ証明書が実際の証明書として扱われないようにするために使われます。この拡張はcritical （処理が必須）です。

CT Signed Certificate Timestamp（SCT）

CTのポリシーに従うクライアントが証明書が信頼できるか判断するためにその証明書がCTログに含まれていることの証明を入手する必要があります。この証明をSCTと呼びプレ証明書または証明書のタイムスタンプが使われ、SCT拡張にセットされます。

Key Usage（鍵用途）

証明書に含まれる鍵の用途を規定する拡張です。例としてCA証明書の場合、用途としてCertificate Signer（証明書の検証用）、CRL Singer（CRLの署名の検証用）を設定します。

EKU Extend Key Usage（鍵拡張用途）

公開鍵の用途をOIDによって指定できる拡張です。例としてBaeline Requirementsでは中間証明書にはハードコードされたドメイン名に対してのみ証明書を発行する、というガイドがありこのためにEKUとName Constraints(後述）拡張を使う事を要求しています。この際のEKUのOID例としてはid-kp-serverAuthやid-kp-clientAuthがあるようです。
RFC5280ではエンドエンティティ用のリーフ証明書に対してのみEKUを使うべき、とありますが、実際には中間CAの発行した証明書でも用途を制限するために使われています。

Name Constraints（名前制約）

たとえばある企業が自社ドメイン名に対してのみ証明書を発行できる下位のCAを作りたい場合に、ルートCAが証明書にName Constraints拡張を使用してこの企業名の身に有効なCAを発行する、という事が考えられます。
RFC5280ではName Constraints拡張はCriticalとされていますが、実際の運用上ではName COnstraints拡張が解釈できない場合証明書そのものが破棄されてしまうためcriticalとして扱空ないケースもあるようです。

Subject Alternative Name（主体者の別名）

従来は主体者 Subject と公開鍵の結び付けは証明書のSubjectフィールドのCNの値が利用されていましたが、この方法だと主体者 Subjectの指定はホスト名単位になってしまうことと、RFCとして複数の主体を扱う方法も規定されていないことから実用面で不便な場合があります。そこでSubjectフィールドの代わりにDNS名、IPアドレス、URI、その他識別子を指定して複数の主体者と公開鍵を結びつけられるよう、このSubject Alternative Name を使用します。

Subject Key Identifire（主体者鍵識別子）

ある公開鍵を使って証明書は複数（無数）に作成できてしまいますが、これらの個々の証明書を一意に特定できる値をSubject Key Identifire に指定します。Subject key Identifire拡張はCAが発行する証明書にはすべてに含まれている必要があります。またその値はCAが発行済みの全ての証明書のAthority Key Identirire拡張に含まれている識別子と同じでなければなりません。
Suject key Identifireに指定する値（識別子）は公開鍵そのものからハッシュ化などで導出する事が推奨されています。

証明書フォーマットの変遷

X.509の証明書の遠いご先祖としては、ASN.1（Abstract Syntax Notation One）があります。ASN.1は1998年にX.208という標準で規定されました。（その後、ITUのX.680シリーズの文書で規定されました。）
ASN.1はマルチプラットフォーム間での複雑なデータ構造・オブジェクトの送受信を可能とする規則で、特定のアーキテクチャーや言語に依存しない設計でした。
ASN.1で規定するデータは抽象的な形式な為、そのデータをエンコードする為の方法がいくつか標準化されました。最も古いASN.1データのエンコード標準がBER（Basic Encoding Rlues）です。BERのサブセットとして ASN.1の値を常に1通りにエンコードできる仕様としてDER（Distinguished Encoding Rules）が作られました。暗号、とくにデジタル署名ではエンコードした値が常に1通りでないと困るのでx.509ではDERが利用されます。

さらにDERをbase64でACSII形式でエンコードしたものをPEMと呼びます。　PEMはPrivacy-Enhanced Mailの略ですが特に意味はありません。

PEMフォーマットはメール送付やコピペが容易な為、証明書ではよく利用されています。一部ではDERフォーマットも利用されています。これらのフォーマット変換をしたい場合は、OpenSSLの x509コマンドを使用します。

ASN.1、X.509証明書を調べるツール類

・OpenSSL asn1parseコマンド　：　証明書の中身を調べる
・ASN.1 デコーダー　　　　　　：　オンラインでASN.1のデータをデコードできる
・der-asciiプロジェクト　　　： DERフォーマットの解析鶴、再構成ツールを公開