Linux下Kestrel配置Cloudflare源站认证IP直连未拦截排查

所有配置失效的核心原因可拆解为5个明确的配置错误，与Cloudflare本身的规则设置无关：

• 端点未绑定强制认证要求：当前配置添加了认证中间件，但没有对API端点设置必须通过认证的规则，未携带有效客户端证书的请求也能直接进入控制器逻辑返回响应，完全绕过证书校验。
• 自定义校验服务未注册依赖注入：MyCertificateValidationService从未在DI容器中注册，后续触发校验逻辑时会直接返回空引用，就算走到验证分支也无法正常执行指纹比对。
• 中间件顺序错误、引入了无用组件：多余的UseCertificateForwarding()是为前置反向代理设计的，用于将代理传递的客户端证书转为请求头格式，当前直连Kestrel的架构下该组件完全无意义，且打乱了正常的中间件执行顺序。
• 认证逻辑未打通TLS层的客户端证书：默认的AddCertificate逻辑优先从请求头读取客户端证书，而直连架构下客户端证书是在TLS握手阶段存储在连接上下文中的，未做配置的情况下认证中间件根本拿不到Kestrel收到的真实客户端证书，校验逻辑永远不会触发。
• 证书加载逻辑存在性能隐患：自定义校验服务每次验证都会从磁盘重新加载Cloudflare证书文件，高并发下会引发IO阻塞，且pfx格式的校验文件是Cloudflare源站拉取验证不需要的（Cloudflare仅提供公钥格式的PEM证书，不需要私钥即可完成指纹比对）。

所有调整不需要引入任何反向代理组件，完全基于Kestrel原生能力实现：

1. 注册自定义校验服务：在Startup.ConfigureServices方法中添加DI注册，保证校验服务可被正常解析，使用单例模式避免重复加载证书造成的磁盘IO开销

   services.AddSingleton<MyCertificateValidationService>();
   

2. 修正证书认证配置：让认证中间件直接读取TLS连接上的客户端证书，跳过默认的请求头读取逻辑，同时调整信任校验规则以适配硬匹配需求

   services.AddAuthentication(CertificateAuthenticationDefaults.AuthenticationScheme)
       .AddCertificate(options =>
       {
           // 跳过默认的证书链信任校验，仅做Cloudflare指定证书的指纹硬匹配
           options.RevocationMode = X509RevocationMode.NoCheck;
           options.ChainTrustValidationMode = X509ChainTrustMode.None;
           options.Events = new CertificateAuthenticationEvents
           {
               // 核心逻辑：从TLS连接上下文读取Kestrel在握手阶段拿到的真实客户端证书
               OnMessageReceived = context =>
               {
                   context.ClientCertificate = context.HttpContext.Connection.ClientCertificate;
                   return Task.CompletedTask;
               },
               OnCertificateValidated = context =>
               {
                   var validationService = context.HttpContext.RequestServices.GetService<MyCertificateValidationService>();
                   if (validationService.ValidateCertificate(context.ClientCertificate))
                   {
                       context.Success();
                   }
                   else
                   {
                       context.Fail("invalid cert");
                   }
                   return Task.CompletedTask;
               },
               OnAuthenticationFailed = context =>
               {
                   context.Fail("invalid cert");
                   return Task.CompletedTask;
               }
           };
       });
   

3. 修正中间件管道：删除无用的证书转发组件，调整执行顺序，全局强制要求所有API端点必须通过认证

   public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
   {
       if (env.IsDevelopment())
       {
           app.UseDeveloperExceptionPage();
       }
   
       app.UseHttpsRedirection();
       app.UseRouting();
       // 移除多余的app.UseCertificateForwarding();
       app.UseAuthentication();
       app.UseAuthorization();
   
       // 核心：全局强制所有控制器端点必须通过认证，未带有效证书的请求直接返回401
       app.UseEndpoints(endpoints => 
       { 
           endpoints.MapControllers().RequireAuthorization();
       });
   }
   

4. 优化证书校验服务：移除重复磁盘读取逻辑，单例初始化时加载一次Cloudflare的公钥证书即可

   using System.Security.Cryptography.X509Certificates;
   
   public class MyCertificateValidationService
   {
       private readonly X509Certificate2 _cloudflareExpectedCert;
   
       // 单例初始化时加载一次证书，避免每次请求读磁盘
       public MyCertificateValidationService()
       {
           _cloudflareExpectedCert = new X509Certificate2("/home/ubuntu/cloudflare_cert.pem");
       }
   
       public bool ValidateCertificate(X509Certificate2 clientCertificate)
       {
           if (clientCertificate == null) return false;
           // 指纹匹配校验
           return clientCertificate.Thumbprint == _cloudflareExpectedCert.Thumbprint;
       }
   }
   

5. 基础权限校验：确保Kestrel进程运行的用户有读取对应路径下证书文件的权限，避免证书加载失败引发的逻辑异常。

完成配置后：

• 来自Cloudflare回源的请求会携带Cloudflare的指定客户端证书，通过指纹校验后正常访问
• 所有IP直连的请求，要么在TLS握手阶段因为不提供证书直接被Kestrel拒绝，要么因为提供的证书不匹配Cloudflare的指纹、未通过全局认证检查返回401，完全无法访问API逻辑。

内容的提问来源于stack exchange，提问作者pb36