证书链如何呈现给客户？ [英] How is a certificate chain presented to the client?

问题描述

如何向客户展示证书链？

How is a certificate chain presented to the client?

我已经了解了该根存储仅存储自签名证书（根证书）。

I've come to the understanding that root stores only store self-signed certificates ("root" certificates).

让 A > B > ...> R 是证书，其中 A > B 表示 B 签名 A 的证书。而 R 是根证书。

Let A>B>...>R be certificates, where A>B means that B signs A's certificate resp. and R is a "root" certificate.

带有证书的服务器如何工作A ，向其根存储中具有 R 的客户出示证书？

How does a server, with certificate A, present its certificate to a client having R in its root store?

服务器是否发送整个链， A > B > ...（不是 R ）发送给客户端？还是只发送证书 A ，这样验证就失败了，如果没有，客户端存储了 B > ...

Does the server send the whole chain, A>B>...(not R) to the client? Or does it only send certificate A, such that validation fails, if not the client has B>... stored "somewhere" and R in its root store?

推荐答案

在其根存储区中是某处和 R ？让我们看一下未来的标准， TLS 1.3

To explain things let us look at the future standard, TLS 1.3 as things will be similar in current lower versions.

第4.4.2节处理证书交换。它以结尾。服务器的certificate_list必须始终为非空。但是上面的文本说明了这种结构：

Section 4.4.2 deals with certificates exchange. It ends with The server's certificate_list MUST always be non-empty. But the text above explains about this structure:

certificate_list

certificate_list

这是CertificateEntry
结构的序列（链），每个结构都包含一个证书和一组
扩展名。

This is a sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.

及以后：

发件人的证书必须输入列表中的第一个
CertificateEntry。随后的每个证书应
直接证明紧接其之前的证书。因为
证书验证要求信任锚独立地分配
，所以指定信任锚的证书可以从链中省略
，前提是已知
所支持的对等方拥有任何

The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify the one immediately preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.

这直接回答了您的问题：在这种情况下，服务器应该发送 A ， B 等，但是可以省略 R （根最终证书）（我认为这很常见。）

That directly answers your question: in this case, the server is supposed to send A, B, etc... but can omit R, the root final ceertificate (which I think is frequent).

关于结构中证书的顺序，文档告诉我们：

As for order of certificates in the structure, the document tells us that:

注意：在TLS 1.3之前， certificate_list命令要求每张
证书来证明紧接其后的证书；但是，
的某些实现允许一定的灵活性。有时
会同时出于过渡
的目的发送当前和已弃用的中间件，而其他服务器只是配置不正确，但仍然可以正确验证这些
的情况。为了获得最大的
兼容性，所有实现都应准备处理
潜在的无关证书以及来自任何
TLS版本的任意顺序，但最终实体证书必须为
首先。

Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.

对于客户端来说，如果需要发送其证书，则相同：它将需要发送所有中间证书（如果有的话）发送到服务器，该服务器通常仅配置了（顶部）CA列表。

It is the same for the client, if it needs to send its certificate: it will need to send all the intermediary certificates, if any, to the server, which is normally configured with just a list of (top) CA.

这篇关于证书链如何呈现给客户？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！