OCSP原理及实践

1.OCSP介绍

  在PKI体系中,CA机构颁发合法的证书。使用者可以使用CA根证书验证该证书是否被篡改过,但无法从证书文件验证出证书是否被吊销。因此CA机构会通过发布CRL(Certificate Revocation List)来告知所有人,哪些证书已经被吊销。使用者为验证证书的合法性,需要通过验证证书签名来确保证书未被篡改,以及通过CRL查询确保证书未被吊销,此两步都完成后,方可说明证书合法性验证通过。
  因CRL巨大且具有时效性,因此设计出OCSP(Online Certificate Status Protocol)机制,可以实时查询证书状态。OCSP比CRL更具有时效性,并且可提供额外的状态信息。本文主要基于RFC6960RFC5912进行解读。

2.OCSP原理

 2.1 OCSP 请求

  OCSP请求的ASN.1格式如下:
在这里插入图片描述

  1. tbsRequest:基础请求信息
  • version:协议版本,默认为v1,值为0。具有DEFAULT标记,编码时可省略。
  • requestorName:请求者名称,可选项
  • requestList: 需要检查的证书清单,可包含一个或多个证书信息
    • reqCert:需检查的证书信息
      • hashAlgorithm:生成issuerNameHash和issuerKeyHash值的HASH算法
      • issuerNameHash:证书颁发者的可分辨名称(DN)的HASH值。HASH值应以DER编码值计算(包含完整的TLV)
      • issuerKeyHash:颁发者公钥的HASH值
      • serialNumber:证书的序列号
    • singleRequestExtensions:该证书的请求扩展项,可选项,详见RFC6960 4.4章节。
  • requestExtensions:扩展信息。为防止重放攻击,可选择添加1个nonce。

2.optionalSignature: 请求签名,可选项

  • signatureAlgorithm: 算法标识符
  • signature:签名,对整个tbsRequest进行计算签名
  • certs:验证signature的证书,以便OCSP服务器验证signature合法性

  当进行OCSP请求时,主要在requestList->reqCert中填充所需认证的证书信息。若一次需检查多个证书,则存在多个reqCert。optionalSignature和requestExtensions等为可选项,通常不使用。

 2.2 OCSP响应

  OCSP响应的ASN.1格式如下:
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

  1. responseStatus:响应状态,为如下值之一
  • successful: 值为0,正常响应
  • malformedRequest:值为1,非法请求
  • internalError:值为2,颁发者内部错误
  • tryLater:值为3,稍后重试
  • sigRequired:值为5,请求必须进行签名
  • unauthorized:值为6,请求未经过授权
  1. responseBytes:响应内容,只有responseStatus为successful时才存在。
  • responseType:对于基础的OCSP响应,此值为id-pkix-ocsp-basic
  • response:DER编码的BasicOCSPResponse
    • tbsResponseData:响应数据
      • version:默认值v1,可省略
      • responderID:可填充名称或HASH,若选择HASH,HASH值为OCSP响应者证书的SHA-1值(包含tag和length字段)
      • producedAt:OCSP响应程序签署此响应的时间
      • responses:校验结果内容。包含N个SingleResponse的数组。OCSP请求中有N个证书,此处就是N个SingleResponse组成的数组,每个SingleResponse的结构如下
        • certID:和OCSP请求中的reqCert一致。
          • hashAlgorithm:生成issuerNameHash和issuerKeyHash值的HASH算法
          • issuerNameHash:证书颁发者的可分辨名称(DN)的HASH值。HASH值应以DER编码值计算
          • issuerKeyHash:颁发者公钥的HASH值
          • serialNumber:证书的序列号
        • certStatus:CHOICE类型,表明当前证书的检查结果,结果为三选一。
          • good: NULL,表明OCSP通过
          • revoked:表明证书被吊销,会包含吊销时间revocationTime、吊销理由revocationReason(可选)
          • unkown:状态未知
        • thisUpdate:响应者最近查询状态的时间。此时间不应晚于当前系统时间。
        • nextUpdate :建议下次查询时间。此时间不应早于当前系统时间。
        • singleExtensions:单个证书附加字段,可选项
      • responseExtensions:响应附加字段,可选项。当OCSP请求为防止重放攻击在requestExtensions字段添加noce时,此处应响应相同的noce值。
    • signatureAlgorithm:算法标识符
    • signature:签名值,基于tbsResponseData(DER编码)内容计算
    • certs:验证signature的证书,可选项

3.OCSP实践

  在了解OCSP原理后,应通过实践验证下解读的原理正确性。本章节以cn.bing.com为目标,进行验证。

 3.1 获取X509证书

方法1
  使用如下命令:openssl s_client -connect cn.bing.com:443,将“-----BEGIN CERTIFICATE-----”开始到“-----END CERTIFICATE-----”保存到bing.crt,即为网站证书(注意复制格式,容易出现多余字符串,从而导致出错,建议使用“方法2”)
方法2
  用浏览器直接打开cn.bing.com,例如使用chrome
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
  选择最下面的www.bing.com证书,导出文件保存的后缀为crt即可
在这里插入图片描述

 3.2 查看OCSP URL

方法1
  使用如下命令:openssl x509 -noout -ocsp_uri -in bing.crt
在这里插入图片描述

  可看到OCSP校验地址为http://oneocsp.microsoft.com/ocsp
方法2
  在windows中直接双击证书文件bing.crt,在“详细信息”-“授权信息访问”中,可查询到OCSP校验地址
在这里插入图片描述

 3.3 证书链

在这里插入图片描述
  如图所示,cn.bing.com的证书链共有三级
在这里插入图片描述
  将DigiCert Global Root G2和Microsoft Azure RSA TLS Issuing CA 04两个证书分别到处
在这里插入图片描述

  使用文本工具打开两个证书,将其中的内容复制到1个新文件中,该文件即为证书链文件。需注意Microsoft Azure RSA TLS Issuing CA 04证书放在新文件最开始,DigiCert Global Root G2放在文件后部,合并后的证书链文件如下图:
在这里插入图片描述

 3.4 OCSP验证

  先使用wireshark开启抓包,随后使用如下命令进行OCSP认证请求:
openssl ocsp -issuer "Microsoft Azure RSA TLS Issuing CA 04.crt" -CAfile chain.pem -cert bing.crt -text -url http://oneocsp.microsoft.com/ocsp,可以看到请求和响应信息,在尾部显示Response Verify Ok,以及bing.crt检查结果是good
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
  抓包文件如下:
  ocsp.pcapng

 3.5 OCSP请求分析

  通过分析wireshark抓包信息,OCSP请求包如下,结合2.1章节OCSP请求格式
  在这里插入图片描述
  optionalSignature未使用,tbsRequest数据解析如下

  3.5.1 version

   使用默认值,报文中已省略

  3.5.2 requestorName

   可选项,报文中未使用

  3.5.3 requestList

  1. reqCert字段
  • hashAlgorithm:表明使用SHA-1的HASH算法

  • issuerNameHash:值为16进制的e475019dc323e226741d6c40390795f90596462e。此值由颁发者DN的DER编码通过SHA-1计算出。计算过程如下:
    1. 查看bing.crt证书的颁发者
    在这里插入图片描述
    2. 因HASH值需要以DER编码进行计算,故查看DER编码内容
    在这里插入图片描述
    3. 将此段内容单独保存成文件bing-dn.bin(注意格式,以二进制格式保存)
    在这里插入图片描述
    4. 使用openssl命令openssl dgst -sha1 .\bing-dn.bin计算SHA-1值,结果和请求报文中的值一致。
    在这里插入图片描述

  • issuerKeyHash:值为16进制的3b70d153e976259d60a8ca660fc69bae6f54166a。此值由颁发者公钥的DER编码(不包含tag和length)通过SHA-1计算出。计算过程如下:
    1. bing.crt的颁发者证书为Microsoft Azure RSA TLS Issuing CA 04
    在这里插入图片描述
    2. 查看Microsoft Azure RSA TLS Issuing CA 04.crt的DER编码格式的公钥字段subjectPublicKeyInfo(注意:不包含tag和length)
    在这里插入图片描述
    3.将以上值单独保存到文件Microsoft Azure RSA TLS Issuing CA 04-public.bin(注意格式,以二进制格式保存)
    在这里插入图片描述
    4. 使用openssl命令openssl dgst -sha1 .\Microsoft Azure RSA TLS Issuing CA 04-public.bin计算SHA-1值,结果和请求报文中的值一致。
    在这里插入图片描述

  • serialNumber:值为16进制的3300651d5cf9d60cb7fdb542b8000000651d5c,打开bing.crt查看,序列号一致
    在这里插入图片描述

  1. singleRequestExtensions:可选项,报文中未使用

  3.5.4 requestExtensions

   扩展信息报文中包含nonce信息
   在这里插入图片描述

 3.6 OCSP响应分析

 OCSP响应抓包内容如下,结合2.3章节分析
在这里插入图片描述

  3.6.1 responseStatus

   报文中值为0x00,代表successful,响应成功

  3.6.2 responseBytes

   因responseStatus是successful,故此值存在

   3.6.2.1 responseBytes

   此为基础的OCSP响应,因此值为id-pkix-ocsp-basic
   在这里插入图片描述

   3.6.2.2 response(BasicOCSPResponse)
  1. tbsResponseData
    在这里插入图片描述
  • version:默认值,报文中已省略

  • responderID:报文中值为5ec339aeb89e74355bcc6231f9d43644e7eeb07f,计算过程为:

  • producedAt:报文中值为UTF时间在这里插入图片描述

  • responses:因请求就检查1个证书,此处responses数据中只有1个SingleResponse,SingleResponse数据如下

    • certID:值和OCSP请求中的一致。在存在多个SingleResponse时,可用于表明,该数组是对哪个证书的响应。在这里插入图片描述

    • certStatus:ASN.1编码值为80 00,代表good,表明certID标记的证书OCSP验证结果为未吊销,处于正常使用状态

    • thisUpdate:UTC时间,响应者最近查询状态的时间。

    • nextUpdate:UTC时间,建议下次查询时间。

    • singleExtensions:该值解读未仔细查询在这里插入图片描述

  • responseExtensions:因OCSP请求中requestExtensions中附加了nonce,因此此处将请求的nonce值返回,以表明响应何请求,避免重放攻击。

  1. signatureAlgorithm
    指明signature字段使用的签名算法,此处为在这里插入图片描述

  2. signature
    在这里插入图片描述
    在signature之前存在一个ASN.1编码为05 00的NULL值,OCSP响应中未发现此定义,也未查询到相关解读,暂留。

  3. certs
    验证signature的证书,将抓包中的整个Certificate选择,选择复制成Hex Stream,随后以二进制保存到ocsp.crt文件中,该文件即为OCSP响应的验签证书。
    在这里插入图片描述
    在这里插入图片描述

  文件如下:ocsp.crt

 3.7 OCSP响应手动验证

  在3.4章节,可以看到openssl已自动验证OCSP响应,结果为通过。此处,进行手动验证OCSP响应。OCSP验证应包含2步:

  1. 使用证书链验证OCSP响应中certs字段指明的证书是否合法
  2. 若certs指明的证书通过证书链验证,使用此证书验证OCSP响应中的signature字段签名是否合法
    若以上两步均验证通过,可认为OCSP响应合法,则正常读取certStatus状态值,以读取OCSP验证结果。

  3.7.1 证书链验证OCSP证书

  在3.6章节,我们从OCSP响应的certs字段提取到证书ocsp.crt。使用openssl命令openssl verify -verbose -CAfile chain.pem ocsp.crt,验证通过:
在这里插入图片描述

  3.7.2 验证签名

  使用ocsp.crt证书验签OCSP响应中的signature,待验签内容为OCSP响应中的tbsResponseData。验签步骤如下:

  1. 将OCSP响应中的tbsResponseData字段值以二进制格式保存到tbsResponseData.bin文件中
    在这里插入图片描述
    在这里插入图片描述

  2. 将OCSP响应中的signature字段值以二进制保存到ocsp-signature.bin文件中
    在这里插入图片描述
    在这里插入图片描述

  3. 通过signatureAlgorithm字段可知签名算法为sha256WithRSAEncryption
    在这里插入图片描述

首先从ocsp.crt提取出公钥到ocsp.pem,命令如下:
openssl x509 -in ocsp.crt -pubkey -noout -out ocsp.pem
随后进行验签
openssl dgst -sha256 -verify ocsp.pem -signature ocsp-signature.bin tbsResponseData.bin
在这里插入图片描述

可看到验签通过。

4.总结

  当要检查某个证书(下称待检查证书A)是否被吊销时,客户端需要发送OCSP请求,OCSP请求中附带“待检查证书A”的序列号等信息,当OCSP服务器收到OCSP请求时,读取OCSP请求中“待检查证书A”的序列号信息,并查询CRL,得到检查结果,随后将检查结果封装到OCSP响应中,使用服务器私钥对OCSP响应进行签名并将签名私钥对应的证书(称为OCSP响应证书B)和签名值附加在OCSP响应中。当客户端收到OCSP响应时,首先使用证书链对OCSP响应中的“OCSP响应证书B”进行验证,验证通过后,再使用“OCSP响应证书B”对OCSP响应中的响应值tbsResponse和签名值signature进行验签,验签通过,则表明OCSP响应合法,此时可读取OCSP响应中“待检查证书A”的校验结果,以确认“待检查证书A”是否被吊销。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值