SSL信息OCSP 装订是OCSP（在线证书状态协议）检查证书的撤销状态的一种可选方案。它使证书颁发者承担为首次TLS握手提供附带（称为“装订”）时间戳的OCSP响应（由证书颁发机构签名）带来的资源消耗，这样客户就不需要联系证书颁发机构。证书持有者只需每隔固定时间向OCSP应答系统进行查询，然后将反馈情况缓存即可。
传统OCSP要求证书颁发机构为每个查询证书撤销状态信息的客户提供响应。当证书由热门网站签发时，大量的查询请求就会涌向该网站的OCSP响应服务器。这引起了私密性方面的风险，因为信息必须通过第三方传输，而该第三方由此能够决定谁在什么时候访问哪个站点。这同样也会造成性能问题，因为大部分浏览器在加载网页的任何内容之前都会先联系OCSP应答系统。OCSP 装订是高效的，因为用户不必单独建立一个与证书颁发机构之间的连接。而这也很安全，因为OCSP响应具有数字签名，只要对其进行更改就会被检测到。
OCSP 装订@Squarespace
当我们计划在Squarespace平台上为所有客户的域全面推行SSL时，我们决定在一开始就支持OCSP 装订。一个由我们的Edge Infrastructure团队建立的反向代理服务器负责终止所有SSL通信，这个反向代理服务器是由Java语言编写，基于Netty技术。但不幸的是，Java JDK 8只有初步的仅对客户端有效的OCSP 装订支持。JDK 9通过JEP 249引入了OCSP 装订，但JDK 9 尚无法使用。
我们的反向代理服务器不使用JDK的SSL工具。我们通过netty-tcnative使用OpenSSL。当前，无论是原版tcnative还是Netty的fork都不支持OCSP 装订。但是，tcnative库揭示了OpenSSL的内部工作原理，包括SSL环境和引擎的地址指针。我们可以用JNI来扩展netty-tcnative库，并使用tlsext_status OpenSSL C函数来添加OCSP 装订支持。我们的扩展是一个独立库，但我们同样可以将其纳入netty-tcnative库。如果需要，我们可以将其纳入Netty的下一个API-breaking开发周期。
我们最初部署OCSP 装订的目标之一，是最大程度上减轻OCSP响应系统的工作量，在这个案例中是Let’s Encrypt。由于我们平台上网站通信的性质，我们的队列很长。至少在最开始，我们不能预先读取并缓存所有OCSP响应。我们会异步读取OCSP响应，而且只有当超过一个客户端可能会请求OCSP响应的时候我们才会这么做。我们用过滤器来判定“昙花一现”的请求，这样的请求我们没必要缓存。
Squarespace在对客户网站及其访问者的安全方面投入很多。我们将持续改进我们的OCSP 装订应用，最终将其应用到所有OCSP请求。
本文由Squarespace团队撰写并客座发布于Let's encrypt博客。有关传统OCSP的讨论与分析，请戳此链接。