[38] ただの列ではなく、前の証明書を証明する発行者の証明書を次に置く、 という形で証明経路を記述したものとなっています。
[43] 証明書鎖は証明書を順に並べたものに過ぎませんが、 どのように並びを記述するか、いくつかの形式があります。
[40]
TLS
でサーバー証明書やクライアント証明書を送信する
Certificate
メッセージでは、
証明書の列を DER
符号化したものが使われます。
application/pkix-pkipath[7] RFC 5280 証明書の列を DER で符号化したものが、
MIME型 application/pkix-pkipath
です >>6。これは certification path を表します >>6。
[8] 証明書の順序は意味を持ちます。最初の証明書の subject が2番目の証明書の発行者、などとなるように並べます >>6。
[9] relying party は RFC 5280 に厳密に適合しない証明書を必ずしも拒絶しなくても構いませんが、 セキュリティーへの影響は慎重に検討する必要があります >>6。
[39]
OpenSSL
は1個以上の証明書が含まれる.pemファイルに対応しています。
OpenSSL
を使った多くの応用がこの形式をそのまま採用しています。
[41]
この形式は、
1個の証明書を表す .pem ファイルを
(適当な改行を挟んで)
任意の個数、繰り返し記述したものです。
[42]
TLS Certificate 用にこれを指定した場合は、
PEMファイルに含まれる証明書がそのまま順に送信されます。
application/pem-certificate-chain[19]
.pemファイル形式の証明書鎖の記述形式の一種として、
application/pem-certificate-chain
があります >>17, >>18。
x5u 参照先[22] JWS のヘッダー引数や
JWK の鍵引数である
x5uで指定された証明書鎖の資源は、
RFC 5280 X.509 証明書または証明書鎖を
RFC 4945 .pem 形式で符号化した表現を提供するものでなければなりません。
>>21, >>31
[23] JWS では、 RFC 4949 デジタル署名に用いた鍵に対応する公開鍵を含む証明書は、 最初の証明書でなければなりません。 >>21
[24] 前の証明書を次の証明書が証明する、 という形で追加の証明書があっても構いません。 >>21
[32] JWK では、 含まれる最初の証明書は、 JWK の他の鍵引数で記述された公開鍵に一致しなければなりません。 >>31
[33] JWSの取得プロトコルも参照。
[16] report-uri で指定された URL に送信される JSON
では、証明書鎖を証明書の .pem 形式の文字列を
JSON 配列として記述します。
x5c の JSON 配列[27]
x5cのJSON配列は、 JSON配列です。
>>26, >>31
[28] JSON配列の各値は、 RFC 5280 PKIX X.509 証明書を DER 符号化し、 RFC 4648 Base64 符号化した文字列です。 >>26, >>31
[29] JWS では、 RFC 4949 デジタル署名するのに使った鍵に対応する公開鍵を含む証明書は、 最初の証明書でなければなりません。 >>26
[35] JWK では、鍵値を含む証明書は、 最初の証明書でなければなりません。 >>31
[30] 前の証明書を次の証明書が証明する、 という形で追加の証明書があっても構いません。 >>26, >>31
[34] JWK では、 含まれる最初の証明書は、 JWK の他の鍵引数で記述された公開鍵に一致しなければなりません。 >>31
[46] TLS はじめ多くのプロトコルは証明書鎖にルート証明書を含めても、 含めなくても良いとしています。 必要なルート証明書は、手元の証明書データベースにあるものを参照します。
[48] TLS はじめ多くのプロトコルは必要な中間証明書をすべて証明書鎖に含めて相手方に送信することを求めています。
[49] しかしそれ以外の手段で中間証明書を取り揃えて証明経路を用意する仕組みを構築することは可能です。
[50] 実際にそのための要素の1つとして、 証明書に AIA を使って中間証明書の入手方法を記述することができます。
[52] また、実装によっては中間証明書の検証結果をキャッシュしているために、 プロトコル上必須とされる中間証明書が証明書鎖に含まれなかった場合でも、 キャッシュを根拠に検証を成功させてしまう場合があります。 このような挙動は接続の可否に再現困難な不確定性をもたらしてしまい、 問題の発覚と修正を難しくするので、避けなければなりません。
[1] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280#section-3.2
Certificate users MUST be prepared to process the issuer
distinguished name and subject distinguished name (Section 4.1.2.6)
fields to perform name chaining for certification path validation
(Section 6). Name chaining is performed by matching the issuer
distinguished name in one certificate with the subject name in a CA
certificate.
Issuer alternative names are not
processed as part of the certification path validation algorithm in
Section 6. (That is, issuer alternative names are not used in name
chaining and name constraints are not enforced.)
[4] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280#section-6
[5] RFC 6818 - Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) https://tools.ietf.org/html/rfc6818#section-4
[14] 634074 – Cannot validate valid certificate chain when looping/cross-signed certs are involved ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=634074
[15] RFC 7515 - JSON Web Signature (JWS) () https://tools.ietf.org/html/rfc7515#section-4.1.6