Ocsp

把核验交给服务器能省掉一整段往返与一次独立请求;就算没有 Staple,客户端也仍可兜底去查。 服务器只取一次 OCSP stapling 是让「验证」这件事不拖慢握手：客户端本要通过一次额外往返，去 CA 的那台应答服务器（OCSP）查询「这张证书有没有被吊销」。开启 stapling 后，这个查询改成由服务端自己做，然后把查询结果（CA 签过名的那条）放进 TLS 握手一起发过去。浏览器就不用再单独发一次查询了，握手因此更快，也少了一层对 OCSP 提供方是否在线的依赖。 客户端免去一次查询 Staple 的机制是把「每次握手由客户端查」改成「每隔一段时间由服务端查」：服务端以缓存一份带 CA 签名的 OCSP 响应，在窗口内对所有客户端重复“贴”出同一条。每次握手几乎零成本。但 OCSP 响应本身会过期，一般以分钟或天为单位计量；太久、或被 CA 拒签、或验证不过的 staple，会让服务端退回旧路径——干脆不贴。打开的开关在 nginx 里很直白：在 nginx 里把 ssl_stapling 打开，并配置 ssl_stapling_verify 与完整证书链（中间证书）即可。 是 Staple,不是绝对保证 要摆正一个重要认识：stapling 是针对 OCSP 的优化，不是安全边界。它并没有把「吊销检查」做得比不发全程更硬，反而只是把检查挪到了服务器上并缓存。staleness 不影响握手成败——一条过期 staple 更可能让检查退回请求 CA，而不是让 TLS 失败。所以，信任应该建立在 CA 签名与整条证书链之上，而不是 stapling 本身。它真正可度量的收益是省下那一次往返，也消除了 OCSP 提供商宕机时客户端被拖慢的那一层影响。能开就开，几乎没有任何理由不开。 ...