LPIC-303 新版ノート331.1 X.509 / PKI / v67 Mobile Sheet Fix
← 332.2 Host IDS
全体進捗·Checkpoint
331.2 TLS / X.509 Auth →
LPIC-3 Security303-300 v3.0Weight 5実践深度を再設計9 themes / 14 pages

331.1 X.509 Certificates and Public Key Infrastructures

331.1は9テーマで学ぶ。初学者向けの橋渡しはテーマ内へ統合し、全14学習ページで「理解→設定→操作→状態変化→出力→失敗判断」までつなぐ。

監査方針：LPI 303-300 v3.0の331.1と突合し、掲載するOpenSSL実習はRoot→Intermediate→Server/Client→Chain→Revocationまで実動作確認する。
331.1の最終到達点
暗号の最低限から始め、OpenSSLで鍵を生成・管理し、CAを構築・保護・運用する。Server/Client CertificateをCSRから発行・管理し、Trust Chainを検証し、Certificate/CAを失効できる。X.509 fields/extensions、Certificate Transparencyを理解し、Let's Encrypt / ACME / Certbot / CFSSLを識別する。
Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は 末尾の問題へ。
01 PKI全体像02 X.509証明書03 鍵と形式04 CSR05 CA構築06 証明書発行07 Trust Chain08 失効09 CT / ACME系
構成について：331.1の学習テーマは当初設計どおり9テーマ。初学者向けに一度に詰め込まないため、9テーマを必要に応じて全14ページへ分けている。ページ数は学習上の分割であり、14個の独立した試験項目があるわけではない。

🟡 Understand

図→原理→実出力で判断できるまで。

🔴 Generate / Manage / Operate

操作を省略しない。成功例だけでなく状態変化・失敗例も扱う。

🔵 Basic feature

役割と関係を識別。操作量を膨らませない。

境界：TLS Handshake / Apache mod_ssl / SNI / HSTS / OCSP Staplingは331.2。ここではCertificate/PKIそのものを完成させる。
DESIGN RULE

「図だけで7〜8割」は実践項目には使わない

  • 図：構造確認
  • 実践：設定・操作・出力・失敗時判断が本体
  • Awareness/Basic featureだけは図・比較中心でよい
← 332.2 Host IDS初学者向け前提から開始 →
331.1 · 01/1401 PKI全体像
初学者前提PKI prerequisite

PKI全体像：暗号の最低限からCertificate Lifecycleまで

このページの到達点：Public/Private Key・Hash・署名の最低限を理解し、CA・Certificate・Trust Chain・Lifecycleまでを一続きで説明できる。
このページの位置付け：公式331.1の追加出題項目ではなく、公式内容をゼロから理解するための前提整理。
PKIに必要な暗号だけ先に
Data ↓ Hash function Hash（内容から作る短い値） ↓ Private Keyで署名 Digital Signature ↓ Public Keyで検証 「対応するPrivate Keyを持つ者が署名し、内容も途中で変わっていない」と確認 Public Key → 他人に渡してよい Private Key → 所有者だけが保持

まず4語だけ区別する

Hash（ハッシュ）
入力データから固定長の値を作る。内容が変われば通常Hashも変わるため、改ざん検知の土台になる。
Encryption（暗号化）
内容を読めない形にして機密性を守る。復号できる者だけが元の内容へ戻す。
Digital Signature（電子署名）
Private Keyで署名し、対応するPublic Keyで検証する。主眼は「署名者」と「改ざんされていないこと」の確認。
Key Pair（鍵ペア）
対応関係を持つPrivate KeyとPublic Key。Private KeyからPublic Keyを導出できる方式がある。
Certificate（証明書）
Public Key、Identity情報、有効期限、用途等を含み、CAの署名によって検証できるX.509データ。
CA（認証局）
Certification Authority。Certificateを発行・署名し、発行後の失効状態も管理する主体。
Identity（識別情報）
「この鍵は誰・どのServerを表すか」という情報。Server名、利用者名、組織情報などが該当する。
X.509
Public Key Certificateの代表的な標準。Certificateにどのような情報を持たせ、どう署名・拡張するかの形式を定める。
CSR
Certificate Signing Request。Certificateを発行してほしいとCAへ渡す署名付き要求。詳しい中身と作成は後の「CSR」ページで扱う。
なぜこれがPKIにつながる？
Public Keyを受け取っても「そのPublic Keyが本当にexample.comのものか」はPublic Key単体では分からない。そこでCAが、Public KeyとIdentity情報をまとめたCertificateへ署名する。

「暗号化」と「署名」を混ぜない

目的この章での主な出番
暗号化内容を秘密にするPrivate KeyのPassphrase保護など
署名署名者・改ざん有無を検証CSR、Certificate、CAのTrust Chain
ここで覚える範囲：暗号Algorithm内部の数学は不要。この後の「なぜPrivate Keyを秘密にするか」「なぜCA署名を検証できるか」を理解できれば十分。
BEGINNER CHECK

次へ進める条件

  • Private Keyは所有者だけが保持する
  • Public Keyは検証側へ渡せる
  • 署名と暗号化は目的が違う
  • Public Key単体ではIdentityを保証できない
続き / SAME THEMEPKI / Certificate Lifecycle
公式要求：Understand X.509 certificates, X.509 certificate lifecycle, trust chains and PKI, including Certificate Transparency.
構造を先に確認
Server: Private Keyを保持 ↓ Public Key + Identity情報 CSR ↓ CAが確認・署名 Certificate ↓ ClientがTrust Chainを検証 「このPublic Keyは、このIdentityに結び付いている」と判断
PKI
Public Key Infrastructure（公開鍵基盤）。Certificate・CA・Trust Chain・失効管理などを組み合わせ、Public KeyとIdentityを信頼できる形で扱う仕組み。
CA
Certification Authority（認証局）。Certificateを発行・署名し、発行/失効状態を管理する。
Identity
Certificateが「誰・どのServer/組織を表すか」という識別情報。
Leaf Certificate
Chainの末端でServerやClient自身を表すCertificate。下位Certificateへ署名するCAとは役割が違う。
Trust Chain
LeafからIssuerを順に辿り、最終的に信頼済みRootまで到達して検証する署名関係。
CSR
Certificate Signing Request（証明書署名要求）。Public KeyとSubject等をまとめ、「この内容でCertificateを発行してほしい」とCAへ渡す要求。Private Key自体は渡さない。
Subject
Certificate/CSRが「誰・何を表しているか」という発行対象のIdentity情報。
Root CA
Trust Chainの最上位に置くCA。Root CertificateをTrust Anchorとしてあらかじめ信頼することでChain検証の起点になる。
Intermediate CA
Root等の上位CAからCA Certificateを発行された下位CA。日常のLeaf Certificate発行を担当できる。
Trust Anchor
Chain検証で「このRootは信頼する」と事前に決めた起点。Self-signed（自分自身で署名したCertificate）だから自動的に信頼されるわけではない。

公開鍵だけでは何が足りない?

公開鍵そのものには「その鍵が本当にexample.comのものか」を第三者が信頼する根拠がない。Certificateは、Public KeyとSubject等のIdentity情報をまとめ、CAが署名することで検証可能にする。

CAがすること

CSR等を基にCertificateを発行・署名し、その発行/失効状態を管理する。

CAがしないこと

Server/ClientのPrivate Keyを受け取って配布・保管する仕組みではない。

X.509 Certificate lifecycle

Key鍵生成
→
CSR発行要求
→
IssueCA署名
→
Deploy利用・検証
→
Renew / Reissue期限・鍵変更等
→
Revoke / Expire失効または期限満了
Renew / Reissue：期限前の更新、鍵変更・Subjectやhostname等の変更に伴う再発行を区別して考える。Private Key compromiseなら「期限まで待つ」のではなくRevoke→新Key/Certificateへ進む。
EXAM DECISION

Lifecycleを1本で判断する

  • Private Keyは所有者側に保持し、CAへ渡すのはCSR
  • 発行後も期限・鍵漏えい・再発行・失効までがLifecycle
  • 信頼済みRootまで署名関係を辿る → Trust Chain
← 全体像次のページ →
331.1 · 02/1402 X.509証明書
🟡 UnderstandFields

X.509 Certificateは「Fieldを実出力から読む」

このページの到達点：X.509 Certificateの出力例からVersion、Serial、Issuer、Validity、Subject、Public Key、Signatureを見つけられる。後半のServer Certificate発行後には同じFieldを実ファイルでも確認する。
公式要求：Understand X.509 certificate lifecycle, fields and X.509v3 certificate extensions.
構造を先に確認
Certificate ├─ Version / Serial Number ├─ Signature Algorithm ├─ Issuer ├─ Validity (Not Before / Not After) ├─ Subject ├─ Subject Public Key Info ├─ X.509v3 Extensions └─ Signature Value

まずCertificateを人間が読める形にする

# 発行済みCertificateを読む一般形 openssl x509 -in <certificate.crt> -text -noout # このノートでは後半の「Server Certificate」発行後、同じ操作を実行する
ここは読解先行：この時点ではまだ実習用server.crtを作っていない。下の内容はX.509出力例として読み、「Server Certificate」ページで自分のCertificateを発行した後に同じFieldを実ファイルで確認する。
CN
Common Name。DN（Distinguished Name）を構成する代表Field。ここではCA名やServer名が表示されている。Web hostname判断はCNだけでなくSAN（次ページで説明）も重要。
SHA-256
Secure Hash Algorithm 256-bit。署名処理で使われるHash Algorithmの1つ。この章では内部計算ではなく「Hashを使った署名Algorithm」と読めればよい。
RSA
Public/Private Key Pairを使う代表的な公開鍵Algorithm。ここでは署名Algorithm名の一部として出てくる。Key生成は後の「Key生成・管理」で扱う。
Certificate: Data: Version: 3 (0x2) Serial Number: 1001 (0x3e9) Signature Algorithm: sha256WithRSAEncryption Issuer: CN = Example Root CA Validity Not Before: Aug 28 00:00:00 2026 GMT Not After : Aug 28 00:00:00 2027 GMT Subject: CN = server.example.com Subject Public Key Info: ...
sha256WithRSAEncryptionという名前に注意：このFieldはCertificateの署名Algorithmを示している。名前にEncryptionが含まれていても、「Certificate本文を秘密にする暗号化」を意味しているわけではない。
読む順：「誰のCertificate?」→ Subject ／「誰が発行?」→ Issuer ／「いつまで?」→ Validity ／「識別番号?」→ Serial。

出力から判断する

問題文見るField
発行対象Subject
発行者Issuer
失効対象をSerialで特定Serial Number
期限切れNot Before / Not After
誤解：Subjectだけ見ればWebのhostname検証が全部分かる、ではない。SAN等のv3 Extensionも重要。次ページで分離して読む。
EXAM DECISION

「Field名 → 意味」を実出力で結ぶ

  • Issuer = 発行者
  • Subject = 発行対象
  • Serial = CA内でCertificateを識別する重要情報
← 前のページ次のページ →
331.1 · 03/1402 X.509証明書
🟡 Understandv3 Extensions

X.509v3 Extensionsは「Certificateの用途・制約・名前」を追加する

このページの到達点：Basic Constraints、Key Usage、Extended Key Usage、SAN等を実出力から読み、CA用・Server用・Client用の違いを判断できる。
公式要求：Understand X.509v3 certificate extensions.
構造を先に確認
X.509 Certificate ↓ Extensions ├─ Basic Constraints → CAになれる? ├─ Key Usage → Keyを何に使う? ├─ Extended Key Usage → TLS Server / Client等の用途 └─ Subject Alternative Name → DNS名/IP等
v3 = Version 3。X.509 version 3では用途・名前・制約などをExtensionとして追加できる。
略語を先に：
SAN = Subject Alternative Name（Certificateが対応するDNS名/IP等）／ KU = Key Usage（鍵の基本用途）／ EKU = Extended Key Usage（TLS Server/Client等の拡張用途）。
Basic Constraintsは「このCertificateをCAとして使えるか」などの制約。pathlenは、そのCAより下に置けるCA階層の深さを制限する値。
Verifier（検証側） = Certificate/署名が正しいかを確認するClientやTool。
DNS = Domain Name System。SANのDNS:server.example.comは、そのDNS名をCertificateの対象名として持つことを示す。
TLS = Transport Layer Security。通信を保護するProtocol。ここではServer/Client Certificateの用途名として出るだけで、TLS詳細は331.2で扱う。

実出力

X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:server.example.com, DNS:www.example.com
CA:FALSEならこのCertificateをCA Certificateとして使う想定ではない。Server AuthenticationならServer用途。SANにはCertificateが対応するDNS名等を載せられる。
Key Usageの出力：Digital Signatureは署名用途、Key Enciphermentは暗号鍵などの値を暗号化・Transportする用途を示す。ここでは名前と役割を読めればよく、TLSのCipher Suite詳細は331.2側で扱う。

Configで後から出るExtensionも先に意味を付ける

項目何を表す?
criticalVerifierがそのExtensionを理解できない場合、Certificateを受け入れてはいけないことを示す指定。
SKI = Subject Key IdentifierそのCertificate自身のPublic Keyを識別するためのID。
AKI = Authority Key Identifier署名したIssuer側のKeyを識別し、Chain構築を助けるID。
pathlenCAの下に何段のCAを置けるかという制約。pathlen:0なら、そのCAより下にさらにCAを置かない。

Server / Client / CAを比較

CA CertificateServer CertificateClient Certificate
Basic ConstraintsCA:TRUE通常 CA:FALSE通常 CA:FALSE
EKUの例用途設計によるserverAuthclientAuth
主目的下位Certificateへ署名Server認証Client/User認証
確認：CA:FALSEなのに「このCertificateで下位Certificateへ署名するCA」と説明されたら？ → 不整合を疑う。
EXAM DECISION

用途判断はExtensionまで見る

  • CA可否 → Basic Constraints
  • 鍵の基本用途 → Key Usage
  • Server/Client等の用途 → Extended Key Usage
  • DNS名等 → SAN
← 前のページ次のページ →
331.1 · 04/1403 鍵と形式
🔴 Generate / ManageKeys

鍵と形式：Private/Public Keyを管理し、PEM / DER / PKCSを区別する

このページの到達点：Private Keyを安全に生成・管理してPublic Keyを抽出し、PEM/DERの違いとPKCSの位置付けまで実操作と結び付けて説明できる。
公式要求：Generate and manage public and private keys.
構造を先に確認
Private Key ├─ 所有者だけが保持 ├─ CSR/署名などで「秘密側の操作」に使用 └─ Public Keyを導出 ↓ CSR / Certificateへ Private Key漏えい → Identityを偽装され得る → Revoke/再発行が必要
実習の作業Directory：以降の相対Pathを迷わないよう、同じDirectoryで最後まで実行する。場所は例なので変更してよい。
mkdir -p ~/lpic303-3311-lab cd ~/lpic303-3311-lab
RSAとは：Public/Private Key Pairを使う代表的な公開鍵Algorithm。この実習ではRSA Keyを生成する。2048/4096はKey size（bit数）で、Algorithm内部の数学は331.1では扱わない。

1. 暗号化されたPrivate Keyを生成

# RSA 2048bit。-aes-256-cbcでPrivate Keyを # Passphrase保護 openssl genpkey -algorithm RSA \ -pkeyopt rsa_keygen_bits:2048 \ -aes-256-cbc -out server.key chmod 600 server.key
-algorithm RSA
生成するKey AlgorithmをRSAにする。
rsa_keygen_bits:2048
RSA Key sizeを2048 bitにする。この実習で使う具体値。
-aes-256-cbc
出力するPrivate KeyをPassphrase（鍵ファイルを保護する秘密の合言葉）で暗号化する。
-out server.key
生成したPrivate Keyの保存先。
実行時にPassphraseを聞かれるのは正常：-aes-256-cbcでPrivate Keyを暗号化しているため、後続のopenssl reqやopenssl pkeyでそのKeyを使うとPassphrase入力を求められる。chmod 600はOS上でも所有者以外から読みづらくする。
Algorithm内部の数学はここでは不要：この章では「RSAでKey Pairを作る」「Private Keyは暗号化して保護する」「Public Keyを抽出できる」を操作できればよい。
実行前 → 実行後
実行前
server.key なし
→
実行後
server.key 作成
Private KeyはPassphrase保護

2. 中身を確認 / Public Keyを抽出

# Private Keyの構造を確認 openssl pkey -in server.key -text -noout # Public KeyだけをFileへ取り出す # （出力形式はこのページ後半で説明） openssl pkey -in server.key -pubout -out server.pub
genpkey
新しいPrivate Keyを生成
pkey -text
鍵の内容・Parameterを確認
pkey -pubout
Private KeyからPublic Keyを出力
Private Key漏えい：Certificateが有効期限内でも信頼を継続できない。新しいKey Pairを作り、旧Certificateを失効させる判断につながる。
操作確認：
  1. Private Key生成
  2. openssl pkey -textで確認
  3. Public Keyを抽出
  4. ls -l等でPrivate Keyの権限も確認
-rw------- ... server.key ← 600なら所有者だけread/write
EXAM DECISION

Key操作の役割

  • 生成 → genpkey
  • 鍵そのものの確認/変換 → pkey
  • CAへ送るのはPrivate KeyではなくCSR
続き / SAME THEMEPEM / DER / PKCS
公式要求：Partial list of used files, terms and utilities: PEM, DER, PKCS. ※これら個々に「Manage」という公式動詞が付いているわけではない。
構造を先に確認
Key / Certificateなどの中身 ├─ PEM → Base64 + headerのtext表現 └─ DER → binary encoding PKCS → 暗号関連の標準群 ├─ PKCS#8 : Private Key関連 └─ PKCS#12 : Key + Certificate等のContainer
PEM
Privacy-Enhanced Mail由来のtext表現。現在はCertificate/Key等をBase64＋BEGIN/END headerで表す形式として広く使う。
DER
Distinguished Encoding Rules。X.509 Certificate等の構造化データをbinaryで一意に表すEncoding Rule。
PKCS
Public-Key Cryptography Standards。公開鍵暗号関連の標準群。PKCS#8やPKCS#12のように番号ごとに目的が違う。
Base64とは：binary dataを英数字中心の文字列として表現するEncoding。暗号化ではない。PEMはDER相当のbinary情報をBase64化し、BEGIN/END headerを付けたtext表現としてよく使われる。

PEMは「中身の種類」ではない

-----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

PEMはBase64＋BEGIN/END headerを使うtext表現。同じPEMでもPrivate Key、CSR、Certificate等を表現できる。

server.keyでPEM ↔ DERを確認

# 「Key生成・管理」で抽出したPublic Key（PEM）をDERへ openssl pkey -pubin -in server.pub \ -outform DER -out server.pub.der # DER Public KeyをPEMへ戻す openssl pkey -pubin -inform DER -in server.pub.der \ -out server.pub.pem
なぜPublic Keyで試す? PEM/DERはEncodingの違いを確認したいだけなので、ここでは秘密情報を不要に書き出さない。Private KeyのFormat変換では、出力先の暗号化・Permissionまで別途確認する。

PKCSは「1つのFormat名」ではなく標準群

例位置付け
PKCS#8Private Key情報の表現/保護で使われる標準
PKCS#12Private Key＋Certificate/Chain等をまとめられるContainer。実際のexportは後半の「Server Certificate」発行後に行う。
EXAM DECISION

形式と中身を混同しない

  • PEM → text表現
  • DER → binary encoding
  • PKCS → 標準群。PKCS#12はKey/Certificateをまとめる代表例
← 前のページ次のページ →
331.1 · 05/1404 CSR
初学者橋渡しConfig syntax

CSR：config記法を読んで、Certificate Signing Requestを作る

このページの到達点：OpenSSLのSection参照を読み、server.cnfを作成してCSRを生成・確認・署名検証できる。
このページの位置付け：公式のOpenSSL configurationを理解するための読み方。独立した追加出題範囲ではない。
設定ファイルの読み方
[ req ] ← Section名 distinguished_name = dn ───────┐ req_extensions = req_ext ───┐ │ ↓ ↓ [ req_ext ] [ dn ] subjectAltName = @alt_names CN = server.example.com ↓ [ alt_names ] DNS.1 = ...

[ section ] は「設定のまとまり」

[req]、[dn]、[server_cert]などは設定を分けるためのSection。Section名の多くは参照先として自分で付ける名前であり、すべてが固定予約語というわけではない。

distinguished_name = dn
「Distinguished Name（Subject情報）は[dn] Sectionを読む」という参照。
req_extensions = req_ext
CSRへ要求するExtensionは[req_ext] Sectionを読む。
@alt_names
[alt_names] Sectionを参照する記法。
$dir
設定内で定義したdirの値を展開する変数参照。例：$dir/index.txt。

DNとは何か

DN = Distinguished Name（識別名）
Certificate/CSRで「誰・何を表すか」を記述するSubject情報のまとまり。ここではまずCN = Common Nameを読めればよい。Serverのhostname確認ではSANも重要なので、CNだけで全部判断しない。
BEGINNER CHECK

設定を「文字列の暗記」にしない

  • [xxx] → 設定のまとまり
  • = dn → 別Sectionを名前で参照できる
  • @alt_names → SAN用Section参照
  • $dir → 変数展開
続き / SAME THEMECSRを作成・確認する
公式要求：Request server and client certificates. Partial term: CSR.
構造を先に確認
Private Key（所有者だけが保持） ↓ Public Key + Subject + requested extensions ↓ Private KeyでCSR自身へ署名 CSR ↓ CAへ渡す Certificate発行判断
CSR = Certificate Signing Request（証明書署名要求）
「このPublic KeyとSubject情報でCertificateを発行してほしい」という要求。CSR自身はPrivate Keyで署名されるが、CSRはCertificateではない。

1. server.cnfを作る

保存先：以下の内容を、実習Directory直下のserver.cnfとして保存する。後続の-config server.cnfがこのFileを読む。
[ req ] prompt = no distinguished_name = dn req_extensions = req_ext [ dn ] CN = server.example.com [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = server.example.com DNS.2 = www.example.com

2. CSRを作成・確認する

openssl req -new -key server.key \ -out server.csr -config server.cnf openssl req -in server.csr -text -noout openssl req -in server.csr -verify -noout
req -new
新しいCSRを作成する。
-key server.key
CSR内のPublic Keyの元となり、CSR自身へ署名するPrivate Keyを指定。
-config server.cnf
Subjectとrequested extension（SAN等）を設定Fileから読む。
req -text -noout
CSRの内容を人が読める形で表示し、PEM本文そのものは表示しない。
req -verify
CSR自身の署名が対応Public Keyで正しく検証できるか確認する。
Certificate Request: Subject: CN = server.example.com Subject Public Key Info: ... Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:server.example.com, DNS:www.example.com Certificate request self-signature verify OK
CSRの署名：CSR自身の改ざん検知・Private Key所持の証明に使われる。CSRを作っただけではCertificateはまだ発行されていない。
EXAM DECISION

CSRの位置

  • Private Key → CSR → CA署名 → Certificate
  • CSRにはPublic Keyと要求情報が入り、Private Key自体はCAへ提出しない
  • CertificateのIssuer / Serial / ValidityはCA発行時に確定
← 前のページ次のページ →
331.1 · 06/1405 CA構築
初学者橋渡しCA state

CA構築①：状態管理を理解してRoot CA configを読む

このページの到達点：CAがDB・Serial・CRL番号を持つ理由を理解し、root.cnfを「状態・署名主体・番号・発行Rule」に分けて読める。
このページの位置付け：Create/operate CAを理解するための前提整理。
CAが発行後も覚える理由
Certificateを発行 ↓ 「誰に？ Serialは？ 今もValid？ Revokeされた？」を後から確認する必要 ↓ CAが状態を管理 ├─ index.txt → 発行/失効の台帳 ├─ serial → 次に付けるCertificate番号 ├─ crlnumber → 次に発行するCRL番号 ├─ private_key→ Certificateへ署名するCA秘密鍵 └─ certificate→ CA自身のCertificate
DB = Database。この教材ではCAの「発行・失効の台帳」を指す略記として使う。

CAは「署名コマンド」だけではない

CA（Certification Authority / 認証局）はCertificateを署名して終わりではない。発行済みCertificateを後で失効できるように、発行記録と状態を持つ必要がある。

database / index.txt
発行済みCertificateの台帳。後でV = Valid、R = Revokedなどの状態を確認する。
serial
CertificateをCA内で識別するSerial Numberを管理する。発行ごとに次の値へ進む。
crlnumber
CAが発行するCRL（Certificate Revocation List）の番号管理に使う。
policy
CSRのSubject情報を発行時にどう確認・要求するかを決めるRule。
extension profile
server_certやclient_certのように、発行Certificateへ付与する用途・制約をまとめる。
ここが分かると後続のRoot CA configが読める：
database = ...は「なぜ必要？」ではなく「発行/失効台帳はどこ？」、serial = ...は「次の番号はどこ？」という質問への答えになる。
BEGINNER CHECK

CAの5要素を役割で言える

  • Private Key → 署名
  • CA Certificate → CA自身のPublic Key/Identity
  • database → 発行/失効状態
  • serial → Certificate番号
  • policy/extensions → 何をどう発行するか
続き / SAME THEMERoot CA用OpenSSL configuration
公式要求：Description: configure and use OpenSSL to implement CAs. Partial list: OpenSSL configuration.
構造を先に確認
openssl ca / req ↓ -config root.cnf root.cnf ├─ root/index.txt / serial / crlnumber ├─ root.key / root.crt ├─ policy_loose └─ v3_ca / v3_intermediate_ca この設定を次の「Root CA構築」ページで実際に使う。
このページは暗記表ではない：前の「CSR」テーマで学んだSection参照と、直前のCA状態管理を、実際のroot.cnfへ対応させる。Intermediate用設定はRoot CAを構築した後に別ページで読む。

長いconfigは4グループに分けて読む

グループ主な設定意味
CAの保存場所dir / database / new_certs_dirCAの管理Directory、発行/失効DB、発行Certificate保存先。
署名主体private_key / certificateどのCA Private Key/Certificateで発行するか。
番号・期限serial / crlnumber / default_days / default_crl_daysCertificate/CRL番号と既定の有効期間。
発行Rulepolicy / copy_extensions / v3_ca / v3_intermediate_caSubjectをどう確認し、CSR Extensionをどう扱い、CA Certificateへどの制約を付けるか。
default_md = sha256
署名で既定に使うMessage Digest（Hash）AlgorithmをSHA-256にする。
supplied
CSR SubjectにそのFieldが存在することを要求する。
optional
そのSubject Fieldがなくても発行Policy上は許容する。
prompt = no
対話入力ではなく、指定Sectionの値を使ってSubject等を組み立てる。
x509_extensions = v3_ca
Self-signed Certificate作成時に[v3_ca]のExtension設定を使う。
default_ca = CA_default
openssl caが既定で読むCA設定Sectionを[CA_default]にする。
copy_extensions = none
CSRに含まれるrequested extensionを無条件には発行Certificateへコピーしない。発行側のExtension Profileで明示する。
policy_looseは本人確認そのものではない：
この学習用configではSubject Fieldが存在するか等をOpenSSL上で確認するだけ。Public CAが実際に行うDomain/組織等のValidation手続きを再現しているわけではない。ここでは「CA側に発行Policyがある」ことを理解する。

Root CA用 root.cnf

保存先：次の設定全体を、実習Directory直下のroot.cnfとして保存する。次ページ以降の-config root.cnfがこのFileを読む。
[ ca ] default_ca = CA_default [ CA_default ] dir = ./root database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/certs/root.crt private_key = $dir/private/root.key serial = $dir/serial crlnumber = $dir/crlnumber default_md = sha256 default_days = 365 default_crl_days = 30 policy = policy_loose copy_extensions = none [ policy_loose ] commonName = supplied organizationName = optional organizationalUnitName = optional countryName = optional stateOrProvinceName = optional emailAddress = optional [ req ] prompt = no distinguished_name = root_dn x509_extensions = v3_ca [ root_dn ] CN = LPIC303 Training Root CA [ v3_ca ] basicConstraints = critical, CA:true, pathlen:1 keyUsage = critical, keyCertSign, cRLSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer [ v3_intermediate_ca ] basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, keyCertSign, cRLSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer
EXAM DECISION

root.cnfは「Rootが何を使って何を発行するか」

  • database / serial / crlnumber → CAの状態
  • private_key / certificate → Rootの署名主体
  • policy → CSR Subjectの確認Rule
  • v3_ca / v3_intermediate_ca → 発行するCA Certificateの制約
← 前のページ次のページ →
331.1 · 07/1405 CA構築
🔴 Create / SecureRoot CA

Root CAを「Key＋Certificate＋CA database」で構築する

このページの到達点：Root CAのDirectory/DB/Serial/CRL番号/Private Key/Certificateを作成し、CA Private Keyを保護する理由を説明できる。
公式要求：Create, operate and secure a certification authority.
構造を先に確認
root/ ├─ private/root.key ← 最重要秘密 ├─ certs/root.crt ← Trust Anchor候補 ├─ newcerts/ ├─ index.txt ← 発行/失効DB ├─ serial └─ crlnumber
Self-signedとは：SubjectとIssuerが同じ（self-issued）だけでなく、そのCertificate自身のPublic Keyに対応するPrivate Keyで署名されているCertificate。この実習ではRoot Private Keyを使ってRoot Certificate自身へ署名する。Rootが信頼される理由は「Self-signedだから」ではなく、Trust StoreでTrust Anchorとして信頼されるから。

1. Root CA管理領域を作る

mkdir -p root/{private,certs,newcerts} touch root/index.txt echo 1000 > root/serial echo 1000 > root/crlnumber chmod 700 root/private

2. Root CA Private Keyを保護して生成

openssl genpkey -algorithm RSA \ -pkeyopt rsa_keygen_bits:4096 \ -aes-256-cbc -out root/private/root.key chmod 600 root/private/root.key

3. Self-signed Root Certificateを作る

openssl req -new -x509 \ -key root/private/root.key \ -sha256 -days 3650 \ -out root/certs/root.crt \ -config root.cnf -extensions v3_ca openssl x509 -in root/certs/root.crt \ -noout -subject -issuer -text
openssl req -new -x509
reqを使うが、-x509を付けるとCSRではなくSelf-signed X.509 Certificateを出力する。
-key root.key
Root Certificateへ署名するPrivate Key。
-days 3650
この学習用Root Certificateの有効期間。
-config root.cnf
SubjectやExtension等の設定を読む。
-extensions v3_ca
CA:TRUE、Key Usage等のRoot CA用Extension Sectionを指定する。
subject=CN = LPIC303 Training Root CA issuer=CN = LPIC303 Training Root CA X509v3 Basic Constraints: critical CA:TRUE, pathlen:1 X509v3 Key Usage: critical Certificate Sign, CRL Sign
出力の読み方：subject = issuerなのでまずself-issuedと分かる。さらに、このCertificateは直前のCommandでRoot自身のPrivate Keyを使って署名しているためSelf-signed。CA:TRUEはCA用途、Certificate Sign/CRL Signは下位Certificate/CRLへ署名する用途を示す。
学習用CAとして扱う：openssl caはOpenSSL公式でも「sample minimal CA application」と位置付けられ、本番運用向けの完全なCA製品そのものではない。ここではLPI Objectiveどおり、CAの構造・発行・DB/Serial・失効を理解して操作するための実習として使う。

secureの最低限

Private KeyをPassphrase保護、Directory/File Permissionを制限、不要な常時Online運用を避け、暗号化Backup/Recoveryも設計する。

漏えい時

Root Keyで正規に見えるCertificate/CAを署名できるため影響が非常に大きい。

EXAM DECISION

Root CAは「自己署名Certificateだけ」ではない

  • 署名用Private Keyを保護
  • CA Certificate＋DB＋Serial/CRL管理が必要
  • Rootは自分自身をIssuerとするSelf-signed Certificate
← 前のページ次のページ →
331.1 · 08/1406 証明書発行
🔴 ConfigureIntermediate config

証明書発行①：Intermediate CAを設定してRootから発行する

このページの到達点：Intermediate CA用configを読み、Key/CSRを作成し、Root CAからIntermediate CA Certificateを発行してDB/Serialの変化まで追える。
公式要求：Description: configure and use OpenSSL to implement CAs. Partial list: OpenSSL configuration.
今から使う設定だけを見る
intermediate.cnf ├─ intermediate/index.txt / serial / crlnumber ├─ intermediate.key / intermediate.crt ├─ policy_loose ├─ server_cert → Server Leaf用Extension └─ client_cert → Client Leaf用Extension このページ後半でIntermediate CAを作り、その後Server/Client発行に使う。
Rootとの違い：管理項目の構造はほぼ同じ。ただしRootはIntermediate CAを発行し、IntermediateはServer/ClientなどのLeaf Certificateを発行するため、Extension Profileが異なる。

Intermediate CA用 intermediate.cnf

保存先：以下の設定全体を、実習Directory直下のintermediate.cnfとして保存する。Intermediate CA自身の管理と、後続のServer/Client発行で使う。
[ ca ] default_ca = CA_default [ CA_default ] dir = ./intermediate database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/certs/intermediate.crt private_key = $dir/private/intermediate.key serial = $dir/serial crlnumber = $dir/crlnumber default_md = sha256 default_days = 365 default_crl_days = 30 policy = policy_loose copy_extensions = none [ policy_loose ] commonName = supplied organizationName = optional organizationalUnitName = optional countryName = optional stateOrProvinceName = optional emailAddress = optional [ server_cert ] basicConstraints = critical, CA:false keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer subjectAltName = @server_alt [ server_alt ] DNS.1 = server.example.com DNS.2 = www.example.com [ client_cert ] basicConstraints = critical, CA:false keyUsage = critical, digitalSignature extendedKeyUsage = clientAuth subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer
Server/Client Profileを読む：
CA:false → CAにはしない ／ serverAuth → TLS Server用途 ／ clientAuth → TLS Client用途。subjectAltName = @server_altはServer CertificateへDNS名を入れる設定。
SKI/AKIの細かい書式は丸暗記しない：subjectKeyIdentifier = hash / authorityKeyIdentifier = keyid,issuerは、前半で学んだ「自分のKey ID / Issuer側Key ID」をCertificateへ持たせる設定として読む。
CSR extensionは自動採用ではない：copy_extensions = noneではCSRのrequested extensionを無条件にコピーしない。最終Certificateへ何を入れるかはCA側の発行Policy/Extension設定で決める。ここではserver_certがSANを明示している。
EXAM DECISION

Intermediate設定はLeaf発行のRuleへつながる

  • database/serial → Intermediate自身の発行状態
  • private_key/certificate → Intermediateが署名主体
  • server_cert → CA:FALSE + serverAuth + SAN
  • client_cert → CA:FALSE + clientAuth
続き / SAME THEMEIntermediate CAを発行する
公式要求：Create and operate a certification authority; revoke certification authorities later in this flow.
構造を先に確認
Root CA │ signs (v3_intermediate_ca) ↓ Intermediate CA ├─ own Private Key ├─ CA Certificate (CA:TRUE, pathlen:0) └─ own DB / Serial Root index.txt: Intermediate CAをValidとして記録
なぜIntermediate CAを挟む？
Root CAのPrivate Keyを日常の発行処理で使い続けず、RootがIntermediate CAへ権限を委任し、IntermediateがLeaf Certificateを発行する構成にできる。pathlen:0は、このIntermediateより下にさらにCAを作らせない制約として読める。

1. Intermediate CAの管理領域とKeyを作る

mkdir -p intermediate/{private,certs,newcerts} touch intermediate/index.txt echo 2000 > intermediate/serial echo 2000 > intermediate/crlnumber chmod 700 intermediate/private openssl genpkey -algorithm RSA \ -pkeyopt rsa_keygen_bits:4096 \ -aes-256-cbc -out intermediate/private/intermediate.key chmod 600 intermediate/private/intermediate.key

2. Intermediate CAのCSRを作り、Root CAが署名

openssl req -new \ -key intermediate/private/intermediate.key \ -subj "/CN=LPIC303 Training Intermediate CA" \ -out intermediate/intermediate.csr openssl ca -batch -config root.cnf \ -extensions v3_intermediate_ca -days 1825 \ -in intermediate/intermediate.csr \ -out intermediate/certs/intermediate.crt
-subj
CSRのSubjectをCommand lineから直接指定する。
-batch
確認入力を出さず、非対話で処理する。実習を同じ手順で再現しやすくするため使用。
-config root.cnf
Root CAのDB/Key/Certificate/Policyを定義した設定を読む。
-extensions v3_intermediate_ca
発行するCertificateをIntermediate CA用途（CA:TRUE等）にするSectionを指定。
-days 1825
発行Certificateの有効期間を日数で指定。
subject=CN = LPIC303 Training Intermediate CA issuer=CN = LPIC303 Training Root CA X509v3 Basic Constraints: critical CA:TRUE, pathlen:0
出力の読み方：SubjectはIntermediate CA、IssuerはRoot CAなので「RootがIntermediateを発行した」。CA:TRUE, pathlen:0なのでCAとして署名できるが、その下にさらにCAを置かない制約。

3. Root CA database / Serialの変化を確認

発行前
root/index.txt: 対象なし
root/serial: 1000
→
発行後
index.txt: V ... 1000 ... Intermediate CA
serial: 次値へ
openssl ca -config root.cnf -status 1000
1000=Valid (V)
EXAM DECISION

CA運用は「署名＋状態管理」

  • Intermediate CAもCSR→CA署名で発行できる
  • Root DB/Serialが発行状態を記録
  • このIntermediateが後でServer/Clientを発行し、Chainが実習と一致する
← 前のページ次のページ →
331.1 · 09/1406 証明書発行
🔴 Request / Sign / ManageServer Certificate

Server Certificateは「CSR→Intermediate署名→Extension確認」まで行う

このページの到達点：前半で作成したServer Key/CSRをIntermediate CAで署名し、Issuer・Serial・CA:FALSE・serverAuth・SANを実出力で確認できる。
公式要求：Request, sign and manage server certificates.
構造を先に確認
server.key（「Key生成・管理」で作成） ↓ server.cnf + req（「CSR」で作成） server.csr ↓ Intermediate CA / server_cert server.crt ↓ x509 -text Issuer / Serial / CA:FALSE / serverAuth / SAN
この実習の「署名」は発行Flow確認：実際のPublic CAでは「そのDomainを本当に管理しているか」等の確認を経て発行する。このTraining CAは、そこを簡略化してKey/CSR/CA Policy/署名/DB更新の仕組みに集中する。

Intermediate CAでServer CSRを署名

openssl ca -batch -config intermediate.cnf \ -extensions server_cert \ -in server.csr -out server.crt openssl x509 -in server.crt \ -noout -subject -issuer -serial -text
subject=CN = server.example.com issuer=CN = LPIC303 Training Intermediate CA serial=2000 X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: DNS:server.example.com, DNS:www.example.com

発行後のIntermediate CA状態も確認する

発行前
intermediate/serial: 2000
Serverの記録なし
→
発行後
V ... 2000 ... /CN=server.example.com
serial: 2001
openssl ca -config intermediate.cnf -status 2000
2000=Valid (V)
Manageの見方：Certificate Fileを作っただけでなく、Intermediate CAのDBに「Serial 2000はValid」と登録され、次の発行番号が2001へ進む。
CSRと発行結果を比較：CSRは「要求」。最終CertificateのExtensionはCA側Policyで決まる。ここではcopy_extensions = noneなので、CSR内Extensionを無条件コピーせず、server_certでSAN/EKU等を明示している。

発行後にPKCS#12へまとめる代表例

openssl pkcs12 -export \ -inkey server.key -in server.crt \ -certfile intermediate/certs/intermediate.crt \ -out server.p12
pkcs12 -export
Private KeyとCertificate等をPKCS#12 Containerへ書き出す。
-inkey server.key
格納するPrivate Key。
-in server.crt
Private Keyに対応するLeaf Certificate。
-certfile intermediate.crt
一緒に格納する追加Certificate（ここではIntermediate）。
PKCS#12 export時：通常はContainerを保護するPassword入力を求められる。server.key自体も暗号化しているため、そのPrivate KeyのPassphrase入力も必要になる。

PKCS#12はPrivate Key＋Certificate/Chainをまとめて受け渡す場合などに使われる代表的Container。

EXAM DECISION

Server用途は発行後のExtensionで確認

  • Issuer → Intermediate CA
  • EKU → TLS Web Server Authentication
  • SAN → 対象DNS名
  • 「CSRに書いた＝必ず採用」ではなくCA Policyを確認
← 前のページ次のページ →
331.1 · 10/1406 証明書発行
🔴 Request / Sign / ManageClient Certificate

Client Certificateも「Key→CSR→署名→用途確認」まで行う

このページの到達点：Client Key/CSRを新規作成し、Intermediate CAでClient用途として発行し、Server CertificateとのEKU差を実出力で確認できる。
公式要求：Request, sign and manage client certificates.
構造を先に確認
client.key ↓ client.cnf / CSR client.csr ↓ Intermediate CA / client_cert client.crt ↓ EKU: TLS Web Client Authentication

1. Client Keyとclient.cnfを作る

# Client Private Keyを生成 openssl genpkey -algorithm RSA \ -pkeyopt rsa_keygen_bits:2048 \ -aes-256-cbc -out client.key chmod 600 client.key

client.cnfとして保存する内容

[ req ] prompt = no distinguished_name = dn [ dn ] CN = alice

2. CSR→Intermediate CA署名

openssl req -new -key client.key \ -out client.csr -config client.cnf openssl ca -batch -config intermediate.cnf \ -extensions client_cert \ -in client.csr -out client.crt openssl x509 -in client.crt \ -noout -subject -issuer -serial -text
subject=CN = alice issuer=CN = LPIC303 Training Intermediate CA serial=2001 X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Client Authentication

Client発行後のCA状態

Server発行後
intermediate/serial: 2001
→
Client発行後
V ... 2001 ... /CN=alice
serial: 2002
openssl ca -config intermediate.cnf -status 2001
2001=Valid (V)
Server/Clientを同じDBで管理：Intermediate CAは発行したLeaf CertificateをSerialごとに記録する。後で失効する時もこの状態管理が土台になる。
ServerClient
基本LifecycleKey→CSR→CA署名Key→CSR→CA署名
EKU例serverAuthclientAuth
認証される側ServerClient/User
EXAM DECISION

Server/Clientは同じX.509、用途が違う

  • どちらもKey→CSR→CA署名
  • Server → serverAuth、Client → clientAuth
  • ApacheでClient Certificateを要求する設定は331.2
← 前のページ次のページ →
331.1 · 11/1407 Trust Chain
🟡 Understand教材: verify実践

Trust Chain：成功と失敗を同じ流れで検証する

このページの到達点：Root→Intermediate→LeafのChainを実ファイルで検証し、Intermediate不足・Trust Anchor・Validityなど失敗原因を切り分けられる。
公式要求：Understand trust chains and public key infrastructures. ※verify操作は理解を実ファイルへ接続する教材上の実践。
構造を先に確認
Trusted Root CA (root/certs/root.crt) ↑ signs Intermediate CA (intermediate/certs/intermediate.crt) ↑ signs Leaf: server.crt / client.crt Leaf単体を無条件に信頼するのではなく、Trust AnchorまでChainを構築・検証する。
Leaf
Server/Client自身のCertificate。この実習ではserver.crt/client.crt。
Issuer
そのCertificateへ署名した発行者。LeafのIssuerはIntermediate CA。
Trust Anchor
Chain検証で「ここは信頼する」とあらかじめ決めた起点。この実習ではRoot Certificateを-CAfileで与える。
Trust Store
OS/Browser等が信頼するRoot Certificateを保持する場所・集合。

実際に作った3段Chainを検証

openssl verify \ -CAfile root/certs/root.crt \ -untrusted intermediate/certs/intermediate.crt \ server.crt openssl verify \ -CAfile root/certs/root.crt \ -untrusted intermediate/certs/intermediate.crt \ client.crt
server.crt: OK client.crt: OK
-CAfile root/certs/root.crt
Trust Anchorとして信頼するRootを与える。
-untrusted intermediate/.../intermediate.crt
LeafからRootへChainを構築するためのIntermediateを与える。IntermediateをRootと同じ意味で「信頼済み」として指定するわけではない。

何を見てChainを辿る?

LeafIssuer = Intermediate
→
IntermediateIssuer = Root / CA:TRUE
→
RootTrust Anchor
EXAM DECISION

RootとIntermediateの役割を分ける

  • -CAfile → Trust Anchor
  • -untrusted → Chain構築に使うIntermediate
  • Self-signedであることと「信頼されている」ことは別
続き / SAME THEMETrust Chainの失敗を切り分ける
公式要求：Understand trust chains / certificate lifecycle. Error reading is practical reinforcement.
構造を先に確認
server.crt ↓ Issuerを探す Intermediate不足 → error 20 / issuer取得不可 ↓ Rootが信頼されない → Trust Anchor問題 Chainが作れてもValidity/Extension等で失敗する場合がある。

失敗例1：Intermediateを与えない

openssl verify \ -CAfile root/certs/root.crt \ server.crt
CN=server.example.com error 20 at 0 depth lookup: unable to get local issuer certificate error server.crt: verification failed

LeafのIssuerであるIntermediate Certificateを見つけられず、RootまでChainを継続できない。

失敗例2：信頼するRootが違う

Intermediateを持っていても、そのChainの終点となるRootがTrust Store/-CAfileにないなら「信頼済みChain」として完了しない。

失敗例3：Validity

error 10 at 0 depth lookup: certificate has expired

Issuer不足と期限切れは別問題。Intermediateを追加してもExpiredは直らない。

1Subject / Issuer
→
2Intermediate
→
3Root Trust
→
4Validity
→
5Extensions
EXAM DECISION

Error文から原因層へ

  • unable to get local issuer certificate → Intermediate/Chain
  • wrong trust root → Trust Anchor
  • certificate has expired → Validity
331.2へ渡すSnapshot：次の失効演習ではServer CertificateとIntermediate CAをRevokeする。331.2のHTTPS実習では失効前の有効な状態を使うため、ここでLab全体をコピーしておく。
cd ~ cp -a lpic303-3311-lab lpic303-3312-lab cd ~/lpic303-3311-lab
以降：331.1の失効演習はlpic303-3311-labで続行し、331.2は~/lpic303-3312-labを使う。
← 前のページ次のページ →
331.1 · 12/1408 失効
🔴 RevokeCRL: Partial list

Revocationは「DBをV→Rに変え、CRLで検証結果まで変える」

このページの到達点：Server Certificateを失効し、CA databaseの変化、CRL生成/読解、CRLを使ったverifyのcertificate revokedまで一続きで確認できる。
公式要求：Revoke certificates and certification authorities. Partial term: CRL.
構造を先に確認
server.crt (Serial 2000 / V) ↓ openssl ca -revoke Intermediate DB: V → R ↓ openssl ca -gencrl intermediate/crl.pem ↓ verify -crl_check error 23: certificate revoked
CRL = Certificate Revocation List（証明書失効リスト）
「有効期限前だが、もう信頼してはいけないCertificate」をCAがSerial Number等で公開するList。Expire（期限満了）とRevoke（期限前失効）は別。

1. Intermediate CAでServer Certificateを失効

openssl ca -batch -config intermediate.cnf \ -revoke server.crt \ -crl_reason keyCompromise
-revoke server.crt
指定CertificateをCA database上で失効状態へ変更する。
-crl_reason keyCompromise
失効理由を「Key compromise」として記録する。
失効前
intermediate/index.txt
V ... 2000 ... /CN=server.example.com
→
失効後
R ... 2000 ... /CN=server.example.com
Revocation Date/Reasonを記録

2. Intermediate CRLを生成・読む

openssl ca -batch -config intermediate.cnf \ -gencrl -out intermediate/crl.pem openssl crl -in intermediate/crl.pem -text -noout
-gencrl
現在のCA databaseの失効情報からCRLを生成する。
openssl crl -text
CRL内容を人が読める形で表示する。
Revoked Certificates: Serial Number: 2000 Revocation Date: ... X509v3 CRL Reason Code: Key Compromise

3. CRLを使って実際に検証

openssl verify \ -CAfile root/certs/root.crt \ -untrusted intermediate/certs/intermediate.crt \ -CRLfile intermediate/crl.pem -crl_check \ server.crt
-CRLfile
検証時に参照するCRLを与える。
-crl_check
Leaf CertificateのIssuerが発行したCRLを使い、Leafの失効Statusを確認する。
CN=server.example.com error 23 at 0 depth lookup: certificate revoked error server.crt: verification failed
重要：CRLを渡さず通常のChain検証だけをすると、失効情報を確認せずOKになる場合がある。「署名Chainが正しい」と「現在失効していない」は別の確認。
EXAM DECISION

Revokeは「登録して終わり」ではない

  • CA DBでV→R
  • CRLはSerial/Revocation Date/Reasonを持つ
  • VerifierがCRLを参照するとrevokedとして失敗
← 前のページ次のページ →
331.1 · 13/1408 失効
🔴 Revoke CAOCSP: Partial list

OCSPをCRLと区別し、CA Certificate自体のRevocationまで実行する

このページの到達点：OCSPの個別Status確認を説明し、Root CAがIntermediate CA Certificateを失効→Root CRL→Client Chainがdepth 1で失敗するところまで確認できる。
公式要求：Revoke certificates and certification authorities. Partial term: OCSP.
構造を先に確認
OCSP: 「このSerialの現在Statusは?」→ good / revoked / unknown Root CA ↓ revokes Intermediate CA Certificate Root CRL ↓ -crl_check_all client.crt自体はValidでも Intermediateがrevoked → Chain失敗
OCSP = Online Certificate Status Protocol
Verifierが「このCertificateは今どういうStatus？」とOCSP Responder（Statusを返すServer）へ個別問い合わせする仕組み。代表Statusは good / revoked / unknown。331.1ではCRLとの違いを理解し、ApacheでのOCSP Stapling設定は331.2へ送る。

CRLとOCSPを用途で分ける

CRLOCSP
基本失効Listを取得・参照特定CertificateのStatusを問い合わせ
識別SerialをList内で確認対象Certificate/SerialについてResponse
代表StatusListに掲載good / revoked / unknown
OCSPの深度：331.1ではOCSPがPartial term。Status確認の仕組みとCRLとの差を理解する。ApacheでOCSP Staplingを構成するのは331.2。

Intermediate CA自体をRoot CAで失効

openssl ca -batch -config root.cnf \ -revoke intermediate/certs/intermediate.crt \ -crl_reason CACompromise openssl ca -batch -config root.cnf \ -gencrl -out root/crl.pem
Root DB
V ... 1000 ... Intermediate CA
→
Root DB
R ... 1000 ... Intermediate CA

まだ失効していないClient CertでもChain全体が失敗する

cat root/crl.pem intermediate/crl.pem > chain-crls.pem openssl verify \ -CAfile root/certs/root.crt \ -untrusted intermediate/certs/intermediate.crt \ -CRLfile chain-crls.pem -crl_check_all \ client.crt
cat ... > chain-crls.pem
Root用CRLとIntermediate用CRLを1ファイルへ連結して検証へ渡す。
-crl_check_all
LeafだけでなくChain内の各Certificateについて、対応IssuerのCRLを使って失効を確認する。
depth 1
Leaf（depth 0）の1段上、つまりIntermediate CAで失敗したことを示す。
CN=LPIC303 Training Intermediate CA error 23 at 1 depth lookup: certificate revoked error client.crt: verification failed
Root CAの場合：Rootには通常その上位Issuerがいないため、下位CA（Subordinate CA）のように「親CAのCRLでRootを失効」とはできない。Root compromise時はTrust StoreからのDistrust/Removal等が重要になる。
EXAM DECISION

Certificate失効とCA失効を分ける

  • CRL → 失効List、OCSP → 個別Status
  • Intermediate CA失効 → そのCAを通る下位Chainへ影響
  • Root CAは親CAのCRLではなくTrust Anchor管理が重要
← 前のページ次のページ →
331.1 · 14/1409 CT / ACME系
🟡 Understand CT🔵 Basic feature

Certificate Transparency / ACME系は「必要な深さだけ正確に」

このページの到達点：CTのLog/SCT/監視の役割を説明し、Let’s Encrypt / ACME / Certbot / CFSSLをCA・Protocol・Client・Toolkitで即座に区別できる。
公式要求：Understand trust chains and PKI, including Certificate Transparency. Basic feature knowledge of Let’s Encrypt, ACME, certbot and CFSSL.
構造を先に確認
Certificate Transparency: CA/Certificate holder等がCertificate/PrecertificateをCT Logへ提出 ↓ Logが受理 → SCT (Signed Certificate Timestamp) を返す ↓ SCT = 定めた期限内にLogへ追記するというLogの署名付き約束 ↓ 追記型Log（過去を勝手に消し替えにくい）/ Monitorで不正・誤発行を監査 Let's Encrypt = CA ACME = Certificate発行/更新自動化Protocol Certbot = ACME Client CFSSL = PKI/TLS Toolkit
CT
Certificate Transparency。Certificate発行を公開Logで監査可能にし、不正・誤発行を発見しやすくする仕組み。
SCT
Signed Certificate Timestamp。CT LogがEntryを受理し、期限内にLogへ追加すると約束する署名付き応答。
Precertificate
CT Logへ事前登録するために使われるCertificate相当の登録データ。最終Certificateそのものと区別して扱う。
Merkle Tree
Logの整合性を効率よく検証する木構造。LPIC-303では数学的仕組みを解く必要はなく、「追記型Logを検証しやすくする構造」と理解すればよい。
ACME
Automatic Certificate Management Environment。Certificate発行・更新を自動化するProtocol。
Monitor
CT Logを継続的に確認し、自分のDomain向けの不審なCertificate発行などを発見する側。
ここまでで十分：CTではLog/SCT/監視の目的が説明できればよい。Merkle TreeのAlgorithmやCT実装の内部構造を深掘りしない。

Certificate Transparencyは「発行を監査可能にする」

SubmitCertificate / Precertificate
→
CT Log受理
→
SCTLogへ追記する署名付き約束
→
AppendMerkle Treeへ追加
→
Monitor監査

目的はCertificate内容を秘密にすることではなく、不正・誤発行を発見しやすくすること。SCTは「Logに既に格納済み」という意味ではなく、Logが定めた期限内に登録データを追加するという署名付き約束として理解する。

ACME系を役割で即答する

Let's Encrypt (CA) ▲ │ ACME Protocol │ Certbot (ACME Client) CFSSL = PKI / TLS Toolkit
項目何者決定語
Let's EncryptPublic CA（一般に信頼されるCA）Certificate発行者
ACMEProtocol発行/更新自動化
CertbotACME ClientACMEを利用するClient Tool
CFSSLPKI/TLS ToolkitCA/Certificate関連Tool群
331.1 EXIT CHECK
X.509 Fields/Extensions/Lifecycleを説明・読解✓
Public/Private Key生成・管理、PEM/DER/PKCS識別✓
Server/Client CSR→Intermediate CA発行✓
Root/Intermediate CA構築・DB/Serial運用・Private Key保護✓
Root→Intermediate→Leaf Chain成功/失敗をverify✓
Leaf Revoke→CRL→revoked判定、Intermediate CA Revokeまで✓
CT / Let's Encrypt / ACME / Certbot / CFSSLを要求深度通り識別✓
331.1 COMPLETE： EXIT CHECKを満たせれば、331.2でCertificate/Trust ChainをTLSへ適用する準備ができている。
EXAM DECISION

要求深度を上げすぎない

  • CT → 不正/誤発行を監査可能にする仕組み
  • Let’s Encrypt=CA / ACME=Protocol / Certbot=Client
  • CFSSL=PKI/TLS Toolkit。全option暗記へ広げない
← 前のページObjective問題へ →
331.1 X.509 / PKI · CHECKPOINTObjective末尾
Weight 5客観判定50 → 75 → 100%

331.1 X.509 / PKI：学習直後にここで解く

本文を読み終えた直後に、そのObjectiveだけを確認する。別ページへ移動して問題を探さない。誤答した問題から該当ノートへ戻り、再度ここへ戻る。

合格条件： 50%は基礎選択式11問中10問以上、75%は選択肢なし再現11問中10問以上。75%到達から72時間後、専用実戦Bankから11問中10問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。
現在の到達度
選択式から開始
0%
問題プール 42問小テーマ 10 実戦Bank 20問直近重複を抑制未出題優先
小テーマ別履歴問題を解くと正答率を表示
全体到達度を見る

Objective Check

100%専用： 72時間後の再テストでは既存564問ではなく、このObjective専用の実戦相当20問から出題する。各問は複数知識・近い誤答・設定/出力/状況判断のいずれかを含み、誤答時は全選択肢の違いまで確認する。
出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。
この問題の役割：Objective理解の客観Checkpoint。実試験の出題再現ではないが、固定問題の暗記だけでは突破しにくい構成にする。
← Objective本文の最後へ次の推奨Objectiveへ →
← 332.2 Host IDS
全体進捗·Checkpoint
331.2 TLS / X.509 Auth →