証明書チェーンの作成と管理

ルートCAは自己署名証明書であり、最終的な信頼の起点として機能します。ルートCAの秘密鍵は、侵害されるとPKI全体が危険にさらされるため、オフライン（エアギャップ環境のシステムまたはHSM上）で保管する必要があります。「openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem」は、10年間有効な自己署名ルート証明書を生成します。

中間CAはルートCAによって署名され、日常的な証明書の発行に使用されます。まず、中間CAの鍵とCSRを生成します。「openssl req -new -key intermediate_key.pem -out intermediate.csr」を実行します。次に、ルートCAで署名します。「openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem」を実行します。

エンドエンティティ証明書（リーフ証明書）は、特定のサーバーまたはクライアント用に中間CAが署名します。Subject Alternative Names（SAN）を付けてサーバーの鍵とCSRを生成し、その後、中間CAで署名します。「openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem」を実行します。

ルートCAの秘密鍵はオフラインで保管し、少数の中間CA証明書への署名にだけ使用します。日常的な証明書の発行は、オンラインの中間CAが行います。中間CAが侵害された場合でも、ルートCAを侵害することなく、その中間CAを失効させて置き換えられます。ルート鍵がオンラインに公開されることはないため、安全な状態が保たれます。

「openssl ca」コマンドは、「openssl x509 -req」よりも完全なCAワークフローを提供します。証明書データベース（index.txt）を管理し、シリアルファイルからシリアル番号を割り当て、CRLの生成を処理します。証明書ポリシーとパス長制約を定義する、CA固有のセクションを含む適切なopenssl.cnf設定ファイルが必要です。

Webサーバー用の完全な証明書チェーンファイルには、エンドエンティティ証明書に続けて、中間CA証明書を順番に並べて含めます。ルート証明書の直前で終わり、ルート証明書自体は含めません。ブラウザにはルート証明書ストアがあらかじめ組み込まれているためです。連結する順序は「cat server_cert.pem intermediate_cert.pem > chain.pem」です。順序を間違えると、TLSハンドシェイクに失敗します。

「openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem」は、チェーン全体を検証します。「-untrusted」フラグには、チェーンの一部ではあるものの、まだ信頼されていない中間証明書を指定します。検証に成功すると、出力は「server_cert.pem: OK」になります。よくあるエラーは、中間証明書の不足や証明書の期限切れを示します。

証明書チェーンで頻繁に発生する問題には、次のようなものがあります。中間証明書がない（サーバーがリーフ証明書だけを送信している）、連結する順序が間違っている（リーフを先頭にする必要がある）、中間証明書の期限が切れている（リーフ証明書の期限だけを監視していると見落としやすい）、自己署名証明書がトラストストアにない、名前が一致しない（証明書のSANがホスト名と一致しない）といった問題です。すべて「openssl s_client -showcerts」で診断できます。

PKCS#12（.pfxまたは.p12）は、秘密鍵、エンドエンティティ証明書、中間証明書を1つの暗号化ファイルにまとめるコンテナ形式です。作成には「openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem」を使用します。IIS、.NET、Javaキーストア、多くのエンタープライズアプリケーションで必要になります。

PEMはBase64エンコードされたASCII形式で、人間が読みやすく、1つのファイルに複数のオブジェクトを格納できます。Apache、nginx、OpenSSLツールで使用されます。DERはバイナリ形式で、1ファイルにつき1つのオブジェクトを格納し、Java（JKSへのインポート）、Android、一部のエンタープライズツールで使用されます。PKCS#12/PFXは、複数のオブジェクトを格納する暗号化バイナリコンテナで、WindowsやIISで使用されます。デプロイする前に、対象システムが想定する形式を確認してください。

現在のCAには、発行したすべての証明書をCertificate Transparency（CT）ログに記録してから配布することが求められています。内部利用のためにプライベートCAを作成する場合、CTへの記録は必要ありません。ただし、一般公開する証明書には、Chromeで信頼されるためにSigned Certificate Timestamp（SCT）が埋め込まれていなければなりません。プライベートCAは、CTの要件なしに独自のポリシーを使用できます。

nginxサーバー用のTLS証明書チェーンファイルを構成するとき、正しい連結順序はどれですか？

ルートCAは自己署名され、オフラインで保管され、中間CAに対してのみ署名します。中間CAが日常的な証明書発行を処理します。チェーンファイルにはリーフ証明書、続いて中間証明書を含め、ルート証明書は省略します。「openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem」で検証します。PKCS#12バンドルは、WindowsやJava向けに鍵と証明書をまとめます。チェーンの順序を間違えることは、よくあるデプロイ失敗の原因であり、s_client -showcertsで診断できます。