証明書チェーン
原書は実際の運用についての仕組み・説明がやや簡素な為、以下のサイトを参照しました。
cert-manager : TLS用語
証明書チェーンが必要な理由
ルートを安全に保つため
ルートCAの証明書は非常に長い期間（年、数十年）をかけてあらゆるネットワーク上に配布されるため事実上取り換えが効かない存在になっています。
またルートCAの鍵が破られてしまうとあらゆるドメイン名の証明書を詐称できてしまう事になります。ルートCAの鍵が破られるとその鍵に関係する証明書全てを失効させる必要が生じます。
※かつてはルートCAの鍵を直接使ってエンドエンティティ用のリーフ証明書を発行するCAもありましたが、この方法は原書執筆時点であまりにも危険だと考えられている、と書かれています。
またBaseline Requirementsには「ルートCAの鍵を扱う場合は直接手入力でコマンド実行すること（＝自動化しないこと）を要求しています。」言い換えるとルートCAの鍵はオフラインに保管しておくべきだという事です。
相互認証証明書のため
新しくCAの運用を開始する唯一の方法はCAの相互認証（cross-certification）によるものです。この相互認証も証明書チェーンです。新しいCAのルート証明書がインターネット上あまねく普及するには長い時間がかかるので最初は既に広く流通しているルート証明書で署名してもらう必要があります。時が経って古いデバイスが使用されなくなっていくと新しいルートCAの鍵も単体で有用になっていきます。
このような新しいCAのルート証明書の例としてLet's Encryptがあり、Let's Encryptの証明書の階層の説明や、Let's Encryptが自分たちのルート証明書へと移行する過程が参考になると記載されています。
区画化のため
ルートCA以外の下位のCAはオンラインで自動化されたシステムで運用されますが、下位のCA証明書を証明書の種類、企業の部門ごとに発行するCAを分けることでリスク分散が図れます。
下位のCAが発行できるリーフ証明書の総数に上限を設けることもできます。
移譲のため
大企業が自社の管理ドメインに対して有効な証明書を発行したい場合に、自社で独自のプライベートなルートCAをたてる方法もありますが、コスト面運用面の負担が大きくなります。そこで、自社CAをルートCAの下位のCAとして認証してもらう方法が出来ます。この場合自社CAの有効な名前空間（ドメイン名など）を制限する事が出来ます。また、ルートCAで企業独自の（下位のCAとした）CAの発行する証明書をルートCA側で制御する事も出来ます。
証明書チェーンの課題点
サーバー側の課題点
TLSにおいて1つの接続でサーバーが提示する証明書チェーンは1つだけです。しかしそのサーバーのリーフ証明書から続く信頼パスは複数のルート証明書に対する複数のパスがあることもよくあります。標準的な信頼パス、というようなものは存在しません
たとえば相互認証している場合、1つめのルートCAにいきつく信頼パスと2つめのルートCAにいきつくパスができることになります。
あるいはあるCAが1つの鍵に対して複数の証明書を発行している場合（よくある）、1つ1つの証明書に別々な信頼パスが生成されている、という事が言えます。
また、サーバーでは完全かつ有効な証明書チェーンを提示する事が求められますが、実装の問題、人系の運用の問題などからそれが出来ていないケースも多いようです。
クライアント側の課題点
上述のようにサーバー側で完全かつ有効な証明書チェーンを提示できない場合、クライアント側で信頼パスを完成させる試みが必要になります。たとえば、
X.509証明書の AIA（認証機関アクセス情報）拡張を使用して発行元のCAから情報を取得する
中間証明書や証明書チェーン全体のキャッシュをローカルに保持する
等を行うクライアントもあります。
また、クライアント側のソフトウェアでは信頼パスの構築と検証に関連したセキュリティ上の問題が多数あります。過去には多くの検証ライブラリーが単純な作業が失敗しています。（例として発行された証明書がCAに属する事の検証が失敗する）。ですが最近（原著執筆の2021年頃）のライブラリーは実用に耐えうる機能や安全性を備えています。このような進歩の背景には数々の問題に対して修正が施されてきた経緯があります。（原書の7章に詳しい説明・事例があります。）
証明書利用者
証明書の利用者が他者の発行した証明書を検証するためには信頼できるルート証明書の一覧を手元に保持している必要があります。多くのアプリケーションではTLS暗号化・証明書に関する操作をOSで処理させる構造になっています。
原書では証明書の利用者としてのメジャーな企業の姿勢や施策を説明しています。
アップル社
アップル社はiOS、macOS上で利用するルート証明書プログラムを運用しています。CAがアップル社のルート証明書プログラムに参加するためにはアップル社の監査を追加する事が必要で、さらにアップル社の顧客に対するビジネス上の価値があることを提示する必要があります。
Chrome
CHromeも以前はOSが提供する機能に証明書の操作を委ねていました。（例としてLinuxではMozillaのトラストストアを使用）。またChrome独自のPKIに対する多数の要求を満たす目的でChrome独自の機能拡張を追加しています。例として、
・信用しないルート証明書およびその他証明書のブラックリスト
・EV証明書を発行できるCAのリスト
・CTへの対応を一部または全部の証明書に追加で求める
をあげています。
2020年にChromeのためにGoogleが独自のルートトラストストアの運営を開始しています。Google社が調査してそれまで信頼されていたCAをChromeの信頼あるCAリストから削除した、というような記事もいくつかあります。
マイクロソフト社
マイクロソフト社はWindowsデスクトップ（クライアント）、サーバー、モバイルフォン（スマートフォン）で利用されるルート証明書プログラムを運用しています。CAがこのプログラムに参加するためには1年間の監査を通過し、かつマイクロソフト社の顧客にビジネス上の価値を提供する事を示す必要があります。
Mozilla
MozillaはMozilla製品で利用するために、特有の透明性を備えたルート証明書プログラムを運用しています。Mozillaのルートトラストストアは様々なLinuxディストリビューションのルートトラストストアのベースとしても利用されています。
CA Certification Authority 認証局 の条件
現在のインターネットのトラストモデルで最重要なのがCAです。CAはあらゆるドメイン名の証明書も発行できます。CAのルート証明書を多数のデバイスに組み込めればビジネスは簡単です。
原書でCAの具体的な条件として挙げているものを抜粋紹介します。
1.競争力のあるCAを組織する
・極めて機密性の高いルート証明書の鍵、および下位のCA証明書の鍵を防御しながら商業的な運用ができる鞏固で安全性の高い区画化されたネットワークを設計すること
・証明書のライフサイクルに対応すること
・各証明書利用者が要求するCTに従うこと
2.自分のルート証明書を様々なルート証明書プログラムに配置すること
・運用を開始するためにルート証明書の相互認証を行う事
古くはDV証明書の販売は利益の高いビジネスでしたが、2015年Let's Encrypt（無償の証明書を誰にでも提供する）が登場以降はそれほどでもなく価格下落している、と書かれています。
証明書のライフサイクル
証明書の申請
証明書はまず証明書所有者 SubscriberがCSR（Certificate Signing Request）を用意しCAに送信する事からはじまります。CSRには証明書の対象となるホスト名の一覧や証明書に含める公開鍵、公開鍵に対応する秘密鍵を所有していることの証明となるデジタル署名などが含まれます。
上図にあるように、CAはCSRの検証を実施します。CAによるCSRの検証手順は証明書の種類で異なります。
DV証明書 Domain Validated Certificate
DV証明書はドメイン名を管轄している事の証明（proof of control）に基づき発行されます。
proof of controlは従来は申請承認用メールアドレス宛にメールを送信し、受信者がメール記載のリンク先にアクセスする（メールを承認する）と証明書が発行されます。オフラインでの証明手段もあるようです（電話、郵送等）。
IPアドレスに対する証明書も同様な手順になります。
オンラインでの申請の場合、発行手順は完全に自動化されていて即座に発行されます。
極端な話、第3者が身分を偽ってDV証明書を取得することも出来てしまいます。
偽の証明書を要求する攻撃者は、世間一般に注目を集めるドメイン名をターゲットにすることが多いようです。このためCAでは狙われやすいドメイン名のリストを管理しており、それに含まれているドメイン名に対する証明書は手動での発行を行うようです。（Baseline Requirementsで要求されている運用事項になっています。）
OV証明書 Organization Validation Certificate
OV証明書はサイトを運営する組織が実在するかどうか、本物の組織が申請しているかを確認します。
OV証明書はインターネット上の記事によっては企業認証、と説明しているものもあります。
OV証明書の手続きは現在ではBaseline Requirements に標準化されたルールが記載されています。それ以前は発行方法や関連情報のエンコード方式などに矛盾が存在していたようです。
考え方としてはOV証明書の取得は匿名や第3者の偽装などはできないことになります。
EV証明書 Extended Validation Certificate
EV証明書はOV証明書よりもさらに厳格な本人性の検証を要求しています。
EV証明書を所有しているという事は、そのサイトがたいへん厳格で信頼できるサイトであることの証明にもなる、という事のようです。
EV証明書をインストールしたサイトをブラウザー表示すると、アドレスバーに鍵マークが表示され安全性をアピールできます。
EV証明書はこちらのサイトなどに詳しく説明があり参照させて頂きました。
Study SEC : EV証明書とは？
検証に成功したらCAは証明書を発行します。CAでは証明書そのものに加え、ルート証明書に至るまでに必要な中間証明書も用意します。主要なプラットフォーム向けの設定手順も用意します。
以上で証明書所有者は自身の製品、サービスで証明書を利用可能になります。
何も問題がなければ証明書の期限切れまで使用できます。もし、証明書に対応する秘密鍵が破られた場合には証明書は失効されます。手順は証明書の発行時と基本共通です。
また、PKIでは証明書の再発行、ということはありません。以前の証明書を失効して、別なあらたな証明書を発行する、という事になります。
証明書の有効期間の変遷
2006年以前 証明書の有効期間は決まっていなかった。（特に制約は無し）
2007年 EV証明書の有効期間が2年、と設定された
2012年 Baseline Requirementsで全ての証明書の上限が5年とされました。
2015年 全ての証明書の上限が39か月（3年3ヶ月）に短縮された
2018年 825日（2年と95日）に短縮
2020年 398日（1年と33日）に制限
---原著記載はここまで---
以降の予定を記載すると、、
2026年3月15日以降 200日に制限
2027年3月15日以降 100日
2029年3月15日以降 47日
※上記は証明書の場合です。ドメインはIPアドレスの認証期間（DV証明書）では、以下です。
2026年3月15日以降 200日に制限
2027年3月15日以降 100日
2029年3月15日以降 10日
余談ですが、日数の根拠あるのかな？と調べたらdigicert社記事でみつけました。
以下引用します。
47 日というのは場当たり的な日数と思えるかもしれませんが、次のような式で導き出されました。
200 日 = 6 か月の最長日数（184 日）+ 1 か月（30 日）の半分（15 日） + 1 日分の余裕
100 日 = 3 か月の最長日数（92 日）+ 1 か月（30 日）の 4 分の 1（7 日） + 1 日分の余裕
47 日 = 1 か月の最長日数（31 日）+ 1 か月（30 日）の半分（15 日） + 1 日分の余裕
・・・余談の余談ですがマイナンバーカードの証明書の有効期間は5年でしたよね。2012年レベルのセキュリティ基準という事です。（怖くて不可…
証明書の有効期間が短くなることは後方互換性を気にする必要がなくなる、という付随的なメリットもある、と書かれています。
証明書の失効
証明書は対応する秘密鍵が破られた場合やすでに必要がなくなった場合執行する必要があります。証明書が有効であるように見えてしまうと誤って使われてしまう危険性があるため証明書が最新の状態であることを保証し、最新でなければ証明書利用者に失効を通知できるよう設計されています。証明書の失効の標準として以下の２つがあります。
CRL Certificate Revocation List 証明書失効リスト
まだ期限切れになっていないが失効した証明書のシリアル番号を一覧にしたものです。 CRLの場所は証明書のCRL Distribution Points(CRL配布点拡張)として証明書に格納されている必要があります。CRLの欠点としてはCRLの一覧が肥大化するとリアルタイムの検索が遅くなってしまうことがあります。また、実際問題としてCRLの一覧が頻繁に更新されない点もあげています。
以下の記事により具体的な運用イメージの例が記載されています。
ネットワークエンジニアとして CRL or OSCP
こちらの記事では、CRLファイルをユーザーがダウンロードして定期的にチェックするようなフローの紹介があります。
OCSP Online Certificate Status Protocol
OCSPは特定の証明書の失効状態を証明書利用者が取得できるようする仕組みです。
ネットワークエンジニアとして CRL or OSCPから引用しますと、
OCSPサーバ（OCSPレスポンダ）は、CA自身やCRLを集中管理するVA（Validation Authority）が運営を行っています。VAはデジタル証明書の失効リスト（CRL）を集中管理して証明書の有効性をチェックするシステムのことです。認証局（CA）とは異なりデジタル証明書の発行は行わず検証機能に特化しています。
OCSPサーバーの場所は証明書のAIA拡張にエンコードします。OCSPはリアルタイムの検索が可能なのでCRLの問題のいくつかが解決できますが全てが解決するわけではありません。例としてOCSPサーバーの利用はパフォーマンスとプライバシーの問題に繋がり新たな問題を引き起こします。
OCSPのパフォーマンス問題はOCSPステープリングという仕組みで解決可能です。これはTLSハンドシェイク中のサーバーからの応答にOCSPレスポンスを埋め込むものです。OCSPレスポンスに含まれる署名は検証可能なので証明書の有効性を検証する余計な通信が発生しません。
OCSPについては以下の記事がわかりやすいと思うので引用します。
OCSP Must-Staple と OCSP Multi-Stapling、及び OneCRL
Web サーバーの SSL/TLS 証明書の状態（失効情報）を"ブラウザ"から認証局にオンラインで個別に問合せて取得するのが OCSP （オンライン証明書状態プロトコル）ですが、"OCSP Stapling" では、ブラウザの代わりに、"Webサーバー" が、認証局に問合せて OCSP レスポンス（SSL/TLS 証明書の有効・無効等の状態）を取得・保持しておき、ブラウザが Web サーバーに TLS 接続してきた際に、その接続のやり取り（TLS ハンドシェイク）の中に、OCSP レスポンスの情報も "stapling"（ホチキス止め）して、一緒に渡します。これによりブラウザは、Webサーバーと、認証局の OCSP の 2 か所ではなく、Webサーバー 1 か所にアクセスするだけで、失効情報も含めて、全情報が効率的に取得でき、TLS 接続がスピードアップする、というものです。
こちら引用記事には原書にも説明があるOCSP Must-Staple についてもわかりやすい説明があり引用さえていただきます。
ブラウザが CRL や OCSP レスポンダから失効情報を取得するのに時間を要し、またはタイムアウトした際、ブラウザは、その証明書が、「有効」であるとも「失効されている」とも判別がつかない状態になります。この時、積極的に Web サーバーにアクセスさせないような挙動（表示）を行うか（"hard-fail"）、Web サーバーへのアクセスを許容するか（"soft-fail"）、2 つの挙動を取り得ますが、多くのブラウザは後者（"soft-fail"）を採用している、
という説明の後に
ブラウザが今接続しようとしている Web サーバーとの TLS 接続の中（ハンドシェイクの中）で、失効情報（OCSP レスポンスの情報）が必ずホチキス止め（"Must-Staple"）されて、ブラウザに渡されるので、もし、失効情報が渡されなければ、ブラウザは、その Web サーバーには接続しないように（"hard-fail"）しなさい、とするのが "OCSP Must-Staple" です。
引用元記事にはこれ以外にもわかりやすい説明があり一度通読をお勧めします。