分析 ServerCertificateChain#

先提供结论：kestrel 目前只能读取到 Endpoint 下配置的 pem 格式证书文件的证书链，其它三种情况都有BUG。

遇到问题不要慌，先 AI 分析一波，AI 告诉要设置 ServerCertificateChain

Copy

builder.WebHost.ConfigureKestrel(kestrel => { kestrel.ConfigureHttpsDefaults(https => { https.ServerCertificateChain = 自己实现从证书文件读取; }); });

我有点想怼 AI，kestrel 不可能不读取证书文件的证书链，于是我加了行 ServerCertificateChain 不为 null 的断言，同时在配置文件的默认证书了放了 ssl 证书：

Copy

builder.WebHost.ConfigureKestrel(kestrel => { kestrel.ConfigureHttpsDefaults(https => { https.OnAuthenticate = (context, options) => { Debug.Assert(https.ServerCertificateChain is not null); }; }); });

Copy

{ "Kestrel": { "Endpoints": { "Https": { "Url": "https://*:443" }, "Certificates": { "Default": { "Path": "certs/test_bundle.crt", "KeyPath": "certs/test.key" } } } }

结果还真炸起来了，Debug.Assert 断言不通过！
这泥马 https.ServerCertificateChain 为 null，证书链短一节我一点都不觉得荒唐了，但为什么为 null 呢，我翻了 ASP.NET core 的 issues，找到25年3月报告的一个问题：Kestrel inconsistent certificate chain handling between endpoint and default configuration，描述的是证书放到 Default 节点后，表现为和放到 Endpoint(Https) 节点不一样，我们现在把配置文件改成如下：

Copy

{ "Kestrel": { "Endpoints": { "Https": { "Url": "https://*:443", "Certificate": { "Path": "certs/test_bundle.crt", "KeyPath": "certs/test.key" } } } } }

现在能读取到 ServerCertificateChain，看来AI说得没错，https.ServerCertificateChain = 自己实现从证书文件读取，可以弥补 Default 证书不读取证书链的问题，假设我们手动设置了 ServerCertificateChain，证书也是配置在Endpoint下，最终保留的来源于哪里的证书链呢？做了以下实验后，发现是证书文件的证书链优先。

Copy

builder.WebHost.ConfigureKestrel(kestrel => { kestrel.ConfigureHttpsDefaults(https => { // 手动设置 ServerCertificateChain https.ServerCertificateChain = []; https.OnAuthenticate = (context, options) => { // 断言成立，如果能读取到证书文件的证书链，手动设置的 ServerCertificateChain 会被覆盖 Debug.Assert(https.ServerCertificateChain is not null && https.ServerCertificateChain.Count > 0); }; }); });

我把证书格式改成带证书链的 pfx，配置在 Endpoint 节下，发现 kestrel 读取到的证书链不为 null ，但总是 0 个元素，翻看最新的源码，看到 kestrel 目前只简单粗暴的通过X509Certificate2Collection.ImportFromPemFile())来读取证书链，对于 pfx 格式，这肯定 import 不到内容哈。

使用 ServerCertificateChain#

经过上述深入的分析，只要我们使用 PEM 格式的证书文件，并且配置在 Endpoint 节下，那么 kestrel 就能使用上证书文件里提供的中间证书，最后生成和 nginx 一样的证书链。

我迫不及待地搭建了一个测试服务器，用上和 nginx 一样的 PEM 证书，满怀信心地使用 openssl 客户端来验证，可我发现还是验证不通过!

我确定 kestrel 已经从 PEM 证书文件里原封地读取到了证书链且设置了 https.ServerCertificateChain，但在 tls 握手时，服务器响应的证书链变短了。

翻看了 HttpsConnectionMiddleware 源码，发现 serverCertificateContext 的构建方式是依赖于系统证书 store，https.ServerCertificateChain 只不过是其构建过程中可能用到的辅料罢了，或者说几乎所有服务器操作系统环境，https.ServerCertificateChain 有值或为 null ，生成的 serverCertificateContext 一般都不会有差异。

我们通过自定义生成 ServerCertificateContext 并应用到 kestrel，最终发现生成的证书链和 nginx 的完全一样，在客户端设备上进行 https 连接成功。

Copy

builder.WebHost.ConfigureKestrel(kestrel => { kestrel.ConfigureHttpsDefaults(https => { https.OnAuthenticate = (context, options) => { var chain = https.ServerCertificateChain; Debug.Assert(chain is not null && chain.Count > 0); // ServerCertificateContext 要缓存，不能每次 OnAuthenticate 都创建新的 ServerCertificateContext，否则性能会非常差。 var serverCertificate = options.ServerCertificate as X509Certificate2; var trust = SslCertificateTrust.CreateForX509Collection(chain); options.ServerCertificateContext = SslStreamCertificateContext.Create(serverCertificate!, chain, false, trust); }; }); });