CN117811738A - 一种网络中授权证书生成、认证的方法和设备 - Google Patents

Abstract

本申请提供了一种网络中授权证书生成、认证的方法和设备，通过在CAPKI系统中引入区块链系统，该区块链系统包括至少一个管理器，由于区块链系统中的每个管理器中都保存了授权记录，该授权记录用于表示第二管理器授权第三管理器，使得第三管理器可以向第三管理器管理的应用服务器签发证书，并且该授权记录包含第三管理器使用的第一公钥。因此，后续第三管理器向其管理域内的应用服务器颁发证书时使用的第一公钥不会被篡改，实现证书颁发行为的透明化和不可篡改性，可以保证授权证书的真实性。

Description

一种网络中授权证书生成、认证的方法和设备

技术领域

本申请实施例涉及公钥基础设施技术领域和区块链技术领域，并且更具体的，涉及一种网络中授权证书生成、认证的方法和设备。

背景技术

现有的三大公钥基础设施(public key infrastructure，PKI)实例系统中，证书授权机构(certificate authority，CA)PKI应用规模最广，CA PKI系统是极其庞大复杂的，中间CA机构非常多，而且极少有名称范围约束。也正是由于CA PKI系统中间CA太多，约束太少，只要授权证书链路径上的任何一个节点(例如，某个中间CA)被攻破，最终客户端都有可能获取到的是一个假的授权证书，比如客户端可能会访问某个假银行网站进行交易，使得客户端存在被攻击的风险。

目前，已经提出了一种方案解决该问题，该方案是采用“基于第三方监督日志的透明化机制”可以及时发现假证书或冒充证书。该方案考虑到：如果每个CA颁发证书的行为或者撤销证书的行为，都可以被记录，那就可以进行公开审计，后续如果客户端在公开的监督日志中检测到未经授权的证书被颁发，则可以立刻申请撤销该证书。

然而，上述方案主要是通过客户端审计证书颁发的记录，从而可以确定出假证书或者冒充证书，这种监督机制本身仍然不能防止虚假证书的颁发。

发明内容

本申请提供了一种网络中授权证书生成的方法，通过在CAPKI系统中引入区块链系统，该区块链系统包括至少一个管理器，由于区块链系统中的每个管理器中都保存了授权记录，该授权记录用于表示第二管理器授权第三管理器，使得第三管理器向第三管理器管理的应用服务器签发证书，并且该授权记录包含第三管理器使用的第一公钥，因此，后续第三管理器向其管理域内的应用服务器颁发证书时使用的第一公钥不会被篡改，实现证书颁发行为的透明化和不可篡改性，可以保证授权证书的真实性。

并且，由于本申请中设置了第三管理器，该第三管理器用于向其管理域下的应用服务器颁发证书，与现有的中间CA管理器任意向应用服务器发证书相比，可以进一步保障证书颁发的安全性，还可以减轻中间CA管理器向应用服务器颁发的证书的数量，便于管理应用服务器。

第一方面，提供了一种网络中授权证书生成的方法，该方法例如可以由管理器执行，或者，也可以由管理器的组成部件(例如芯片或者电路)执行，对此不作限定。

该方法包括：第二管理器基于第一证书向第三管理器进行授权，并生成授权记录，所述授权记录用于表示所述第二管理器授权所述第三管理器，使得所述第三管理器向所述第三管理器管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，其中，所述第一证书为第一管理器授权区块链系统中的任意两个管理器之间进行授权的授权证书，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器；所述第三管理器基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，所述第二证书为所述第三管理器器向所述应用服务器签发的授权证书，所述第二证书包含所述第一公钥。

应理解，本申请中，第一管理器也可以有多个。

需要说明的是，由于区块链系统中的各个管理器之间有“共识机制”，该“共识机制”使得区块链系统中各个管理器中保存的授权记录是同步的，或者也可以理解为区块链系统中的每个管理器保存的授权记录是一致的。“授权记录”一旦生成，区块链上的各个管理器都会签名并在各自在本地保存，一旦各个管理器都签名保存后，后续如果有任何一个管理器想要篡改该“授权记录”中的内容都是非常困难的，除非可以得到区块链中各个管理器的签名，否则，该“授权记录”的内容无法被篡改。例如，授权记录包含第三管理器使用的公钥(记为“第一公钥”)，后续第三管理器向其管理域中的应用服务器颁发证书时需要使用第一公钥签名，此时，“第一公钥”是不容易被篡改的。因此，本申请的方法可以确保证书颁发的安全性。

本申请中，“授权记录”例如，也可以表示第二管理器#1向第二管理器#2的授权，使得第二管理器#2代替第二管理器#1承担一些授权(例如，某些场景下第二管理器#1的负载太大，此时可考虑该实现方式)，即可以赋予第二管理器#2第一管理器#1原有的一些权力。假设，原本第二管理#1可以向第三管理器#1～第三管理器#5授权，第二管理器器#2可以向第三管理器#6～第三管理器#13授权，此时，第二管理器#2可以代替第二管理器#1向第三管理器#1～第三管理器#5授权。类似的，对于第三管理器也可以按照上述实现方式进行理解，不再赘述。

本申请中，由于第三管理器也是区块链系统中的一个节点，因此，第三管理器还可以实时监督区块链系统中的授权记录。从而可以确保第三证书的实时有效性。因此，本申请提供的授权证书的生成方法，使得客户端无需额外再查验第三证书的授权是否过期，在访问应用服务器时可以减少认证时延，提高用户的业务体验。

在一种可能的实现方式中，第一管理器向区块链系统中的任意一个管理器发送第一证书。

由于区块链系统中的各个管理器之间有“共识机制”，因此，第一管理器可以向区块链系统中的任意一个管理器发送第一证书，其中，如果其中一个管理器收到第一证书，其它管理器同步都会有该第一证书。

在一种可能的实现方式中，所述第一证书包括该区块链系统的第一区块的块头的第一哈希值，所述方法还包括：第三管理器生成第三证书，第三证书包括授权记录、所述授权记录在该区块链系统中对应的哈希路径以及该区块链系统的第一区块的块头，其中，所述第一哈希值、所述授权记录、该哈希路径以及该第三证书中的第一区块的块头用于验证第三证书的真实性。

在一种可能的实现方式中，第三证书中的第一区块的块头至少包括第一值，第一值为该区块链系统的第一区块的块体的哈希树树根的值，该第一证书、该授权记录、该哈希路径以及该第三证书中的第一区块的块头用于验证该第三证书的真实性，具体包括：该授权记录和该哈希路径用于确定第二值，该第二值为该区块链系统的第一区块的块体的哈希树树根的值；该第三证书中的该第一区块的块头用于确定第二哈希值；如果该第二值与该第一值相同，并且，该第二哈希值与该第一哈希值相同，则该第三证书具有真实性。

基于上述技术方案，本申请中，客户端在验证授权证书时通过验证各级证书里的公钥和签名是否形成一个完整的授权链条。与现有技术相比，本申请中，客户端还需要验证第三证书是否可信，并且是通过验证第三证书中区块链系统的第一区块的块头的第二哈希值是否与第一证书中的第二哈希值相同，以及通过第三证书中的授权记录和哈希路径是否可以计算出第一区块的块体的哈希树树根，从而确保第三证书是可信的，后续通过第三证书的公钥验证第二证书，从而进一步确保授权证书链的是真实可信的。

在一种可能的实现方式中，该方法还包括：第三管理器生成第二证书，第二证书为第三管理器向应用服务器颁发的证书；其中，第三证书用于验证第二证书的真实性。

在一种可能的实现方式中，第三证书用于验证第三证书第二证书的真实性，具体包括：如果第二证书中第三管理器使用的公钥为第三证书中的第一公钥，则第二证书具有真实性。

基于上述技术方案，本申请中，由于每个第三管理器可以管理众多应用服务器，因此，与第二管理器直接向应用服务器颁发证书相比，可以减少了授权证书的颁发数量，减轻第二管理器向应用服务器颁发证书的数量。本申请中，客户端可以通过第三证书验证第二证书，从而避免了将整个区块链系统中的授权记录的整个账本都发送给应用服务器，通过应用服务器发送给客户端。换句话说，本申请中，第二管理器可以生成轻量级的授权证书，减轻客户端的数量。

在一种可能的实现方式中，该方法还包括：第三管理器向应用服务器发送第一证书、第三证书以及第二证书。

本申请中，第三管理器可以向应用服务器发送授权证书链，以便于应用服务器可以向客户端出示授权证书链。

在一种可能的实现方式中，第一管理器为根证书授权机构管理器，第二管理器为中间证书授权机构管理器，第三管理器为端域授权证书管理器。

第二方面，提供了一种网络中授权证书认证的方法，该方法例如可以由客户端执行，或者，也可以由客户端的组成部件(例如芯片或者电路)执行，对此不作限定。

该方法包括：客户端向服务器发送访问请求消息，访问请求消息用于请求获取应用服务器的授权证书链；客户端接收来自服务器的访问响应消息，访问响应消息携带第一证书、第三证书以及第二证书；其中，所述第一证书是第一管理器生成的，所述第一证书为所述第一管理器授权所述区块链系统中的任意两个管理器之间进行授权的授权证书，所述区块链系统包括至少一个管理器；所述第三证书是第三管理器生成的，所述第三证书包含授权记录，所述授权记录是第二管理器基于所述第一证书向所述第三管理器授权生成的记录，所述授权记录用于表示所述第二管理器授权所述第三管理器，使得所述第三管理器向所述第三管理器管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，其中，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器，所述第二证书是所述第三管理器基于所述授权记录和所述第一公钥向所述应用服务器签发授权证书，所述第二证书包含所述第一公钥；客户端根据第一证书和授权记录验证第三证书的真实性；客户端根据第三证书验证第二证书的真实性。

基于上述技术方案，本申请中，通过在CAPKI系统中引入区块链系统，该区块链系统包括至少一个管理器，由于区块链系统中的每个管理器中都保存了授权记录，该授权记录用于表示第二管理器授权第三管理器，使得第三管理器向第三管理器管理的应用服务器签发证书，并且该授权记录包含第三管理器使用的第一公钥，因此，后续第三管理器向其管理域内的应用服务器颁发证书时使用的第一公钥不会被篡改，实现证书颁发行为的透明化和不可篡改性，可以保证授权证书的真实性。

在一种可能的实现方式中，第一证书是第一管理器向区块链系统中的任意一个管理器发送的授权证书。

在一种可能的实现方式中，该第一证书包括所述区块链系统的第一区块的块头的第一哈希值，所述第三证书包括所述授权记录、所述授权记录在所述区块链系统中对应的哈希路径以及所述区块链系统的第一区块的块头，所述第三证书中的所述第一区块的块头至少包括第一值，所述第一值为所述区块链系统的第一区块的块体的哈希树树根的值，所述客户端根据所述第一证书和所述授权记录验证所述第三证书的真实性，包括：所述客户端根据所述授权记录和所述哈希路径确定第二值，所述第二值为所述区块链系统的第一区块的块体的哈希树树根的值；所述客户端根据所述第三证书中的所述第一区块的块头确定第二哈希值；如果所述客户端确定所述第二值与所述第一值相同，并且，确定所述第二哈希值与所述第一哈希值相同，则所述客户端确定所述第三证书具有真实性。

基于上述技术方案，本申请中，客户端在验证授权证书时通过验证各级证书里的公钥和签名是否形成一个完整的授权链条。与现有技术相比，本申请中，客户端还需要验证第三证书是否可信，并且是通过验证第三证书中区块链系统的第一区块的块头的第二哈希值是否与第一证书中的第二哈希值相同，以及通过第三证书中的授权记录和哈希路径是否可以计算出第一区块的块体的哈希树树根，从而确保第三证书是可信的，后续通过第三证书的公钥验证第二证书，从而进一步确保授权证书链的是真实可信的。

在一种可能的实现方式中，客户端根据第三证书验证第二证书的真实性，包括：客户端通过确定第二证书中第三管理器使用的公钥为第三证书中的第一公钥，则客户端确定第二证书具有真实性。

基于上述技术方案，本申请中，由于每个第三管理器可以管理众多应用服务器，因此，与第二管理器直接向应用服务器颁发证书相比，可以减少了授权证书的颁发数量，减轻第二管理器向应用服务器颁发证书的数量。本申请中，客户端可以通过第三证书验证第二证书，从而避免了将整个区块链系统中的授权记录的整个账本都发送给应用服务器，通过应用服务器发送给客户端。换句话说，本申请中，第二管理器可以生成轻量级的授权证书，减轻客户端的负载。

在一种可能的实现方式中，第一管理器为根证书授权机构管理器，第二管理器为中间证书授权机构管理器，第三管理器为端域授权证书管理器。

在一种可能的实现方式中，第三管理器还用于实时监督区块链系统中的授权记录。

基于上述技术方案，本申请中，第三管理器还可以实时监督区块链系统中的授权记录，从而可以确保第三证书的实时有效性。因此，本申请提供的授权证书的生成方法，使得客户端无需额外再查验第三证书的授权是否过期，在访问应用服务器时可以减少认证时延，提高用户的业务体验。

在一种可能的实现方式中，在所述访问请求消息还用于请求获取所述应用服务器的互联网协议地址的情况下，第二证书还包括应用服务器的互联网协议地址，该服务器为递归服务器，该递归服务器用于实时缓存区块链系统中的第一证书、第三证书和第二证书。

基于上述技术方案，本申请中提出：客户端可以向递归服务器查询应用服务器(或者，也可以理解为“某个应用名称”)对应的IP地址和公钥，这种方式只需要客户端向递归服务器查询一次，并且一次查询过程既解析了应用服务器域名对应的IP地址，又完成了授权证书链的验证。

与现有技术中，客户端访问应用服务时需要发送两次相比请求消息，先向应用服务器请求获取其IP地址，再向应用服务器请求获取应用服务器的授权证书链相比，本申请中，整体上，客户端只需要一次查询请求便可以验证可信身份，接着进行可信访问，避免了多次发送请求消息暴露客户端隐私的问题，并且访问时延短，提高了用户的业务体验以及访问安全性。

在一种可能的实现方式中，该服务器为应用服务器，在客户端向服务器发送访问请求消息之前，该方法还包括：客户端向域名系统DNS服务器发送域名解析请求消息，域名解析请求用于请求获取应用服务器的互联网协议地址；客户端接收来自DNS服务器的域名解析响应消息，域名解析响应消息携带应用服务器的互联网协议地址。

在一种可能的实现方式中，若该访问请求消息还携带第一随机数，则第二证书还包括第一随机数，第二证书为第三管理器通过第一公钥实时签名生成的。

基于上述技术方案，本申请中，可以通过随机数挑战，应用服务器向客户端出示实时有效的EE证书，从而可以避免应用服务器出示的证书实际上已经被撤销了，提高了用户的业务体验以及访问安全性。并且，基于本申请提供的技术方案，由于第三管理实时监督区块链系统中的授权记录可以确保第三证书的实时有效性，并且通过“随机数挑战模式”也可以确保第二证书的实时有效性，从而使得客户端可以省去的授权证书有效性检查过程，减少访问认证的时延，提高了用户的业务体验。同时，由于减少可客户端与管理器之间信息交互检查授权证书的有效性，还可以避免多次发送请求消息暴露客户端隐私的问题，使得客户端可以更加安全的与应用服务器进行通信。

第三方面，提供了一种网络中授权证书生成的系统，该系统包括：区块链系统，其中，所述区块链系统包括至少一个管理器，第二管理器用于基于第一证书向第三管理器进行授权，并生成授权记录，所述授权记录用于表示所述第二管理器授权所述第三管理器，使得所述第三管理器向所述第三管理器管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，其中，所述第一证书为第一管理器授权区块链系统中的任意两个管理器之间进行授权的授权证书，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器；第三管理器用于基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，所述第二证书为所述第三管理器器向所述应用服务器签发的授权证书，所述第二证书包含所述第一公钥。

其中，系统侧技术方案对应的有益效果以及下述设备对应的有益效果可以参照方法侧的有益效果的描述，此处不再赘述。

在一种可能的实现方式中，第一管理器还用于向所述区块链系统中的任意一个管理器发送所述第一证书。

在一种可能的实现方式中，第三管理器还用于实时监督区块链系统中的授权记录。

在一种可能的实现方式中，该第一证书包括该区块链系统的第一区块的块头的第一哈希值，该第三管理器用于生成第三证书，该第三证书包括所述授权记录、该授权记录在该区块链系统中对应的哈希路径以及该区块链系统的第一区块的块头，其中，该第一哈希值、该授权记录、该哈希路径以及该第三证书中的该第一区块的块头用于验证该第三证书的真实性。

在一种可能的实现方式中，该第三证书中的第一区块的块头至少包括第一值，第一值为区块链系统的第一区块的块体的哈希树树根的值，第一证书、授权记录、哈希路径以及第三证书中的第一区块的块头用于验证第三证书的真实性，具体包括：授权记录和所述哈希路径用于确定第二值，第二值为区块链系统的第一区块的块体的哈希树树根的值；第三证书中的第一区块的块头用于确定第二哈希值；如果第二值与第一值相同，并且，第二哈希值与第一哈希值相同，则第三证书具有真实性。

在一种可能的实现方式中，第三管理器还用于生成第二证书，第二证书为第三管理器向应用服务器颁发的证书；其中，第三证书用于验证第二证书的真实性。

在一种可能的实现方式中，第三证书用于验证第二证书的真实性，具体包括：如果第二证书中第三管理器使用的公钥为第三证书中的第一公钥，则第二证书具有真实性。

在一种可能的实现方式中，第三管理器还用于向应用服务器发送第一证书、第三证书以及第二证书。

在一种可能的实现方式中，第一管理器为根证书授权机构管理器，第二管理器为中间证书授权机构管理器，第三管理器为端域授权证书管理器。

第四方面，提供了一种网络中授权证书生成的设备，该设备用于执行上述第一方面中任一种可能实现方式中的方法。具体地，该设备可以包括用于执行第一方面中任何一种可能实现方式中的方法的单元和/或模块。

在一种实现方式中，该设备为管理设备(例如，CA管理器)。当该设备为管理设备时，通信单元可以是收发器，或，输入/输出接口；处理单元可以是至少一个处理器。可选地，收发器可以为收发电路。可选地，输入/输出接口可以为输入/输出电路。

在另一种实现方式中，该设备为用于管理设备的芯片、芯片系统或电路。当该设备为用于通信设备的芯片、芯片系统或电路时，通信单元可以是该芯片、芯片系统或电路上的输入/输出接口、接口电路、输出电路、输入电路、管脚或相关电路等；处理单元可以是至少一个处理器、处理电路或逻辑电路等。

例如，该设备可以为公钥基础设施PKI设备。

第五方面，提供了一种网络中授权证书生成的设备，该设备包括：至少一个处理器，用于执行存储器存储的计算机程序或指令，以执行上述第一方面中任一方面中任一种可能实现方式中的方法。可选地，该设备还包括存储器，用于存储的计算机程序或指令。可选地，该设备还包括通信接口，处理器通过通信接口读取存储器存储的计算机程序或指令。

在一种实现方式中，该设备为管理设备。

在另一种实现方式中，该设备为用于管理设备的芯片、芯片系统或电路。

例如，该设备可以为公钥基础设施PKI设备。

第六方面，提供了一种网络中授权证书认证的设备，该设备用于执行上述第二方面中任一种可能实现方式中的方法。具体地，该设备可以包括用于执行第二方面中任何一种可能实现方式中的方法的单元和/或模块。

在一种实现方式中，该设备为客户端设备。当该设备为客户端设备时，通信单元可以是收发器，或，输入/输出接口；处理单元可以是至少一个处理器。可选地，收发器可以为收发电路。可选地，输入/输出接口可以为输入/输出电路。

在另一种实现方式中，该设备为用于客户端设备的芯片、芯片系统或电路。当该设备为用于通信设备的芯片、芯片系统或电路时，通信单元可以是该芯片、芯片系统或电路上的输入/输出接口、接口电路、输出电路、输入电路、管脚或相关电路等；处理单元可以是至少一个处理器、处理电路或逻辑电路等。

第七方面，提供了一种网络中授权证书生成的设备，该设备包括：至少一个处理器，用于执行存储器存储的计算机程序或指令，以执行上述第二方面中任一方面中任一种可能实现方式中的方法。可选地，该设备还包括存储器，用于存储的计算机程序或指令。可选地，该设备还包括通信接口，处理器通过通信接口读取存储器存储的计算机程序或指令。

在一种实现方式中，该设备为客户端设备。

在另一种实现方式中，该设备为用于客户端设备的芯片、芯片系统或电路。

第八方面，本申请提供一种处理器，包括：输入电路、输出电路和处理电路。所述处理电路用于通过所述输入电路接收信号，并通过所述输出电路发射信号，使得所述处理器执行第一方面或第二方面中任一方面中任一种可能实现方式中的方法。

在具体实现过程中，上述处理器可以为一个或多个芯片，输入电路可以为输入管脚，输出电路可以为输出管脚，处理电路可以为晶体管、门电路、触发器和各种逻辑电路等。输入电路所接收的输入的信号可以是由例如但不限于收发器接收并输入的，输出电路所输出的信号可以是例如但不限于输出给发射器并由发射器发射的，且输入电路和输出电路可以是同一电路，该电路在不同的时刻分别用作输入电路和输出电路。本申请实施例对处理器及各种电路的具体实现方式不做限定。

对于处理器所涉及的发送和获取/接收等操作，如果没有特殊说明，或者，如果未与其在相关描述中的实际作用或者内在逻辑相抵触，则可以理解为处理器输出和接收、输入等操作，也可以理解为由射频电路和天线所进行的发送和接收操作，本申请对此不做限定。

第九方面，提供了一种处理设备，包括处理器和存储器。该处理器用于读取存储器中存储的指令，并可通过收发器接收信号，通过发射器发射信号，以执行第一方面或第二方面中任一方面中任一种可能实现方式中的方法。

可选地，所述处理器为一个或多个，所述存储器为一个或多个。

可选地，所述存储器可以与所述处理器集成在一起，或者所述存储器与处理器分离设置。

在具体实现过程中，存储器可以为非瞬时性(non-transitory)存储器，例如只读存储器(read only memory，ROM)，其可以与处理器集成在同一块芯片上，也可以分别设置在不同的芯片上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

应理解，相关的数据交互过程例如发送指示信息可以为从处理器输出指示信息的过程，接收能力信息可以为处理器接收输入能力信息的过程。具体地，处理器输出的数据可以输出给发射器，处理器接收的输入数据可以来自收发器。其中，发射器和收发器可以统称为收发器。

上述第九方面中的处理设备可以是一个或多个芯片。该处理设备中的处理器可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，该处理器可以是逻辑电路、集成电路等；当通过软件来实现时，该处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，该存储器可以集成在处理器中，可以位于该处理器之外，独立存在。

第十方面，提供了一种芯片，该芯片获取指令并执行该指令来实现上述第一方面以及第一方面的任意一种实现方式中的方法。

可选地，作为一种实现方式，该芯片包括处理器与数据接口，该处理器通过该数据接口读取存储器上存储的指令，执行上述第一方面或第二方面以及第一方面的任意一种实现方式中的方法。

可选地，作为一种实现方式，该芯片还可以包括存储器，该存储器中存储有指令，该处理器用于执行该存储器上存储的指令，当该指令被执行时，该处理器用于执行第一方面或第二方面中中的任意一种实现方式中的方法。

第十一方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述第一方面或第二方面中任意一种实现方式中的方法。

第十二方面，提供了一种计算机可读存储介质，包括指令；所述指令用于实现上述第一方面或第二方面中任意一种实现方式中的方法。

作为示例，这些计算机可读存储包括但不限于如下的一个或者多个：只读存储器(read-only memory，ROM)、可编程ROM(programmable ROM，PROM)、可擦除的PROM(erasablePROM，EPROM)、Flash存储器、电EPROM(electrically EPROM，EEPROM)以及硬盘驱动器(harddrive)。

可选地，作为一种实现方式，上述存储介质具体可以是非易失性存储介质。

第十三方面，提供一种授权证书认证的系统，该系统包括上述第三方面任一种实现方式中的网络中授权证书生成的系统，以及，客户端设备，所述客户端设备用于执行上述第二方面中任一方面中的任一种可能实现方法。

在一种可能的实现方式中，该系统还包括应用服务器，

第十四方面，提供一种授权证书认证的系统，该系统包括上述第四方面或第五方面中任一种实现方式中的网络中授权证书生成的设备，以及第六方面或第七方面中任一中实现方式中的网络中授权证书认证的设备。

在一种可能的实现方式中，该系统还包括应用服务器。

附图说明

图1是CA PKI中证书授权流程的示意图。

图2是CA PKI中另一证书授权流程的示意图。

图3是本申请提出的一种网络中授权证书生成方法的架构示意图。

图4是本申请提出的另一种网络中授权证书生成方法的架构示意图。

图5是本申请提出的客户端验证授权证书的示意性流程图。

图6是本申请提出的一种网络中授权证书生成设备或者网络中授权证书认证设备的示意性框图。

图7是本申请提出的一种网络中授权证书生成设备或者网络中授权证书认证设备的示意性框图。

具体实施方式

下面将结合附图，对本申请实施例中的技术方案进行描述。

为了便于理解本申请的技术方案，下面首先将本申请涉及的专业术语进行简单的介绍。

1、公钥基础设施(public key infrastructure，PKI)

又称为“公开密钥基础架构”、“公钥基础建设”、或者“公钥基础机构”，是一组由硬件、软件、参与者、管理政策与流程组成的基础架构，能够为所有网络应用提供加密和数字签名等密码服务及所必须的密钥和证书管理体系。简单来说PKI就是利用公钥理论和技术建立的提供的安全服务设施，是信息安全技术的核心。其目的在于创造、管理、分配、使用、存储以及撤销数字证书。PKI既不是一个协议，也不是一个软件，它是一个标准，在这个标准之下发展出的为了实现安全基础服务目的的技术统称为PKI。

也可以理解为，PKI是大规模跨域网络安全通信的信任锚点，负责安全通信实体(例如，服务器、设备等)的公钥的注册、分发、储存、撤销等一系列管理行为。PKI支撑着整个网络安全体系架构，包括网络层的互联网安全协议(internet protocol security，IPSec)、传输层的安全传输层协议(transport layer security，TLS)、应用层的安全多用途网际邮件扩充协议(secure multipurpose internet mail extensions，S/MIME)等。PKI由一系列授权机构管理服务器(后文简称“管理器”)构成，每个管理器有一对公钥和私钥，用于签名授权内容。

根据授权资源的不同，目前存在三种PKI系统包括：证书授权机构(certificateauthority，CA)、域名系统安全扩展(domain name system security extensions，DNSSec)、资源公共公钥基础架构(resource public key infrastructure，RPKI)。现有的三大PKI实例系统中，CA PKI应用规模最广，CA是PKI的核心，即CA是数字证书的申请及签发机关，CA必须具备有权威性的特征，它是负责管理PKI结构下的所有用户(例如，各种应用程序)的证书，把用户的公钥和用户的其他信息捆绑在一起，在网上验证用户的身份，CA还有负责用户证书的黑名单登记和黑名单发布。但是，CA PKI的授权链是由非资源持有者层层授权的。这种第三方带外授权的方式会造成客户端无法高效的验证应用服务器的出示的授权证书是否是实时有效的，会造成冒充者攻击。

2、数字签名

数字签名是基于非对称密钥加密技术与数字摘要技术的应用，是一个包含电子文件信息以及发送者身份，并能够鉴别发送者身份以及发送信息是否被篡改的一段数字串。一段数字签名数字串，包含了电子文件经过哈希(hash)编码后产生的数字摘要，即一个Hash函数值以及发送者的公钥和私钥三部分内容。发送方通过私钥加密后发送给接收方，接收方使用公钥解密，通过对比解密后的hash函数值确定数据电文是否被篡改。

CA机构颁发的数字证书分为公钥证书和私钥证书：公钥证书是对外公开、任何人都可以使用的，而私钥证书是专属于签署人所有的。当需要签署文档时，签署人使用私钥证书对电子文件(例如，文件的哈希值)进行加密，从而形成电子签名。CA会对用户证书的内容做哈希运算，然后用自己的私钥对运算出的摘要进行非对称加密。而CA的公钥是公开的，用户可以用CA公钥解密出经CA私钥加密的原始摘要，同时得到原始的用户证书的内容。再对其使用同样的哈希算法得到一个摘要值，对比两个摘要值，如果两个摘要值一致则说明数据内容没有被篡改过，可以信任，从而确保证书的合法性和不可篡改性。

因此，通过数字签名，可以鉴定签名人的身份，以及表达对一项电子数据内容的认可。另外，它还能验证出文件的原文在传输过程中有无变动，确保传输电子文件的完整性、真实性和不可抵赖性，从而确保电子合同内容具有法律效力。

3、根证书

“根证书”通常是指获得广泛认可，通常已预先安装在各种软件(例如，操作系统、浏览器、电邮软件等)，一般作为信任链的起点，来自于公认可靠的政府机关、软件公司、证书颁发机构公司等，与各大软件商透过严谨的核认程序才在不同的软件广泛部署。由于部署程序复杂费时，需要行政人员的授权及机构法人身份的核认，一张根证书有效期可能长达十年以上。在某些企业，也可能会在内部电脑自行安装企业自签的根证书，以支持内部网的企业级软件；但是这些证书可能未被广泛认可，只在企业内部适用。

4、授权证书

“授权证书”也可以称为“属性证书”，本身没有公钥，必须依附在一张有效的数字证书上才有意义，其用处是赋予相关拥有人签发证书的权力。

5、终端实体(end entity，EE)证书

“终端实体证书”也可以称为“叶子证书”，该证书不会用作签发其它证书的。在实际的软件中部署，以便创建加密通道时应用。

6、授权证书链

“证书链”通常由：根证书、中间证书、用户证书组成的一条完整证书信任链。只有当整个证书信任链上的各个证书都有效时，应用服务器才会认定当前颁发给用户的证书是有效和受信任的。

7、区块链

区块链是一种去中心化的分布式数据库，可以维护一份连续不断的交易记录，每一笔资料被称为一个区块(block)。一个区块分为两部分，区块头和区块体。其中，区块头中存储了区块的头信息，包含上一个区块的块头的哈希值(prehash)、本区块的块体的哈希树树根以及时间戳；区块体存储着这个区块的详细数据，例如，可以是交易信息，也可以是其它某种信息。每一个区块可以包含一笔以上的交易，每个区块都会与另一个区块产生连接(linking)，每个区块都会包含上个区块的hash值，所有被连接在一起的区块被称为链(chain)。

在区块链中，交易记录会分布到多个节点，所有的节点会共同维护整个分布式数据库，每一个区块是否为合法有效的区块不由一个节点决定，只有大多数节点(超过50％的节点)共同验证后的区块才是合法有效的区块。即，区块链中的每个节点必须存储所有区块的交易记录，每一个节点都可以协助验证各个区块的合法性与有效性。换句话说，区块链上任何一笔交易被篡改都将破坏整个区块的完整性，但是该交易被篡改的几率是极小的。

下面简单介绍一下现有的证书颁发和认证流程，图1示出了CA PKI中证书授权流程和访问流程。图1中包括客户端、应用服务器、根(root)授权机构以及中间证书授权机构CA。

按目前的标准(例如，国际电信联盟(international telecommunication union，ITU)的X.509标准)证书分为两类：CA证书和EE证书。CA证书可以颁发下级证书，EE证书不可再颁发下级证书，EE证书记录着应用服务的应用信息，供客户端验证。其中，根证书可以用于验证CA证书，客户端的可信根库里预置了一些根证书作为验证授信链的锚点。例如，若客户端预置存储了该根证书，则该根证书颁发的CA证书是可信的，此时客户端确定CA证书颁发的EE证书也是可信的。根CA管理器和中间CA管理器通过私钥签名，逐层授信下级证书里的内容，可信绑定关联关系，包括下级证书的名称(例如，CA的名称、应用服务器的域名，等等)和公钥等字段，形成证书链。当客户端请求安全访问应用服务器后，服务器出示证书链供客户端验证。客户端的验证流程包含下述步骤：

步骤一，验证各级证书里的公钥和签名是否形成一个完整的授权链条。例如，若应用服务器出示的根证书在预置的库里，则根证书可信，则根证书自签名的key1(即，证书颁发者的公钥ID(authority identifier，AKI))有效，如果中间证书是根证书的key1签名的，则key2(即，证书使用者的公钥ID(subject key identifier，SKI))有效，如果EE证书是中间机构的key2(即，证书颁发者的公钥)签名的，则key3有效(即，证书使用者的公钥)。若中间任何一个签名验证不通过，则授权链不完整。

例如，图1示出的证书#1～证书#3，其中，证书#1是根CA管理器中预置的，因此，颁发者和使用者均为根CA管理器，根CA管理器的公钥为key1，并且该证书是由根CA管理器签名的。证书#2是根CA管理器向中间CA管理器颁发的证书，即，颁发者为根CA管理器，使用者为中间CA管理器，其中颁发者公钥为key1，使用者公钥为key2，并且该证书是根CA管理器签名的。证书#3是中间CA管理器向应用服务器颁发的证书，因此，颁发者为中间CA管理器，使用者为应用服务器(例如，该应用服务的域名为“www.xy.com”)，并且该证书是由中间CA管理器签名的。假设，客户端请求访问应用服务器，则应用服务器可以向客户端发送证书链(即，证书#1～证书#3)，客户端可以通过本地预置的可信根证书库中验证证书#1是否可信，并通过证书#1验证证书#2是否可信，通过证书#2验证证书#3是否可信。

步骤二，客户端验证EE证书里的应用或资源信息和实际访问情况是否相符合。例如对于web应用，客户端当前访问的域名是否包含在EE证书的使用者名称的字段中(commonname字段)里或备用名字段中(subject alternative name，SAN)。

步骤三，客户端除了要验证证书授信链的完整性和真实性，还需要验证服务器出示的证书是不是实时有效的。因为，有可能虽然证书在有效期内，但被临时动态撤销了。例如，因为私钥泄露或握手协议层(handshake protocol layer，SSL)实现库有漏洞。客户端需要逐链接或者周期性的查询中间CA管理器是否动态撤销了已颁发的CA证书。

图2示出了现有的CAPKI系统中，根CA管理器向中间CA管理器颁发证书，以及中间证书CA向应用服务器颁发证书的示意图。如图2所示，CA PKI体系是极其庞大复杂的，例如，根CA管理器可能有上百个，中间CA管理器可能有上千个，并且中间CA管理器颁发证书时极少有名称范围的约束。比如，目前很少约束中间CA管理器只能向某个服务器颁发证书。并且，应用服务器也不能控制由谁为其颁发证书。这样，形成的颁发证书的关系不是“一棵树”的逻辑关系，而更像是一个有向无环图。目前，测量结果显示中间CA管理器有1800多个，只有7个中间管理器有约束可以向某些特定的应用服务器颁发证书，且多于一半的中间CA管理器还能再能为下一级的中间CA管理器签发证书。EE证书量级更大，有上百万个。在图2中，根CA管理器向中间CA颁发授权证书，该授权证书包含中间CA的公钥，该公钥只有该中间CA知道，其它中间CA可能不知道该中间CA的公钥，因此，该中间CA极容易篡改密钥向应用服务器颁发一个虚假的证书。因此，只要授权证书链路径上的任何一个节点(例如，某个中间CA)被攻破，最终客户端都有可能访问到一个虚假的证书，继而处于高风险中。

目前，针对图2示出的CA PKI系统中间CA管理器颁发证书无约束的问题，已经提出了一种方案解决该问题，该方案是采用“基于第三方监督日志的透明化机制”可以及时发现假证书或冒充证书。该方案考虑到：如果每个CA颁发证书的行为或者撤销证书的行为，都可以被记录，那就可以进行公开审计，后续如果客户端在公开的监督日志中检测到未经授权的证书被颁发，则可以立刻申请撤销该证书。然而，上述方案主要是通过客户端审计证书颁发的记录，从而可以确定出假证书或者冒充证书，这种监督机制本身仍然不能防止虚假证书的颁发。

有鉴于此，本申请提供了一种网络中授权证书生成、认证方法，通过在CA PKI系统中引入区块链系统，该区块链系统包括至少一个管理器，由于区块链系统中的每个管理器中都保存了授权记录，该授权记录用于表示第二管理器授权第三管理器，使得第三管理器向第三管理器管理的应用服务器签发证书，并且该授权记录包含第三管理器使用的第一公钥，因此，后续第三管理器向其管理域内的应用服务器颁发证书时使用的第一公钥不会被篡改，实现证书颁发行为的透明化和不可篡改性，可以保证授权证书的真实性。

并且，由于本申请中设置了第三管理器，该第三管理器用于向其管理域下的应用服务器颁发证书，与现有的中间CA管理器任意向应用服务器发证书相比，可以进一步保障证书颁发的安全性，还可以减轻中间CA管理器向应用服务器颁发的证书的数量，便于管理应用服务器。

本申请提供的网络中授权证书生成、认证方法，例如可以应用于在广域网(例如，Internet)中，具体的，客户端访问应用服务器(或者，对等端时)需要通过PKI认证对方的身份。需要说明的是，本申请提供的该方法，并不局限上述具体场景，例如，本申请提供的网络中授权证书生成、认证方法还可以应用于物联网中的标识解析系统中。

图3是本申请提出一种网络中授权证书生成方法的示意性流程图，如图3所示，该方法包括：

可选的，步骤301，第一管理器向区块链系统中的任意一个管理器发送第一证书。

由于区块链系统中的各个管理器(本申请中，区块链系统中的各个管理器也可以理解为区块链系统中的各个节点)之间有“共识机制”，因此，第一管理器可以向区块链系统中的任意一个管理器发送第一证书，其中，如果其中一个管理器收到第一证书，其它管理器同步都会有该第一证书。

本申请中的第一证书为第一管理器授权区块链系统中的任意两个管理器之间进行授权的授权证书。换句话说，本申请中，区块链系统中的各个管理器之间都可以进行授权事项，不予限定。例如，第二管理器可以向第三管理器授权，表示第三管理器可以向第三管理器管理的应用服务器颁发证书。又例如，第二管理器#1可以向第二管理器#2授权，表示第二管理器#2可以代替第二管理器#1，为第二管理器#1分担一些授权事务，等等。

本申请中，第一管理器可以理解为是可信的管理器。例如，第一管理器可以是根CA管理器。本申请中，区块链系统包括至少一个管理器。例如，区块链系统还可以包括至少一个第二管理器和至少一个第三管理器。

其中，第一证书包括区块链系统的第一区块(该“第一区块”可以指代区块系统中的任意一个区块)的块头的第一哈希值。例如，第一证书为区块链连头的授信证书(signedblock header，SBH)。换句话说，本申请中，第一管理器可以为该区块链系统的第一区块签发证书，即，该第一证书中包括区块链系统的第一区块的块头的第一哈希值。第一证书的颁发者为第一管理器，第一证书的使用者可以为该区块链系统，并且该第一证书是由第一管理器签名的。

例如，区块链系统向第一管理器申请证书时，第一管理可以生成第一证书并发送给区块链系统中的任意一个管理器。

本申请中，第一管理器也可以有多个。

步骤302，第二管理器基于第一证书向第三管理器进行授权，并生成授权记录。

本申请中，该授权记录用于表示第二管理器授权第三管理器，使得第三管理器向第三管理器管理的应用服务器签发证书，其中，授权记录保存在该区块链系统中的每个管理中。

本申请中，第二管理器例如可以为中间CA管理器，第二管理器为至少一个第二管理器中的一个管理器。第三管理器用于为其管理域下的应用服务器颁发证书，第三管理器为至少一个管理器中的另一个管理器。例如，第三管理器为端域CA管理器。

本申请中，“授权记录”也可以称作“授权事务记录”，该授权记录的颁发者为第二管理器，使用者为第三管理器。

该授权记录具体包括：第二管理器使用的第二公钥、第三管理器的名称以及第三管理器使用的第一公钥。

需要说明的是，由于区块链系统中的各个管理器之间有“共识机制”，该“共识机制”使得区块链系统中各个管理器中保存的授权记录是同步的，或者也可以理解为区块链系统中的每个管理器保存的授权记录是一致的。“授权记录”一旦生成，区块链上的各个管理器都会签名并在各自在本地保存，一旦各个管理器都签名保存后，后续如果有任何一个管理器想要篡改该“授权记录”中的内容都是非常困难的，除非可以得到区块链中各个管理器的签名，否则，该“授权记录”的内容无法被篡改。例如，授权记录包含第三管理器使用的公钥(记为“第一公钥”)，后续第三管理器向其管理域中的应用服务器颁发证书时需要使用第一公钥签名，此时，“第一公钥”是不容易被篡改的。因此，本申请的方法可以确保证书颁发的安全性。

可选的，步骤303，第三管理器生成第三证书。

本申请中，第三证书包括授权记录、授权记录在区块链系统中对应的哈希路径(即，区块链系统整个merkle tree)以及区块链系统的第一区块的块头。并且该第三证书是由第二管理器签名的。例如，第三证书可以称作授权存在性证据(inclusion proof，INPRF)

本申请中，第一证书、授权记录和哈希路径可以用于验证第三证书的真实性。具体的，客户端在验证第三证书时，主要需要验证以下两部分的内容。一方面，客户端可以根据授权记录和哈希路径确定第二值，该第二值为区块链系统的第一区块的块体哈希树树根。由于，第三证书中包含的第一区块的块头包含第一值，该第一值为区块链系统的第一区块的块体的哈希树树根的值。因此，客户端可以通过第一区块的块头直接获得区块链系统的第一区块的块体哈希树树根的值，客户端也可以通过哈希路径和授权记录计算出区块链系统的第一区块的块体哈希树树根的值。客户端可以通过比较两个值是否相同验证第三证书是否可信。另一方面，客户端可以将第三证书中的第一区块的块头整体作哈希运算获取第二哈希值，客户端通过比较第二哈希值是否与第一哈希值相同，可以验证第三证书是否可信。如果第一区块的块体的哈希树树根的值相同，并且，第二哈希值与第一哈希值相同，则客户端确定第三证书是可信的。

如前所述，现有的方案中，客户端在验证授权证书时通过验证各级证书里的公钥和签名是否形成一个完整的授权链条。与现有技术相比，本申请中，客户端还需要验证第三证书是否可信，并且是通过验证第三证书中区块链系统的第一区块的块头以及第一区块的块体的哈希树树根，从而确保第三证书是可信的，后续通过第三证书的公钥验证第二证书，从而进一步确保授权证书链的是真实可信的。

现有技术中，一般都是根证书直接向中间CA管理器颁发证书，并没有基于区块链系统的pki方案，也可以理解为，现有技术中，并不会验证区块链系统中第二管理器向第三管理器授权行为是否为可信的。本申请中，通过将区块链系统第一区块的块头本身的哈希嵌入到授权证书里(例如，第一证书中包含第一区块的块头的第一哈希值)，增加了一步授权验证(即，验证第三证书是否是可信的)，增强了授权证书颁发的安全性，并且保证授权链的完整性。

并且，由于每个端域CA管理器可以管理众多应用服务器，因此，与中间CA管理器直接向应用服务器颁发证书相比，将中间管理器颁发证书的数量从“应用服务器量级”降低到了“端域CA管理器量级”。换句话说，本申请中，可以减轻中间CA管理器颁发证书的量级。本申请中，客户端可以通过第三证书验证第二证书，从而避免了将整个区块链系统中的授权记录的整个账本都发送给应用服务器，然后再通过应用服务器发送给客户端。换句话说，本申请中，第二管理器可以生成轻量级的授权证书，减轻客户端的负载。

例如，第三管理器向第二管理器申请证书时，第二管理可以生成第三证书并发送给第三管理器。

可选的，步骤304，第三管理器基于授权记录和第一公钥向该应用服务器签发第二证书。

本申请中，第二证书为第三管理器向该应用服务器签发的授权证书，该第二证书包含第一公钥。

第三管理器获得第三证书时，可以基于第三证书中的授权记录向其管理域下的应用服务器颁发第二证书。其中，第二证书包括第三管理器的使用第一公钥的数字签名以及应用服务器使用的第四公钥。例如，第二证书可以理解为EE证书。

本申请中，客户端可以通过第三证书验证第二证书是否可信，具体的，如果第二证书中第三管理器数字签名使用的公钥为第三证书中的第一公钥，则第二证书具有真实性。

例如，应用服务器向第三管理器申请证书时，第三管理器可以生成第二证书并发送给应用服务器。

由于本申请中设置了第三管理器，该第三管理器用于向其管理域下的应用服务器颁发证书，与现有的中间CA管理器任意向应用服务器发证书相比，可以进一步保障证书颁发的安全性，还可以减轻中间CA管理器向应用服务器颁发的证书的数量，便于管理应用服务器。

可选的，步骤305，第三管理器向应用服务器发送第一证书、第三证书以及第二证书。

例如，如果客户端请求访问应用服务器，或者，也可以理解为，客户端请求获取应用服务器的授权证书链时。应用服务器向第三管理器申请证书，第三管理器可以向第二管理器申请证书，第二管理器向第一管理器申请证书，后续，第一管理器向区块链系统发送第一证书，第二管理器向第三管理器发送第一证书和第三证书，第三管理向应用服务器发送第一证书、第三证书、第二证书。应用服务器向客户端发送授权证书链，即，应用服务器向客户端发送第一证书、第三证书以及第二证书。由于客户端本地预置有可信的根证书库，因此，可以通过预置的可信根证书库中验证根证书是否可信，如果根证书可信，则可以通过根证书验证第一证书，然后根据第一证书验证第三证书，并且根据第三证书验证第二证书，如果第一证书～第三证书都通过验证，则证明该应用服务器出示的授权证书链为可信的，客户端可以访问该应用服务器。

基于上述技术方案，本申请提供了一种网络中授权证书生成、认证方法，本申请在CAPKI系统中引入区块链系统，该区块链系统包括至少一个第二管理器和至少一个第三管理器，其中，第三管理器用于为其管理域下的应用服务器颁发证书，由于第二管理器向第三管理器颁发证书的行为都记录在区块链，从而实现证书颁发行为的透明化和不可篡改性。并且，由于设置了第三管理器，该第三管理器用于向其管理域下的应用服务器颁发证书，与现有的中间CA管理器任意向应用服务器发证书相比，可以进一步保障证书颁发的安全性，还可以减轻负载，便于管理应用服务器。

图4是本申请提供的网络中授权证书生成、认证方法具体实现方式的示意图，如图4所示，该架构包括根CA管理器(第一管理器的示例)、区块链系统、应用服务器、客户端。其中，区块链系统包括至少一个中间CA管理器(第二管理器的示例)、至少一个端域CA管理器(第三管理器的示例)。下面对该架构中涉及的各个模块进行详细的介绍。

(1)根CA管理器：如前所述，传统的根CA管理器签发的是对下级中间CA管理器的公钥的授信证书。而本方案中，根CA管理器签发的是区块链系统的第一区块的块头(“块头”也可以称为“链头”)的SBH证书(第一证书的示例)。应理解，根CA管理器也会出示根证书，颁发者和使用者均为根CA管理器，根CA管理器的公钥为key1，并且该证书是由根CA管理器签名的。

如图4所示，可信的根CA管理器可以用自己的公钥签名并颁发签发SBH，SBH中包含授权所在区块链系统的块头的哈希值(记为，第一哈希值)。SBH证书的颁发者为根CA管理器，SBH证书的使用者为区块链系统，根CA管理器的公钥为key1，假设区块链系统的第一区块的块头的哈希为“adfvrwop”。

(2)中间CA管理器：区块链系统的节点，所有中间CA管理器之间通过区块链系统共同维护了透明公开的、不可篡改的全局账本(该账本也可以理解为“授权记录”或者，称为“授权事务记录”)，账本中记录了所有中间CA管理器对端域CA管理器的颁发的授权证书的记录以及授权内容本身。由于，每个端域CA管理器可以管理众多应用服务器，因此，与中间CA管理器直接向应用服务器颁发证书相比，可以减少中间CA管理器授权证书的颁发数量，减轻中间CA向应用服务器颁发授权证书的负载。并且，现有的方案中，中间CA管理器颁发的是对下级中继CA管理器的公钥授权证书或者EE证书的公钥授权证书。然而，在本方案中，中间CA管理器可以向端域CA管理器颁发证书，并且通过“智能合约”实现的证书的颁发。

如图4所示，假设中间CA管理器#1向端域CA管理器#1颁发了证书，则授权记录中记载了：颁发者为中间CA管理器#1，中间CA管理器#1的公钥为key2，使用者为端域CA管理器#1，端域CA管理器#1的公钥为key3。

(3)端域CA管理器：本申请中，新增了端域CA管理器，端域CA管理器可以用于为其管理域的应用服务器颁发EE证书。也可以理解为，端域CA管理器本质也是一种中间CA管理器，但其只能为其管理域内的应用服务器颁发证书。也可以理解为，本申请中，基于透明化的区块链系统，端域CA管理器可以参与到授权证书颁发的监督过程中，端域CA管理器可以监视所有的授权记录，中间CA管理器向端域CA管理器的授权，只有该端域CA管理器签名同意，才能生效写进授权记录中。本申请中，可以基于不可篡改的数据结构merkle tree来公示中间CA管理器向端域CA管理器授权的行为(即，授权记录)(包括证书的“颁发”和“撤销”)，所有中间CA管理器的证书授权行为都在可信的根CA管理器授权的公开账本上进行交易。

端域CA管理器可以生成INPRF(第三证书的示例)，INPFR中包含授权记录，以及该授权记录在区块链系统中的哈希路径(merkle path)和区块链系统的第一区块的块头。由于，端域CA管理器可以实时监督区块链系统中的授权记录，从而可以确保INPRF的实时有效性。因此，本申请提供的授权证书的生成方法，使得客户端无需额外再查验INPRF的授权是否过期，在访问应用服务器时可以减少认证时延，提高用户的业务体验。

如图4所示，例如，d1～d8均可以理解为是授权记录的具体内容，a～h是分别是授权记录的哈希，例如，c是授权记录d3的哈希。对于授权记录d3而言，哈希路径为：[d，i，n]。由该哈希路径和授权记录，可以计算出一个哈希树树根mklroot＝H(m＝H(j＝H(c，d)，i)，n)。图4中示出的INPRF证书中的“授权记录”可以理解是d3的授权记录的具体内容。

应理解，客户端可以通过INPRF证书中的第一区块的块头直接获得区块链系统的第一区块块体哈希树树根的值(记作，第一值)，客户端也可以通过哈希路径和授权记录确定区块链系统的第一区块块体哈希树树根(记作，第二值)。后续客户端可以将INPRF证书中的第一区块的块头整体做哈希运算得到一个哈希值，并与SBH中区块链系统的第一区块的块头的第一哈希值比较。如果两个哈希值相同，并且第一值与第二值相同，则确定INPRF是可信的。需要说明的是，本申请中，INPRF中第一区块的块头至少包括：第一区块的前一个区块的块头的哈希值和第一区块的块体的哈希树树根。例如，INPRF中第一区块的块头还可以包括时间戳信息等等。

本申请中，端域CA管理器可以向其管理域的用于服务器颁发EE证书。假设端域CA#1管理器可以向应用应用服务器#～应用服务器#10颁发EE证书。假设，端域CA管理器#1向应用服务器#4颁发EE证书，如图4所示，EE证书的颁发者为端域CA管理器#1，EE证书的使用者为应用服务器#1，其中，端域CA管理器#1的公钥为key3，应用服务器#1的公钥为key4，并且，该EE证书是端域CA管理器#1使用其公钥签名的。

(4)客户端：本申请中，客户端可以向应用服务器(或者，对端peer)发起访问请求，并且可以收到应用服务器(或者，对端peer)响应的完整的证据链。例如，客户端可以通过预置的可信的根证书库验证签名和对应内容是否形成完整的授信链条，若通过客户端的验证则可以访问该应用服务器。本申请中，客户端也可以在发起访问请求时强制要求应用服务器出示的EE证书里嵌入客户端发送的随机数，从而证明端域CA管理器颁发的EE是实时有效的。

(5)应用服务器：本申请中，在客户端访问应用服务器时，应用服务器可以出示完整的授信链证据。如果客户端强制要求证明EE证书的实时有效性，应用服务器还可以响应客户端发来的随机数挑战请求，后面会详细描述随机数挑战机制。

图5是本申请提出的客户端验证授权证书的示意性流程图，图5示出了客户端验证授权证书链的流程，下面主要介绍本申请中提出的客户端验证授权证书的验证方法，该方法包括：

步骤一，客户端向服务器发送访问请求消息，该访问请求消息用于请求获取应用服务器的授权证书链。对应的服务器接收来自客户端的访问请求消息。

本申请中，例如，该服务器器例如可以是递归服务器。在一种可能的实现方式中，该递归服务器可以位于区块链系统中，该递归服务器可以不用于颁发授权证书，只用于监控区块链系统中的授权记录并且同步保存区块链系统中各个端域CA管理器颁发的授权证书。例如，递归服务器可以保存第一证书～第二证书。又例如，该服务器可以是域名系统(domain name system，DNS)服务器。

步骤二，服务器向客户端发送访问响应消息，访问响应消息携带第一证书、第三证书以及第二证书。对应的客户端接收来自服务器的访问响应消息。

在一种可能的实现方式中，递归服务器将同步保存的第一证书～第三证书发送给客户端。

在另一种可能的实现方式中，DNS服务器接收到客户端的访问请求消息后，向端域CA管理器申请EE证书，端域CA管理器向中间CA管理器申请授权证书，中间CA向根CA管理器申请授权证书，之后，DNS服务器接收第一证书～第三证书。

步骤三，客户端验证授权证书链。

示例性的，客户端的验证授权证书链的流程如图5所示。例如，(1)客户端可以验证应用服务器出示的根证书是否在本地的可信根库中，若“否”则认证不成功，若“是”则继续(2)；(2)客户端验证SBH证书是否是根证书里的使用者公钥key1签名的，若“否”则认证不成功，若“是”则继续(3)；(3)INPRF中的第一区块的块头的哈希值(记为“第二哈希值”)是否和SBH中的第一区块的块头的第一哈希值相同，若“否”则认证不成功，若“是”则继续(4)；(4)INPRF中的授权记录和哈希路径计算得到merkle root的是否和INPRF中第一区块的块头中的merkle root相同，若“否”则认证不成功，若“是”则继续(5)；(5)EE证书是否是INPRF中的授权记录中的使用者的公钥key3签名的，若“否”则认证不成功，若“是”则认证成功。如果客户端验证成功则访问该应用服务器，如果客户端验证不成功则拒绝访问该应用服务器。

需要说明的是，本申请中，客户端在验证授权证书时，可以先验证SBH再验证INPRF证书，最后验证EE证书，或者客户端先验证INPRF再验证SBH证书最后验证EE证书，等等，不予限定。换句话说，图5示出的验证证书的流程仅仅是示意性的，本申请并不限定验证证书时的先后顺序。

通常情况下，客户端在访问应用服务器时需要进行“域名解析”、“验证授权证书链”以及“授权证书是否是实时有效的”，最后才能成功“访问应用服务器”。其中，“域名解析”是指将域名解析为互联网协议(internet protocaol，IP)地址。通常情况下，客户端访问网站都是访问域名的，将域名转换为IP地址即可以理解为域名解析。如前所述，“验证授权证书链”的过程，即客户端验证授权证书是否是可信的。最后，客户端还需要验证“授权证书是否是实时有效的”，例如，应用服务器出示的EE证书是否已经被撤销。

本申请中，在一种可能的实现方式中，“域名解析”、“验证授权证书链”可以合并，即，客户端向服务器发送访问请求消息时，该访问请求消息在请求获取授权证书链还用于请求获取应用服务器的IP地址。示例性的，如果客户端有缓存该递归服务器的IP地址和应用服务器的EE证书则可以直接访问该应用服务器；如果客户端没有缓存该应用服务器的IP地址和公钥，则递归服务器可以向区块链系统获取完整的授权证书链，客户端进行验证。例如，客户端可以向递归服务器发送访问请求消息，该访问请求消息用于获取应用服务器的授权证书链以及应用服务器的IP地址。如前所述，授权证书层级授权的过程为：根CA管理器签名授权区块链系统，生成SBH证书；中间CA管理器向端域CA管理器授权，使得端域CA管理器可以向其管理域下的应用服务器颁发授权证书，并且生成授权记录；端域CA管理器生成含有授权记录的INPRF证书；端域CA管理器签名生成对应用服务器的授权证书。

由上可以看出，对于需要名称解析和认证的应用，与现有技术中“域名解析”—“验证授权证书链”—“授权证书是否是实时有效的”—“访问应用服务器”相比，本申请提出的技术方案可合并成“可信解析域名”—“访问应用服务器”。

本申请中提出的客户端可以向递归服务器查询应用服务器对应的IP地址和公钥，这种方式只需要客户端向递归服务器查询一次，并且一次查询过程既解析了应用服务器的域名对应的IP地址，又完成了授权证书链的验证。与现有技术中，客户端访问应用服务时需要发送两次相比请求消息，先向应用服务器请求获取其IP地址，再向应用服务器请求获取应用服务器的授权证书链相比，本申请中，整体上，客户端只需要一次查询请求便可以验证可信身份，接着进行可信访问，避免了多次发送请求消息暴露客户端隐私的问题，并且访问时延短，提高了用户的业务体验以及访问安全性。

在另一种可能的实现方式中，“域名解析”、“验证授权证书链”两个过程也可以分开进行。示例性的，客户端可以先向DNS服务器发送域名解析请求消息，该域名解析请求消息用于请求获取应用服务器的IP地址，DNF服务器向客户端发送域名解析响应消息，该域名解析响应消息携带所述应用服务器的IP地址。然后，客户端向应用服务器发送访问请求消息，该访问请求消息包括随机数，应用服务器收到客户端访问请求后向端域CA管理器申请EE证书。如前所述，授权证书层级授权的过程为：根CA管理器签名授权区块链系统，生成SBH证书；中间CA管理器向端域CA管理器授权，使得端域CA管理器可以向其管理域下的应用服务器颁发授权证书，并且生成授权记录；端域CA管理器生成含有授权记录的INPRF证书‘’端域CA管理器签名生成对应用服务器的授权证书。需要强调的是，本示例中，端域CA管理器向应用服务器颁发的证书，为实时签名的，该EE证书携带有随机数，同时端域CA管理器可以把整个授权证书链下发给应用服务器，最后应用服务器出示给客户端供客户端验证授权证书链。

本申请中，可以通过随机数挑战，应用服务器向客户端出示实时有效的EE证书，从而可以避免应用服务器出示的EE证书实际上已经被撤销了，提高了用户的业务体验以及访问安全性。并且，基于本申请提供的技术方案，由于第三管理实时监督区块链系统中的授权记录可以确保第三证书的实时有效性，并且通过“随机数挑战模式”也可以确保第二证书的实时有效性，从而使得客户端可以省去的授权证书有效性检查过程，减少访问认证的时延，提高了用户的业务体验。同时，由于减少可客户端与管理器之间信息交互检查授权证书的有效性，还可以避免多次发送请求消息暴露客户端隐私的问题，使得客户端可以更加安全的与应用服务器进行通信。

可以理解，本申请实施例中的各个方法仅仅是为了便于本领域技术人员理解本申请实施例，并非要将本申请实施例限于例示的具体场景。本领域技术人员根据方法中的例子，显然可以进行各种等价的修改或变化，这样的修改或变化也落入本申请实施例的范围内。

还可以理解，本申请的各实施例中的一些可选的特征，在某些场景下，可以不依赖于其他特征，也可以在某些场景下，与其他特征进行结合，不作限定。

还可以理解，本申请中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。并且实施例中出现的各个术语的解释或说明可以在各个实施例中互相参考或解释，对此不作限定。

可以理解，在本申请中，“在…情况下”、“若”以及“如果”均指在某种客观情况下装置会做出相应的处理，并非是限定时间，且也不要求装置实现时一定要有判断的动作，也不意味着存在其它限定。

本申请还提供一种网络中授权证书生成的系统，该系统包括：第一管理器、区块链系统，其中，区块链系统包括至少一个管理器。

第二管理器用于基于第一证书向第三管理器进行授权，并生成授权记录，所述授权记录用于表示所述第二管理器授权所述第三管理器，使得所述第三管理器向所述第三管理器管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，其中，所述第一证书为第一管理器授权区块链系统中的任意两个管理器之间进行授权的授权证书，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器；所述第三管理器用于基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，所述第二证书为所述第三管理器器向所述应用服务器签发的授权证书，所述第二证书包含所述第一公钥。

在一种可能的实现方式中，第三管理器还用于向应用服务器发送第一证书、第三证书以及第二证书。

在一种可能的实现方式中，第一管理器为根证书授权机构管理器，第二管理器为中间证书授权机构管理器，第三管理器为端域授权证书管理器。

图6和图7为本申请的实施例提供的网络中授权证书生成设备、网络中授权证书认证设备的结构示意图。该设备可以用于实现上述方法实施例中第一管理器，或者第二管理器，或者第三管理器的功能，该设备也可以用于实现上述方法实施例中客户端的功能，因此，也能实现上述网络中授权证书生成方法、网络中授权证书认证方法实施例所具备的有益效果。

如图6所示，设备100包括处理单元110和收发单元120。在一种可能的实现方式中，设备100用于实现上述所示的网络中授权证书生成方法实施例中第一管理器，或者第二管理器，或者第三管理器的功能。在另一种可能的实现方式中，设备100用于实现上述所示的网络中授权证书认证方法实施例中客户端的功能。

如图7中示出的设备200，该设备200包括：存储器210、处理器220以及输入输出接口230。其中，该处理器220可以与输入输出接口230通信连接。该存储器210可以用于存储获数据预取装置200的程序代码和数据。因此，该存储器210可以是处理器220内部的存储单元，也可以是与处理器220独立的外部存储单元，还可以是包括处理器220内部的存储单元和与处理器220独立的外部存储单元的部件。

可选的，该设备200还可以包括总线240。其中，存储器210、输入输出接口230可以通过总线240与处理器220连接。总线240可以是外设部件互连标准(peripheral componentinterconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。所述总线240可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

举例说明，处理器220例如可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(fieldprogrammable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。

输入输出接口230可以是包括上述天线和发射机链和接收机链的电路，二者可以是独立的电路，也可以是同一个电路。

当存储器210中存储的程序代码和数据被执行时，在一一种可能的实现方式中，所述处理器220用于执行第一管理器执行的方法，或者处理器220用于执行第二管理器执行的方法，或者处理器220用于执行第三管理器执行的方法。在另一种可能的实现方式中，所述处理器220用于执行网络中授权证书认证方法实施例中客户端执行的方法。

一种实现举例，处理器可以为中央处理单元(central processing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

一种实现举例，存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasablePROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的随机存取存储器(random access memory，RAM)可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhancedSDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

本申请实施例还提供一种芯片，该芯片获取指令并执行该指令来实现上述网络中授权证书生成方法中第一管理器，或者第二管理器，或者第三管理器执行的方法，或者该指令用于实现上述各个管理器对应的功能。

可选地，作为一种实现方式，该芯片包括处理器与数据接口，该处理器通过该数据接口读取存储器上存储的指令，执行上述网络中授权证书生成方法。

可选地，作为一种实现方式，该芯片还可以包括存储器，该存储器中存储有指令，该处理器用于执行该存储器上存储的指令，当该指令被执行时，该处理器用于执行上述网络中授权证书生成方法中第一管理器，或者第二管理器，或者第三管理器执行的方法。

本申请实施例还提供一种芯片，该芯片获取指令并执行该指令来实现上述网络中授权证书生认证方法中客户端执行的方法，或者该指令用于实现上述各个客户端对应的功能。

可选地，作为一种实现方式，该芯片包括处理器与数据接口，该处理器通过该数据接口读取存储器上存储的指令，执行上述网络中授权证书生认证方法。

可选地，作为一种实现方式，该芯片还可以包括存储器，该存储器中存储有指令，该处理器用于执行该存储器上存储的指令，当该指令被执行时，该处理器用于执行上述网络中授权证书生认证方法中客户端执行的方法。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有指令，该指令用于执行上述方法实施例中的网络中授权证书生成方法执行的方法，或者该指令用于实现上述的第一管理器，或者第二管理器，或者第三管理器对应的功能。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有指令，该指令用于执行上述方法实施例中的网络中授权证书认证方法执行的方法，或者该指令用于实现上述的第一管理器，或者第二管理器，或者第三管理器对应的功能。

本申请实施例还提供一种包含指令的计算机程序产品，该指令用于实现上述方法实施例中的网络中授权证书生成方法中客户端执行的方法，或者该指令用于实现上述的客户端对应的功能。

第十四方面，提供一种授权证书认证的系统，该系统包括上述实施例中网络中授权证书生成的设备，以及网络中授权证书认证的设备。在一种可能的实现方式中，该系统还包括应用服务器。

本申请的实施例中的方法步骤可以在硬件中实现，也可以在可由处理器执行的软件指令中实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器、闪存、只读存储器、可编程只读存储器、可擦除可编程只读存储器、电可擦除可编程只读存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于基站或终端中。处理器和存储介质也可以作为分立组件存在于基站或终端中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机程序或指令。在计算机上加载和执行所述计算机程序或指令时，全部或部分地执行本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、网络设备、用户设备或者其它可编程装置。所述计算机程序或指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机程序或指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是集成一个或多个可用介质的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，例如，软盘、硬盘、磁带；也可以是光介质，例如，数字视频光盘；还可以是半导体介质，例如，固态硬盘。该计算机可读存储介质可以是易失性或非易失性存储介质，或可包括易失性和非易失性两种类型的存储介质。

在本申请的各个实施例中，如果没有特殊说明以及逻辑冲突，不同的实施例之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例中的技术特征根据其内在的逻辑关系可以组合形成新的实施例。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定。

Claims (28)

1.一种网络中授权证书的生成的方法，其特征在于，包括：

第二管理器基于第一证书向第三管理器进行授权，并生成授权记录，所述授权记录用于表示所述授权记录用于表示所述第二管理器授权所述第三管理器向第三管理器所管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，

其中，所述第一证书为第一管理器授权区块链系统中的任意两个管理器之间进行授权的授权证书，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器；

所述第三管理器基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，所述第二证书为所述第三管理器器向所述应用服务器签发的授权证书，所述第二证书包含所述第一公钥。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一管理器向所述区块链系统中的任意一个管理器发送所述第一证书。

3.根据权利要求1或2所述的方法，其特征在于，所述第一证书包括所述区块链系统的第一区块的块头的第一哈希值，所述方法还包括：

所述第三管理器生成第三证书，所述第三证书包括所述授权记录、所述授权记录在所述区块链系统中对应的哈希路径以及所述区块链系统的第一区块的块头，

其中，所述第一哈希值、所述授权记录、所述哈希路径以及所述第三证书中的所述第一区块的块头用于验证所述第三证书的真实性。

4.根据权利要求3所述的方法，其特征在于，所述第三证书中的所述第一区块的块头至少包括第一值，所述第一值为所述区块链系统的所述第一区块的块体的哈希树树根的值，

所述第一哈希值、所述授权记录、所述哈希路径以及所述第三证书中的所述第一区块的块头用于验证所述第三证书的真实性，具体包括：

所述授权记录和所述哈希路径用于确定第二值，所述第二值为所述区块链系统的所述第一区块的块体的哈希树树根的值；

所述第三证书中的所述第一区块的块头用于确定第二哈希值；

如果所述第二值与所述第一值相同，并且，所述第二哈希值与所述第一哈希值相同，则所述第三证书具有真实性。

5.根据权利要求3或4所述的方法，其特征在于，所述第三管理器基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，包括：

所述第三管理器基于所述授权记录和所述第一公钥生成所述第二证书；

其中，所述第三证书用于验证所述第二证书的真实性。

6.根据权利要求5所述的方法，其特征在于，所述第三证书用于验证所述第二证书的真实性，具体包括：

如果所述第二证书中所述第三管理器使用的公钥为所述第一公钥，则第二证书具有真实性。

7.根据权利要求5或6所述的方法，其特征在于，所述方法还包括：

所述第三管理器向所述应用服务器发送所述第一证书、所述第三证书以及所述第二证书。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述第一管理器为根证书授权机构管理器，所述第二管理器为中间证书授权机构管理器，所述第三管理器为端域授权证书管理器。

9.一种网络中授权证书认证的方法，其特征在于，包括：

客户端向服务器发送访问请求消息，所述访问请求消息用于请求获取应用服务器的授权证书链；

所述客户端接收来自所述服务器的访问响应消息，所述访问响应消息携带第一证书、第三证书以及第二证书，其中，

所述第一证书是第一管理器生成的，所述第一证书为所述第一管理器授权所述区块链系统中的任意两个管理器之间进行授权的授权证书，所述区块链系统包括至少一个管理器；

所述第三证书是第三管理器生成的，所述第三证书包含授权记录，所述授权记录是第二管理器基于所述第一证书向所述第三管理器授权生成的记录，所述授权记录用于表示所述第二管理器授权所述第三管理器向第三管理器所管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，其中，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器，

所述第二证书是所述第三管理器基于所述授权记录和所述第一公钥向所述应用服务器签发授权证书，所述第二证书包含所述第一公钥；

所述客户端根据所述第一证书和所述授权记录验证所述第三证书的真实性；

所述客户端根据所述第三证书验证所述第二证书的真实性。

10.根据权利要求9所述的方法，其特征在于，所述第一证书是所述第一管理器向所述区块链系统中的任意一个管理器发送的授权证书。

11.根据权利要求9或10所述的方法，其特征在于，所述第一证书包括所述区块链系统的第一区块的块头的第一哈希值，所述第三证书包括所述授权记录、所述授权记录在所述区块链系统中对应的哈希路径以及所述区块链系统的第一区块的块头，所述第三证书中的所述第一区块的块头至少包括第一值，所述第一值为所述区块链系统的第一区块的块体的哈希树树根的值，

所述客户端根据所述第一证书和所述授权记录验证所述第三证书的真实性，包括：

所述客户端根据所述授权记录和所述哈希路径确定第二值，所述第二值为所述区块链系统的第一区块的块体的哈希树树根的值；

所述客户端根据所述第三证书中的所述第一区块的块头确定第二哈希值；

如果所述客户端确定所述第二值与所述第一值相同，并且，确定所述第二哈希值与所述第一哈希值相同，则所述客户端确定所述第三证书具有真实性。

12.根据权利要求9至11中任一项所述的方法，其特征在于，所述客户端根据所述第三证书验证所述第二证书的真实性，包括：

所述客户端确定所述第二证书中所述第三管理器使用的公钥为所述第一公钥，则所述客户端确定所述第二证书具有真实性。

13.根据权利要求9至13中任一项所述的方法，其特征在于，所述第一管理器为根证书授权机构管理器，所述第二管理器为中间证书授权机构管理器，所述第三管理器为端域授权证书管理器。

14.根据权利要求13所述的方法，其特征在于，在所述访问请求消息还用于请求获取所述应用服务器的互联网协议地址的情况下，所述第二证书还包括所述应用服务器的互联网协议地址，所述服务器为递归服务器，所述递归服务器用于实时缓存所述区块链系统中的所述第一证书、所述第三证书和所述第二证书。

15.根据权利要求13所述的方法，其特征在于，所述服务器为应用服务器，在所述客户端向服务器发送访问请求消息之前，所述方法还包括：

所述客户端向域名系统DNS服务器发送域名解析请求消息，所述域名解析请求用于请求获取所述应用服务器的互联网协议地址；

所述客户端接收来自所述DNS服务器的域名解析响应消息，所述域名解析响应消息携带所述应用服务器的互联网协议地址。

16.根据权利要求15所述的方法，其特征在于，若所述访问请求消息携带第一随机数，则所述第二证书还包括所述第一随机数，所述第二证书为所述第三管理器通过所述第一公钥实时签名生成的。

17.一种网络中授权证书生成的系统，其特征在于，包括：第一管理器、区块链系统，其中，所述区块链系统包括至少一个管理器，

第二管理器用于基于第一证书向第三管理器进行授权，并生成授权记录，所述授权记录用于表示所述第二管理器授权所述第三管理器向第三管理器所管理的应用服务器签发证书，所述授权记录包含第一公钥，所述第一公钥为所述第三管理器的公钥，所述授权记录保存在所述区块链系统中的每个管理器中，

其中，所述第一证书为第一管理器授权区块链系统中的任意两个管理器之间进行授权的授权证书，所述第二管理器为所述区块链系统中的一个管理器，所述第三管理器为所述区块链系统中的另一个管理器；

所述第三管理器用于基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，所述第二证书为所述第三管理器器向所述应用服务器签发的授权证书，所述第二证书包含所述第一公钥。

18.根据权利要求17所述的系统，其特征在于，所述第一管理器还用于向所述区块链系统中的任意一个管理器发送所述第一证书。

19.根据权利要求17或18所述的系统，其特征在于，所述第一证书包括所述区块链系统的第一区块的块头的第一哈希值，

所述第三管理器用于生成第三证书，所述第三证书包括所述授权记录、所述授权记录在所述区块链系统中对应的哈希路径以及所述区块链系统的第一区块的块头，

其中，所述第一哈希值、所述授权记录、所述哈希路径以及所述第三证书中的所述第一区块的块头用于验证所述第三证书的真实性。

20.根据权利要求19所述的系统，其特征在于，所述第三证书中的所述第一区块的块头至少包括第一值，所述第一值为所述区块链系统的第一区块的块体的哈希树树根的值，

所述第一哈希值、所述授权记录、所述哈希路径以及所述第三证书中的所述第一区块的块头用于验证所述第三证书的真实性，具体包括：

所述授权记录和所述哈希路径用于确定第二值，所述第二值为所述区块链系统的第一区块的块体的哈希树树根的值；

所述第三证书中的所述第一区块的块头用于确定第二哈希值；

如果所述第二值与所述第一值相同，并且，所述第二哈希值与所述第一哈希值相同，则所述第三证书具有真实性。

21.根据权利要求17至20中任一项所述的系统，其特征在于，所述第三管理器用于基于所述授权记录和所述第一公钥向所述应用服务器签发第二证书，包括：

所述第三管理器还用于基于所述授权记录和所述第一公钥生成第二证书，所述第二证书为所述第三管理器向所述应用服务器颁发的证书；

其中，所述第三证书用于验证所述第二证书的真实性。

22.根据权利要求21所述的系统，其特征在于，所述第三证书用于验证所述第二证书的真实性，具体包括：

如果所述第二证书中所述第三管理器使用的公钥为所述第一公钥，则第二证书具有真实性。

23.根据权利要求21或22所述的系统，其特征在于，

所述第三管理器还用于向所述应用服务器发送所述第一证书、所述第三证书以及所述第二证书。

24.根据权利要求17至23中任一项所述的系统，其特征在于，所述第一管理器为根证书授权机构管理器，所述第二管理器为中间证书授权机构管理器，所述第三管理器为端域授权证书管理器。

25.一种网络中授权证书认证的设备，其特征在于，包括客户端，所述客户端用于执行权利要求9至16中任一项所述的方法。

26.一种网络中授权证书认证的设备，其特征在于，包括处理器和存储器；所述处理器运行所述存储器中的指令，使得所述处理器执行如权利要求9至16中任一项所述的方法。

27.一种网络中授权证书认证的系统，其特征在于，包括权利要求17至24中任一项所述的网络中授权证书生成的系统，以及，权利要求25或者权利要求26中所述的设备。

28.根据权利要求27中所述的系统，其特征在于，所述系统还包括应用服务器。