公開鍵基盤における信頼の確立：PKIの証明書信頼モデル

証明書チェーン、ルートCAと中間CA、そして安全な証明書検証によって、PKIにおける信頼を確立します。

信頼の確立

クライアントは、証明書の信頼チェーンを用いる一連の処理を通じて、特定のルート認証局（CA）への信頼を示します。その仕組みは次のとおりです。

プリインストールされたルート証明書：ほとんどのオペレーティングシステムとWebブラウザーには、信頼された認証局のルート証明書があらかじめ組み込まれています。これらのルート証明書は、信頼されたルートストアに格納されます。
証明書の検証：クライアントがサーバーに接続すると（Webサイトを閲覧する場合など）、サーバーは自身のTLS証明書を提示します。この証明書は通常、中間CAによって署名されており、その中間CAはさらにルートCAによって署名されています。
信頼チェーンの検証：クライアントは、提示された証明書が信頼されたルートCAによって署名されているかを確認し、信頼チェーンを検証します。あわせて、チェーン内の中間CAが信頼されているかも確認します。
デジタル署名：チェーン内の各証明書は、その上位にある認証局によってデジタル署名されています。クライアントは認証局の公開鍵を使ってこれらの署名を検証し、証明書が改ざんされていないことを確かめます。
信頼の判断：信頼チェーン全体が有効で、信頼されたルートCAまでさかのぼれる場合、クライアントはサーバーの証明書を信頼します。これにより安全な通信が開始できます。

インフラストラクチャー向けのPKIでは、単一のルートのほうが有利な場合もあります。

中間認証局（CA）は、ルートCAによるクロス署名と呼ばれる手順を通じて自身の証明書を取得します。その仕組みは次のとおりです。

証明書署名要求（CSR）：中間CAを構築したい組織がCSRを生成します。このCSRには、中間CAの公開鍵と識別情報が含まれます。
ルートCAへの提出：CSRを信頼されたルートCAに提出します。
検証：ルートCAは、中間証明書を要求している組織の身元と正当性を検証します。
署名：検証が完了すると、ルートCAは自身の秘密鍵でCSRに署名し、中間証明書を作成します。この署名済み証明書によって中間CAがルートCAに結び付けられ、信頼チェーンが確立されます。
発行：ルートCAは署名した中間証明書を要求元の組織に発行し、組織はそれを使ってエンドエンティティ証明書（WebサイトのTLS証明書など）に署名できるようになります。

この手順により、中間CAは、すでにブラウザーとオペレーティングシステムから信頼されているルートCAとのつながりによって信頼されることになります。

証明書チェーンは信頼チェーンとも呼ばれ、デジタル証明書の真正性と信頼性を保証する証明書の連なりです。その仕組みは次のとおりです。

検証の流れ：クライアント（Webブラウザーなど）がサーバーに接続すると、サーバーは自身のエンドエンティティ証明書を提示します。続いてクライアントは証明書チェーンを確認し、各証明書がチェーン内の次の証明書によってルート証明書まで順に署名されていることを検証します。
信頼チェーン：チェーン内の各証明書は、その上位にある証明書の公開鍵を使って検証されます。この処理は、クライアントがすでに信頼しているルート証明書に到達するまで続きます。
信頼の確立：チェーン全体が有効で、信頼されたルート証明書までさかのぼれる場合、クライアントはエンドエンティティ証明書を信頼し、安全な通信が開始できます。

この仕組みによって、エンドエンティティ証明書が正当であり、信頼できる機関から発行されたことが保証され、デジタル通信の完全性とセキュリティが維持されます。

デジタル証明書のBasic Constraints拡張は、公開鍵基盤（PKI）における証明書の種類とその役割を区別するという課題に対処します。その仕組みは次のとおりです。

認証局（CA）の識別：その証明書がCA証明書かエンドエンティティ証明書かを示します。CA証明書は他の証明書を発行できるのに対し、エンドエンティティ証明書は発行できないため、この区別は極めて重要です。
パス長の制約：証明書チェーンにおいて、このCAの下位に存在できる中間CAの数を制限できます。これにより、非効率でセキュリティ上の懸念もある過度に長い証明書チェーンを防げます。

解決される問題：

不正な証明書発行の防止：どの証明書が認証局として振る舞えるかを明示することで、エンドエンティティ証明書が他の証明書を発行するのを防ぎ、PKIの完全性を保ちます。
証明書チェーン長の管理：パス長を制限することで証明書チェーンを扱いやすく安全な範囲に保ち、長いチェーンに伴う潜在的な脆弱性を防ぎます。

デジタル証明書のBasic Constraints拡張は、CA証明書とエンドエンティティ証明書を区別し、証明書チェーンの長さを管理するという課題を、次の仕組みで解決します。

CAフラグ：このフラグは、その証明書が認証局（CA）の証明書かエンドエンティティ証明書かを示します。フラグがTRUEに設定されている場合、その証明書は他の証明書の署名に使用でき、CA証明書であることを表します。FALSEの場合はエンドエンティティ証明書であり、他の証明書を発行できません。
パス長の制約：有効な証明書パスにおいて、この証明書の後に続けられる自己発行以外の中間証明書の最大数を指定します。この制約を設定することで、拡張は証明書チェーンの長さを制限し、扱いやすく安全な状態に保ちます。

これらの仕組みの働き：

CAフラグ：証明書の発行時に、想定される用途に応じてCAフラグが設定されます。証明書の検証処理において、クライアントはこのフラグを確認し、その証明書が他の証明書を発行するものとして信頼できるかを判断します。
パス長の制約：検証処理の中でこの値が確認され、証明書チェーンが指定された長さを超えていないことが検査されます。チェーンが長すぎる場合、その証明書は無効と見なされます。

これらの仕組みによって、他の証明書を発行できるのは権限を与えられた証明書だけとなり、過度に長い証明書チェーンも防がれるため、公開鍵基盤（PKI）の完全性とセキュリティが維持されます。