LPIC-303 新版ノート331.2 TLS / X.509 Auth / v69 Learning App
← 331.1 X.509 / PKI
全体進捗·Checkpoint
331.3 Encrypted FS →
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.1331.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を大きく時代で整理

名前この章での扱い
SSLv3TLS以前の古いProtocol。現代の新規構成では使用対象にしない。
TLSv1.0 / TLSv1.1旧Version。互換性の話で出ることはあるが、新規の安全な構成で中心にしない。
TLSv1.2 / TLSv1.3331.2の実習で許可・TestするVersion。Apache/OpenSSLの対応状況は実環境Versionに依存。
試験での軸：個別Cipher暗記より、「古いProtocolを無効化し、必要なVersionをSSLProtocolで制御する」ことを理解する。

VersionとCipherを混ぜない

設定したいものApache側判断
受け付けるTLS VersionSSLProtocolVersionのON/OFF
交渉可能なCipher SuiteSSLCipherSuite暗号条件の集合
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の有効値を全部区別する

値意味
noneClient Certificateを要求しない。
optionalClientはCertificateを提示してもよい。提示された場合は有効なChainとして検証する。
require有効なClient Certificateを必須にする。
optional_no_caClient 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何をする?
SSLUseStaplingApache自身のServer Certificateに対するOCSP ResponseをClientへStapleする。
SSLOCSPEnableApacheが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 ErrorLeaf/Intermediate送信、Trust Anchor、-showcerts＋verify
特定TLS Versionだけ失敗SSLProtocolとClient testのVersion指定
Client Cert requiredSSLVerifyClient、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からランダム出題する。
現在の到達度
選択式から開始
0%
問題プール 41問小テーマ 8 実戦Bank 16問直近重複を抑制未出題優先
小テーマ別履歴問題を解くと正答率を表示
全体到達度を見る

Objective Check

出題方式：初回は小テーマをできるだけ横断し、未出題・出題回数の少ない問題を優先する。再挑戦では小テーマ網羅より直近問題の重複回避を優先し、必要な場合だけ再利用する。
この問題の役割：Objective理解の客観Checkpoint。50%/75%はObjective理解の確認、100%は専用実戦Bankで状況判断・設定/出力読解・近い選択肢まで確認する。
← Objective本文の最後へ次の推奨Objectiveへ →
← 331.1 X.509 / PKI
全体進捗·Checkpoint
331.3 Encrypted FS →