Nginx开启OCSP装订

OCSP简介
全称为 Online Certificate Status Protocol, 是通用的数字证书在线状态查询协议。大多数客户端、浏览器都会在访问HTTPS网站时查询证书的OCSP状态，以进一步确保访问者的安全性。比如 火狐浏览器(FireFox)，就默认校验所有的公开信任证书的OCSP状态。只有通过OCSP校验，FireFox才会正常打开您的网站。

由于 OCSP 校验失败而导致的客户端无法连接情况会有很多，不仅只反应在浏览器端。如果您为移动 APP 的接入使用了双向验证，且每次接入都校验服务器证书的有效性。还比如您为您的 API 服务器接入开启了严格SSL验证模式，即每次对接API时都校验服务器证书的有效性。等等此类环境下，一旦您的客户端网络连接OCSP服务器出现问题，都有可能导致您的服务中断。因为客户端的网络情况是复杂的，多变的，甚至不可预估的。

就最近Let's Encrypt的一个OSCP域名ocsp.int-x3.letsencrypt.org被污染，解析到了以31开头的FaceBook的IP或者其他被墙IP，而不是使用Akamai CDN的Let's Encrypt的OSCP服务器上。导致国内的服务器无法正常申请和续期Let's Encrypt的免费证书，以及访问速度变慢。

解决因网络问题导致的OCSP校验失败
OCSP装订 可以很好的作为OCSP查询协议的替代方案，也是目前 Mozilla基金会推崇实施的一种在线证书查询协议扩展。它能够利用您的服务器网络为客户端、浏览器提供证书状态查询服务。用户如果能够访问您的网站，就能够通过您的网站服务器查询到证书的状态。因此，为了更好的为您的用户提供加密的网站访问和接入服务，您应该为您的每一个安装SSL证书的服务器开启OCSP装订。

Nginx开启OCSP装订
以使用acme.sh申请的Let's Encrypt证书为例，证书会存放在~/.acme.sh/example.com文件夹下，下面有这两个文件：
fullchain.cer
example.com.key

编辑Nginx配置文件，在server大括号中加入以下内容：

1. 
   
2. ssl_certificate /[用户名]/.acme.sh/example.com/fullchain.cer; #证书路径
   
3. ssl_certificate_key /[用户名]/.acme.sh/example.com/example.com.key; #私钥路径
   
4. ssl_stapling on; #开启OCSP
   
5. ssl_stapling_verify on; #开启OCSP验证
   
6. ssl_trusted_certificate /[用户名]/.acme.sh/xmgspace.me/fullchain.cer; #证书链路径
   

复制代码

证书链路径 并不是证书



获取证书链路径
https://myssl.com/chain_download.html

如果使用BT面板  
RSA证书链中的所有字符复制到宝塔SSL证书(PEM格式)中即可
在第15行（不同的nginx配置可能不同）#HTTP_TO_HTTPS_END 下面添加

1. 
   
2. ssl_stapling on;
   
3. ssl_stapling_verify on;
   

复制代码

----------------分割线
理解证书和证书链


最近一直在研究的东东，这东西说到底，也是依赖于一个前提

ROOT 证书，所以说很多安全说最终也是个伪命题；只是搞理论的人喜欢

把东西搞复杂，乱扯概念，不讲本质。



1.  简单来说，end-user证书上面几级证书都是为了保证end-user证书未被篡改，

保证是CA签发的合法证书，进而保证end-user证书中的公钥未被篡改。

2. 除了end-user之外，证书被分为root Certificates和intermediates Certificates。

相应地，CA也分了两种类型：root CAs 和intermediates CAs。

首先，CA的组织结构是一个树结构，一个root CAs下面包含多个intermediates CAs，

而intermediates又可以包含多个intermediates CAs。root CAs 和 intermediates CAs

都可以颁发证书给用户，颁发的证书分别是rootCertificates和intermediates Certificates，

最终用户用来认证公钥的证书则被称为end-user Certificates。



3. 我们使用end-user certificates来确保加密传输数据的公钥(public key)不被篡改，

而又如何确保end-user certificates的合法性呢？这个认证过程跟公钥的认证过程类似，

首先获取颁布end-user certificates的CA的证书，然后验证end-user certificates的signature。

一般来说，root CAs不会直接颁布end-user certificates的，而是授权给多个二级CA，而二级CA

又可以授权给多个三级CA，这些中间的CA就是intermediates CAs，它们才会颁布end-user certificates。





4. 1.拆封证书

    所谓证书的拆封，是验证发行者CA的公钥能否正确解开客户实体证书中的“发行者的数字签名”。

两个证书在交换传递之后，要进行拆封，看是否能够拆封。一个证书或证书链的拆封操作，是为了

从中获得一个公钥。可示为X1p?X1<>,这为一个中缀操作，其左操作数为一个认证机构的公钥，

右操作数则为该认证机构所颁发的一个证书。如果能正确解开，输出结果为用户的公钥。

    从证书内容列表中可以看出，证书结构的最后内容是认证机构CA的数字签名，即一个可信任的CA

已经在证书上用自己的私钥做了签名。如果用该CA的公钥就可以拆封一个用户实体的证书，那么，

这个签名被验证是正确的。因为它证明了这个证书是由权威的、可信任的认证机构所签发。因此，

这个实体证书是真实可信的。

5..证书链的验证

    所谓证书链的验证，是想通过证书链追溯到可信赖的CA的根（ROOT）。换句话说，要验证签发用户

实体证书的CA是否是权威可信的CA，如CFCA。证书链验证的要求是，路径中每个证书从最终实体到根证书

都是有效的，并且每个证书都要正确地对应发行该证书的权威可信任性CA。操作表达式为 Ap?A<>B<>,

指出该操作使用A的公钥，从B的证书中获得B的公钥Bp，然后再通过 Bp来解封C的证书。操作的最终结果

得到了C的公钥Cp。这就是一个证书链的认证拆封过程。

    (1)证书链的定义。证书链也称认证链，它是最终实体到根证书的一系列证书组成，这个证书链的处

理过程是所有根的前辈指向最开始的根证书，即子辈连向父辈。如图1所示。

  (2) 从用户实体证书到ROOT CA的证书链确认，其具体的做法如下页图2所示。
    从以上对比中可以看出：用户实体证书中的AuthorityKey Identifier扩展项CertIssuer，即证书签发者的

甄别名，应当与CA证书中签发此证书的CA名称相匹配，如图中箭头所指。即CA证书中的Subject Name

是用户实体证书中Issuer Name的父名，对上级CA来说又成为子名，CA证书中Issuer Name是上一级CA的

名字，成为可信任的链状结构。这样通过各级实体证书的验证，逐渐上溯到链的终止点——可信任的根CA，

如CFCA。
————————————————
版权声明：本文为CSDN博主「junwua」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/junwua/article/details/80506399