LPIC-3 Security303-300 v3.0331.2Weight 4Configure / Use7 themes / 8 pages

331.2 X.509 Certificates for Encryption, Signing and Authentication

331.1で作ったCertificate/Trust Chainを、今度はTLSとApache HTTPD 2.4+の実際のHTTPS・Server/Client Authenticationへ接続する。

331.2の最終到達点
SSL/TLSのVersionとCipherの役割を理解し、Apache HTTPD + mod_sslでHTTPS、SNI、HSTS、Certificate Chain、Protocol/Cipher設定、Client Certificate認証、OCSP Staplingを構成できる。OpenSSLのs_client/s_serverで成功・失敗を検証できる。

Objective判定： このObjectiveの最後に客観Checkpointを配置。学習後は末尾の問題へ。

01 TLS全体像02 HTTPS / mod_ssl03 SNI / HSTS04 Chain / Cipher05 Client Certificate06 OCSP Stapling07 OpenSSL Test

LPI公式：Weight 4。Apache HTTPD 2.4+を対象に、HTTPS/SNI/HSTS、Certificate Chain/Cipher、Certificate User Authentication、OCSP Stapling、OpenSSL client/server testまで要求。

331.1から継続：331.1のTrust Chain終了時に作成した~/lpic303-3312-lab（失効前Snapshot）を使う。root/certs/root.crt、intermediate/certs/intermediate.crt、server.crt/server.key、client.crt/client.keyが有効な状態で残っている。

なぜSnapshotが必要？331.1の最後では失効処理そのものを学ぶため、元LabのServer CertificateとIntermediate CAをRevokeする。331.2では有効なTLS Server/Client Certificateが必要なので、失効前状態を分離して使う。

DEPTH RULE

理解だけで終わらない

TLS Version/Cipher → 原理と設定位置を理解
Apache / Client Auth / Stapling → 実設定＋検証まで
個々のCipher Suite名の丸暗記はしない（LPI公式もcipher-specific knowledge不要）

← 331.1 331.2開始 →

331.2 · 01/0801 TLS全体像

🟡 UnderstandSSL / TLS

TLSは「相手を確認して、通信条件と共有秘密を決め、保護通信へ移る」

このページの到達点：SSLとTLS、Protocol VersionとCipherの違いを説明し、TLS接続でCertificateがどこに使われるかを331.1と接続できる。

公式要求：Understand SSL, TLS, including protocol versions and ciphers.

細かいPacket暗記より「何が決まるか」

Client │ ClientHello │ ├─ 対応Protocol Version │ ├─ 対応Cipher/暗号条件 │ └─ SNI（接続したいhostname） ▼ Server │ ServerHello → Version/条件を選択 │ Certificate → Server Identity + Public Key ▼ Client │ 331.1のTrust ChainでCertificateを検証 │ Key Exchangeから共有秘密を作る ▼ 暗号化されたApplication Data（例: HTTP → HTTPS）

SSL

Secure Sockets Layer。TLSの前身。試験ではSSL/TLSという表現が残るが、現在の実運用ではTLSが中心。

TLS

Transport Layer Security。Application Dataを送る前にPeer Authentication・鍵合意等を行い、機密性・完全性を持つ保護通信を作るProtocol。

Protocol Version

TLSv1.2 / TLSv1.3のように、Handshakeや利用可能機能のRule setを表す。

Cipher Suite

TLSで利用する暗号Algorithmの組合せ・選択条件。LPI 331.2では個別Cipher名の知識は不要で、「許可する集合を設定できる」ことが重要。

Handshake

Application Data送信前に、Version・暗号条件・Peer認証・鍵材料等を決める段階。

Protocol Versionを大きく時代で整理

名前	この章での扱い
SSLv3	TLS以前の古いProtocol。現代の新規構成では使用対象にしない。
TLSv1.0 / TLSv1.1	旧Version。互換性の話で出ることはあるが、新規の安全な構成で中心にしない。
TLSv1.2 / TLSv1.3	331.2の実習で許可・TestするVersion。Apache/OpenSSLの対応状況は実環境Versionに依存。

試験での軸：個別Cipher暗記より、「古いProtocolを無効化し、必要なVersionをSSLProtocolで制御する」ことを理解する。

VersionとCipherを混ぜない

設定したいもの	Apache側	判断
受け付けるTLS Version	`SSLProtocol`	VersionのON/OFF
交渉可能なCipher Suite	`SSLCipherSuite`	暗号条件の集合

TLS 1.2と1.3は内部が完全に同一ではない：HandshakeやCipher Suiteの意味づけに差がある。このノートでは個別Cipherを暗記せず、「VersionとCipher設定は別軸」「Certificate認証と鍵合意を経て保護通信へ進む」という軸を掴む。

EXAM DECISION

問題文の決定語

「TLS 1.2/1.3を許可・禁止」→ SSLProtocol
「交渉可能な暗号Suiteを調整」→ SSLCipherSuite
「Serverが本物か」→ X.509 Certificate / Trust Chain

← 331.2全体次のページ →

331.2 · 02/0802 HTTPS / mod_ssl

🔴 ConfigureApache HTTPD 2.4+

Apache HTTPS：mod_sslにCertificateとPrivate Keyを結び付ける

このページの到達点：HTTPS VirtualHostの最低限を組み、どのDirectiveがCertificate・Private Key・TLS Engineを担当するか説明できる。

公式要求：Configure Apache HTTPD with mod_ssl to provide HTTPS service. Partial list: httpd.conf, mod_ssl.

331.1で作ったものをApacheへ

Apache HTTPD └─ mod_ssl ├─ SSLEngine on ├─ SSLCertificateFile → Server Certificate / Chain ├─ SSLCertificateKeyFile → 対応Private Key └─ Listen / VirtualHost → TLSを受けるAddress:Port

mod_sslとは：Apache HTTP ServerへSSL/TLS機能を追加するModule。暗号処理自体はOpenSSLを利用する。httpd.confの実際の場所や追加confの分割方法はDistributionで異なる。

Lab開始：

cd ~/lpic303-3312-lab pwd

Apache設定へCertificate Pathを書くときは、pwdで得た実際のabsolute pathへ置き換える。Shellの~や$HOMEをそのままApache設定へ書く前提にはしない。

Moduleを確認

apachectl -M | grep -E 'ssl_module|headers_module'

ssl_moduleはHTTPS本体、headers_moduleは後のHSTS Header設定で使う。

最低限のHTTPS VirtualHost

Listen 443 <VirtualHost *:443> ServerName server.example.com SSLEngine on SSLCertificateFile /absolute/path/to/lpic303-3312-lab/server.crt SSLCertificateKeyFile /absolute/path/to/lpic303-3312-lab/server.key </VirtualHost>

SSLEngine on

このVirtualHostでTLSを有効化。

SSLCertificateFile

ServerのX.509 Certificateを指定。Apache 2.4.8+ではIntermediateも同じPEMに含められる。

SSLCertificateKeyFile

CertificateのPublic Keyと対応するPrivate Keyを指定。

ServerName

このVirtualHostが扱うhostname。SNIでの選択にも関係する。

この段階のCertificate：まずHTTPSを起動するためLeafのserver.crtを指定している。ClientへIntermediateまで正しく配るFull Chain構成は「Chain / Cipher」ページで完成させる。

Encrypted Private Key：Private KeyがPassphraseで暗号化されている場合、Apache起動時にPassphrase入力が必要になる。331.1の「Private Key保護」と運用方法を切り離さない。

変更したらSyntaxを先に確認

apachectl configtest # Syntax OK を確認してから、環境に応じてreload/restart

典型的な失敗：CertificateとPrivate Keyが対応していない、Path/Permissionが違う、mod_sslがLoadされていない、443をListenしていない。まずError Logとconfigtestを確認する。

EXAM DECISION

Directiveを役割で選ぶ

TLS自体を有効化 → SSLEngine on
Certificate → SSLCertificateFile
Private Key → SSLCertificateKeyFile

← 前のページ次のページ →

331.2 · 03/0803 SNI / HSTS

🔴 ConfigureSNI / HSTS

SNIとHSTSは「何を解決するか」が別

このページの到達点：1つのIP:PortでhostnameごとにCertificateを出し分けるSNIと、BrowserへHTTPS継続利用を指示するHSTSを設定・確認できる。

公式要求：Configure Apache HTTPD with mod_ssl to provide HTTPS service, including SNI and HSTS.

TLS開始前後の位置が違う

SNI: ClientHello ── hostname=server.example.com ─→ Apache ├─ server.example.com VHost → server.crt └─ other.example.com VHost → other.crt HSTS: HTTPS Response Strict-Transport-Security: max-age=... ↓ Browserが「今後このHostはHTTPSで接続」と記憶

SNI：TLS Handshakeの時点でhostnameを伝える

SNI確認用に2枚目のCertificateを用意：331.1のCA発行Flowを増やさず、ここでは「どのCertificateが選ばれたか」を見分けるだけの短期Self-signed Certificateを作る。Trust Chain学習には使わない。

openssl req -x509 -newkey rsa:2048 -noenc \ -keyout other.key -out other.crt -days 30 \ -subj "/CN=other.example.com" \ -addext "subjectAltName=DNS:other.example.com" chmod 600 other.key

目的：同じIP:Portに異なるCertificateを持つ2つのVirtualHostを置き、-servernameで選択が変わることだけを確認する。

<VirtualHost *:443> ServerName server.example.com SSLEngine on SSLCertificateFile /absolute/path/to/lpic303-3312-lab/server.crt SSLCertificateKeyFile /absolute/path/to/lpic303-3312-lab/server.key </VirtualHost> <VirtualHost *:443> ServerName other.example.com SSLEngine on SSLCertificateFile /absolute/path/to/lpic303-3312-lab/other.crt SSLCertificateKeyFile /absolute/path/to/lpic303-3312-lab/other.key </VirtualHost>

SNIをOpenSSLで確認

openssl s_client -connect 127.0.0.1:443 \ -servername server.example.com -showcerts openssl s_client -connect 127.0.0.1:443 \ -servername other.example.com -showcerts

server.example.com → subject=CN=server.example.com other.example.com → subject=CN=other.example.com

HTTP Host Headerより前：Server CertificateはHTTP Requestを読む前のTLS Handshakeで必要。そのためSNIはClientHello内でhostnameを伝える。

HSTS：HTTP Response HeaderでBrowserへ指示

# mod_headersを利用する代表例 Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

HSTS = HTTP Strict Transport Security。HSTS自体はmod_ssl専用DirectiveではなくHTTP Response Header。Apacheでは通常mod_headersのHeader Directiveで設定する。HTTPSで受け取ったBrowserが以後のHTTP接続をHTTPSへ切り替える判断に使う。

Response Header確認

curl -k -I --resolve server.example.com:443:127.0.0.1 \ https://server.example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains

混同：SNIは「どのCertificate/VHostを選ぶか」。HSTSは「Browserへ今後HTTPSを使わせる」。HSTSは単なるHTTP→HTTPS Redirectそのものではない。

EXAM DECISION

決定語

同一IPで複数HTTPS hostname → SNI
BrowserへHTTPS利用を継続させる → HSTS

← 前のページ次のページ →

331.2 · 04/0804 Chain / Cipher

🔴 ConfigureChain / Protocol / Cipher

Certificate Chainを正しく配り、TLS VersionとCipherの許可範囲を調整する

このページの到達点：ApacheがLeaf＋IntermediateをClientへ送る構成を作り、SSLProtocol/SSLCipherSuiteの役割を区別してテストできる。

公式要求：Configure mod_ssl to serve certificate chains and adjust cipher configuration (no cipher-specific knowledge).

Serverが送るもの / Clientが元から信頼するもの

Apacheから送信 server.crt (Leaf) ↓ intermediate.crt 通常送信しない root.crt ← Client側Trust StoreのTrust Anchorとして保持 Client: Leaf → Intermediate → Root(Trust Anchor) を検証

Apache 2.4ではFull ChainをSSLCertificateFileへ

cat server.crt intermediate/certs/intermediate.crt > server-fullchain.pem SSLCertificateFile /absolute/path/to/lpic303-3312-lab/server-fullchain.pem SSLCertificateKeyFile /absolute/path/to/lpic303-3312-lab/server.key

Apache 2.4.8+：SSLCertificateFileへLeafの後ろにIntermediateを含められる。古いSSLCertificateChainFileは2.4.8以降ではobsolete/deprecated扱いなので、新規教材では主手順にしない。

Serverが送ったCertificateを確認

openssl s_client -connect 127.0.0.1:443 \ -servername server.example.com -showcerts

-showcerts：Serverが送ったCertificate listを表示する。これは検証済みChainそのものではないので、Trust確認は別途-verifyCAfile等で行う。

VersionとCipherは別Directive

# 例：TLS 1.2 / 1.3を許可 SSLProtocol -all +TLSv1.2 +TLSv1.3 # Cipher Suiteの許可範囲を調整する例 SSLCipherSuite HIGH:!aNULL

LPIの深度：個々のCipher Suite名を暗記する必要はない。SSLCipherSuiteが交渉可能な暗号条件を調整するDirectiveであること、実環境の既定値やTLS 1.3の扱いはApache/OpenSSL versionに依存することを理解する。

Versionを明示してTest

openssl s_client -connect 127.0.0.1:443 \ -servername server.example.com -tls1_2 -brief openssl s_client -connect 127.0.0.1:443 \ -servername server.example.com -tls1_3 -brief

Protocol version: TLSv1.2 Protocol version: TLSv1.3

EXAM DECISION

3つを分離

Chainを配る → SSLCertificateFileのFull Chain
Version → SSLProtocol
Cipher許可範囲 → SSLCipherSuite

← 前のページ次のページ →

331.2 · 05/0805 Client Certificate

🔴 ConfigureUser / Client Authentication

Client Certificate認証：Server側がClientのTrust Chainを検証する

このページの到達点：通常のServer Authenticationとの向きを反転して理解し、ApacheでClient Certificateを要求・検証し、OpenSSLで「なし→失敗 / あり→成功」を確認できる。

公式要求：Configure Apache HTTPD with mod_ssl to authenticate users using certificates.

誰が誰を検証するか

通常HTTPS: Client ── Server Certificateを検証 ─→ Server Client Certificate Authentication: Client ←── Certificateを要求 ── Server Client ── Client Certificate ─────→ Server ↓ SSLCACertificateFileのCAで検証 ↓ User/Clientを認証

Apache設定

学習用に別Portへ分ける：通常HTTPSの確認を壊さずClient Certificate必須動作を比較するため、例では同じserver.example.comをPort 8444でもListenさせる。

Listen 8444 <VirtualHost *:8444> ServerName server.example.com SSLEngine on SSLCertificateFile /absolute/path/to/lpic303-3312-lab/server-fullchain.pem SSLCertificateKeyFile /absolute/path/to/lpic303-3312-lab/server.key SSLCACertificateFile /absolute/path/to/lpic303-3312-lab/root/certs/root.crt SSLVerifyClient require SSLVerifyDepth 2 # CertificateのCNをApache側usernameとして利用する例 SSLUserName SSL_CLIENT_S_DN_CN </VirtualHost>

SSLCACertificateFile

Client Certificateを検証するために信頼するCA Certificate群。

SSLVerifyDepth

Client Certificate Chainで許可する検証深度の上限。

SSLUserName

Client Certificateのどの情報をApacheのUser Nameとして扱うかを指定できる。

`SSLVerifyClient`の有効値を全部区別する

値	意味
`none`	Client Certificateを要求しない。
`optional`	ClientはCertificateを提示してもよい。提示された場合は有効なChainとして検証する。
`require`	有効なClient Certificateを必須にする。
`optional_no_ca`	Client Certificateを提示できるが、CA検証成功を必須にしない。Apache公式もClient Authentication用途として依存できないと注意。

OpenSSLで失敗→成功を比較

# Client Certificateなし → requireなら失敗 openssl s_client -connect 127.0.0.1:8444 \ -servername server.example.com \ -verifyCAfile root/certs/root.crt -verify_return_error # Client Certificate＋Private Key＋Intermediateを提示 openssl s_client -connect 127.0.0.1:8444 \ -servername server.example.com \ -verifyCAfile root/certs/root.crt -verify_return_error \ -cert client.crt -key client.key \ -cert_chain intermediate/certs/intermediate.crt

なし: tlsv13 alert certificate required あり: Protocol version: TLSv1.3 / Verification: OK

よくある原因：Client CertificateのEKUがclientAuthでない、Serverが信頼するCAが違う、IntermediateをClientが送っていない、SSLVerifyDepthが小さすぎる。

EXAM DECISION

Server Certificate認証との向きを見る

ServerをClientが確認 → 通常HTTPS
Client/UserをServerがCertificateで確認 → SSLVerifyClient + Client CA

← 前のページ次のページ →

331.2 · 06/0806 OCSP Stapling

🔴 ConfigureOCSP Stapling

OCSP Stapling：Serverが自分のCertificate Statusを取得してHandshakeへ添付する

このページの到達点：OCSP Staplingの通信方向を説明し、ApacheでCache＋Staplingを有効化してs_client -statusでResponseを確認できる。

公式要求：Configure Apache HTTPD with mod_ssl to provide OCSP stapling.

331.1のOCSPをServer側で肩代わり

通常OCSP: Client ─────────→ OCSP Responder OCSP Stapling: Apache ── Status Query ─→ OCSP Responder ↑ ↓ └── OCSP ResponseをCache ↓ TLS HandshakeでClientへ「Staple」 ↓ ClientがStatusを確認

331.1 Training CertificateにはOCSP URI(AIA)を入れていない：そのままSSLUseStapling onだけではResponder URLを取得できない。実習ではLocal OCSP Responderを起動し、SSLStaplingForceURLでそのURLを明示する。

1. Local OCSP Responderを起動

cd ~/lpic303-3312-lab openssl ocsp \ -index intermediate/index.txt \ -port 8888 \ -rsigner intermediate/certs/intermediate.crt \ -rkey intermediate/private/intermediate.key \ -CA intermediate/certs/intermediate.crt

Intermediate Private KeyがPassphrase保護されているため、Responder起動時に入力を求められる。実習中はこのTerminalを起動したままにする。

2. Apache設定

# Server/VHost側 SSLUseStapling on SSLStaplingForceURL "http://127.0.0.1:8888" # Server config側：Stapling Cacheは前提 SSLStaplingCache "shmcb:/tmp/lpic303_ocsp_stapling(128000)"

SSLUseStapling on

ClientがCertificate Statusを要求した場合、ApacheがOCSP ResponseをTLS Handshakeへ含める。

SSLStaplingForceURL

CertificateのAIAにあるOCSP URIを上書きする。AIAにURIがない学習Certificateでも、利用可能なResponderが分かっていれば明示できる。

SSLStaplingCache

取得したOCSP ResponseをProcess間でCacheする。Apache 2.4 docsではStapling有効化の前提。

Client側からStapled Responseを要求

openssl s_client -connect 127.0.0.1:443 \ -servername server.example.com -status

OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Responder Id: ...

似たDirectiveを混同しない

Directive	何をする?
`SSLUseStapling`	Apache自身のServer Certificateに対するOCSP ResponseをClientへStapleする。
`SSLOCSPEnable`	ApacheがClient Certificate Chainを検証するときにOCSP Validationを行う別機能。

Staplingが出ない：CertificateにResponder情報がない/Responderへ到達できない、Cache設定がない、Responseが期限切れ、Intermediate/Issuer情報が不足などを確認する。

EXAM DECISION

「誰のStatus？」で分ける

Server CertificateのStatusをHandshakeへ添付 → OCSP Stapling / SSLUseStapling
Client CertificateをOCSPで追加検証 → SSLOCSPEnable（別機能）

← 前のページ次のページ →

331.2 · 07/0807 OpenSSL Test

🔴 Useopenssl s_client

`s_client`：TLS Serverを外側から検査する

このページの到達点：SNI、Certificate list、Trust Verification、Protocol Version、OCSP Stapling、Client Certificateの有無を目的別にTestできる。

公式要求：Use OpenSSL for SSL/TLS client and server tests.

「何を知りたい？」→ Option

接続できる? → -connect 正しいSNI Certificate?→ -servername 何を送ってきた? → -showcerts Trustできる? → -verifyCAfile + -verify_return_error TLS Versionは? → -tls1_2 / -tls1_3 / -brief Staplingは? → -status Client Certを送る? → -cert / -key / -cert_chain

基本Test

openssl s_client \ -connect 127.0.0.1:443 \ -servername server.example.com \ -showcerts \ -verifyCAfile root/certs/root.crt \ -verify_return_error

-servername

SNI hostnameをClientHelloへ入れる。Name-based HTTPSのCertificate選択確認に重要。

-showcerts

Serverが実際に送ったCertificate listを表示。検証済みChainとは限らない。

-verifyCAfile

Server Certificateを検証するTrust Anchor等を指定。

-verify_return_error

Certificate検証ErrorをHandshake失敗として返す。Test toolの「Errorを表示しながら続行」挙動を避ける。

重要：s_clientは診断Toolなので、既定ではCertificate検証Errorが出ても接続処理を続ける場合がある。「CONNECTEDが出たからTrust OK」と判断しない。厳密に失敗させたいTestでは-verify_return_errorを付ける。

目的別の短いTest

目的	例
TLS 1.2	`-tls1_2 -brief`
TLS 1.3	`-tls1_3 -brief`
OCSP Stapling	`-status`
Client Certificate提示	`-cert client.crt -key client.key -cert_chain intermediate/certs/intermediate.crt`

331.2実動作確認例

SNI server.example.com → subject=CN=server.example.com SNI other.example.com → subject=CN=other.example.com Server Chain count → 2 (Leaf + Intermediate) Verification → OK TLS 1.2 → Protocol version: TLSv1.2 TLS 1.3 → Protocol version: TLSv1.3 Client Certなし → alert certificate required Client Certあり → Verification: OK OCSP Stapling → OCSP Response Status: successful

EXAM DECISION

`s_client`は「外から何を確認するか」

SNI → -servername
Serverが送るCertificate → -showcerts
Trust Errorで本当に止める → -verify_return_error
Stapling → -status

← 前のページ次のページ →

331.2 · 08/0807 OpenSSL Test

🔴 Useopenssl s_server / Troubleshooting

`s_server`：Apacheを外してTLS Server側だけをTestし、障害を層で切り分ける

このページの到達点：OpenSSLだけで簡易TLS Serverを起動でき、Apache設定・Certificate Chain・TLS Version・Client Auth・Staplingのどこが原因か順番に切り分けられる。

公式要求：Use OpenSSL for SSL/TLS client and server tests.

Apacheを疑う前にTLS素材だけTestできる

server.crt + server.key + intermediate.crt ↓ openssl s_server ↓ TLS openssl s_client ここが成功 → Key/Certificate/TLS素材は概ね動く Apacheで失敗 → VirtualHost/mod_ssl/Path/Directive側を重点確認

簡易TLS Serverを起動

openssl s_server -accept 9443 \ -cert server.crt \ -key server.key \ -cert_chain intermediate/certs/intermediate.crt \ -www

s_server：本番Web ServerではなくTLSのTest Tool。331.1で作ったCertificate/Private Key/ChainがServer側で使えるかをApacheから切り離して確認できる。

別Terminalから接続

openssl s_client -connect 127.0.0.1:9443 \ -servername server.example.com \ -verifyCAfile root/certs/root.crt \ -verify_return_error

症状から確認順を固定する

症状	最初に確認
TCP/TLS接続自体ができない	Listen/Port/Process → `SSLEngine` → Error Log
違うCertificateが返る	SNI `-servername` / `ServerName` / VHost順
Trust Chain Error	Leaf/Intermediate送信、Trust Anchor、`-showcerts`＋verify
特定TLS Versionだけ失敗	`SSLProtocol`とClient testのVersion指定
Client Cert required	`SSLVerifyClient`、Client `-cert/-key/-cert_chain`、Client CA
Staplingがない	`SSLUseStapling`、`SSLStaplingCache`、Responder到達性、`s_client -status`

331.2 EXIT CHECK

SSL/TLS、Version、Cipherの役割を区別✓

Apache + mod_sslでHTTPSを構成✓

SNIでhostname別Certificateを選択、HSTSをHeaderで設定✓

Leaf＋Intermediate Chainを配り、Protocol/Cipherを調整✓

Client Certificate認証をrequire/CA/Depthで構成✓

OCSP StaplingをCache＋UseStaplingで構成し-statusで確認✓

s_client / s_serverで成功・失敗を切り分け✓

監査基準：LPI 303-300 v3.0 331.2、Apache HTTP Server 2.4 mod_ssl documentation、OpenSSL s_client / s_server documentation。実習構成はApache 2.4.68 + OpenSSL 3.5.5でSyntax/接続/SNI/Chain/TLS1.2/1.3/HSTS/Client Auth/OCSP Staplingを確認。

331.2 COMPLETE

試験では「どの層の設定か」を先に分ける

TLS Version/Cipher → Handshake条件
Certificate/Chain/SNI → Server Identityと配布
Client Cert → Client/User Authentication
OCSP Stapling → Server Certificate Status
OpenSSL → 外側/内側から検証

← 前のページ Objective問題へ →

331.2 TLS / X.509 Auth · CHECKPOINTObjective末尾

Weight 4客観判定50 → 75 → 100%

331.2 TLS / X.509 Auth：学習直後にここで解く

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

合格条件： 50%は基礎選択式9問中8問以上、75%は選択肢なし再現9問中8問以上。75%到達から72時間後、専用実戦Bankから10問中9問以上で100%。さらに各段階で全小テーマを最低1問正解する必要がある。毎回Question Bankからランダム出題する。

現在の到達度

選択式から開始

問題プール 41問小テーマ 8 実戦Bank 16問直近重複を抑制未出題優先

小テーマ別履歴問題を解くと正答率を表示

全体到達度を見る

Objective Check

JavaScriptが無効：このCheckpointの自動採点と進捗保存はJavaScript実行環境で利用してください。本文はそのまま閲覧できます。

出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。

この問題の役割：Objective理解の客観Checkpoint。50%/75%はObjective理解の確認、100%は専用実戦Bankで状況判断・設定/出力読解・近い選択肢まで確認する。

← Objective本文の最後へ次の推奨Objectiveへ →

← 331.1 X.509 / PKI

全体進捗·Checkpoint

331.3 Encrypted FS →

331.2 X.509 Certificates for Encryption, Signing and Authentication

理解だけで終わらない

TLSは「相手を確認して、通信条件と共有秘密を決め、保護通信へ移る」

Protocol Versionを大きく時代で整理

VersionとCipherを混ぜない

問題文の決定語

Apache HTTPS：mod_sslにCertificateとPrivate Keyを結び付ける

Moduleを確認

最低限のHTTPS VirtualHost

変更したらSyntaxを先に確認

Directiveを役割で選ぶ

SNIとHSTSは「何を解決するか」が別

SNI：TLS Handshakeの時点でhostnameを伝える

HSTS：HTTP Response HeaderでBrowserへ指示

決定語

Certificate Chainを正しく配り、TLS VersionとCipherの許可範囲を調整する

Apache 2.4ではFull ChainをSSLCertificateFileへ

VersionとCipherは別Directive

3つを分離

Client Certificate認証：Server側がClientのTrust Chainを検証する

Apache設定

SSLVerifyClientの有効値を全部区別する

Server Certificate認証との向きを見る

OCSP Stapling：Serverが自分のCertificate Statusを取得してHandshakeへ添付する

1. Local OCSP Responderを起動

2. Apache設定

似たDirectiveを混同しない

「誰のStatus？」で分ける

s_client：TLS Serverを外側から検査する

基本Test

目的別の短いTest

s_clientは「外から何を確認するか」

s_server：Apacheを外してTLS Server側だけをTestし、障害を層で切り分ける

簡易TLS Serverを起動

症状から確認順を固定する

試験では「どの層の設定か」を先に分ける

331.2 TLS / X.509 Auth：学習直後にここで解く

Objective Check

`SSLVerifyClient`の有効値を全部区別する

`s_client`：TLS Serverを外側から検査する

`s_client`は「外から何を確認するか」

`s_server`：Apacheを外してTLS Server側だけをTestし、障害を層で切り分ける