CN113301016A - 实现https双向验证的方法、装置及*** - Google Patents

实现https双向验证的方法、装置及*** Download PDF

Info

Publication number
CN113301016A
CN113301016A CN202110411975.3A CN202110411975A CN113301016A CN 113301016 A CN113301016 A CN 113301016A CN 202110411975 A CN202110411975 A CN 202110411975A CN 113301016 A CN113301016 A CN 113301016A
Authority
CN
China
Prior art keywords
server
https
certificate
task
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110411975.3A
Other languages
English (en)
Inventor
王斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Aisino Corp
Original Assignee
Aisino Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aisino Corp filed Critical Aisino Corp
Priority to CN202110411975.3A priority Critical patent/CN113301016A/zh
Publication of CN113301016A publication Critical patent/CN113301016A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036—Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明公开了实现https双向验证的方法、装置和***。该方法包括：在验证网站身份的合法性时，https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。该方法中，在任一服务器出现了证书有关的故障时，将其与客户端的连接切换到其它的任一个正常服务器，提高了网页服务的可靠性，提升了用户体验。

Description

实现https双向验证的方法、装置及***
技术领域
本发明属于互联网应用技术领域，具体涉及实现https双向验证的方法、装置及***。
背景技术
服务器与客户端之间的常规认证为单向认证。单向认证时，服务器与客户端之间传输的是加密后的数据。但是单向认证这种方式很容易被仿冒，如第三方恶意软件在传输过程中截取数据，向服务器仿冒客户端，向客户端仿冒服务器，就可以拿到传输的明文数据。
因此针对安全性要求比较高的业务，如金融、支付等，就必须提高安全性，这时，服务器与客户端之间采用https双向认证。
目前，服务器与客户端之间在实现双向认证时，认证手续繁琐，认证效率低。
发明内容
针对现有技术的不足，本发明提供实现https双向验证的方法、装置及***，以简化认证手续并提高认证效率。
第一方面，本发明提供一种实现https双向验证的方法，包括：
在验证网站身份的合法性时，https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；
其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；
客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
具体地，所述的方法，还包括：
在与执行https任务的服务器协商对称加密密钥时，客户端根据服务器根级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥；或
在与执行https任务的服务器协商对称加密密钥时，客户端根据服务器二级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥。
具体地，所述的方法，
执行https任务的服务器有多个，其中，任一个执行https任务的服务器对应于服务器根级证书，其他执行https任务的服务器分别对应一个服务器二级证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
具体地，所述的方法，
执行https任务的服务器有多个，其中，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
具体地，所述的方法，
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
具体地，所述的方法，
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
在与正常执行https任务的服务器协商对称加密密钥时，
客户端根据服务器根级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥；或
客户端根据服务器二级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥。
具体地，所述的方法，
所述https任务由nigix协同PCRE安装包、OpenSSL安装包和ZLIB安装包实现。
第二方面，本发明提供一种实现https双向验证的装置，包括：
服务器证书发送模块，用于：在验证网站身份的合法性时，使得https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；
其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；
https任务合法性验证模块，用于使得客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
具体地，所述的装置，还包括：
对称密钥确定模块，用于在与执行https任务的服务器协商对称加密密钥时，使得客户端根据服务器根级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥；或
在与执行https任务的服务器协商对称加密密钥时，使得客户端根据服务器二级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥。
第三方面，本发明提供一种实现https双向验证的***，包括：
至少一个执行https任务的客户端，
多个执行https任务的服务器，其中，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
本发明实施例的实现https双向验证的方法、装置和***中，多个具有级联证书的服务器互为热备份。在任一服务器出现了证书有关的故障时，将其与客户端的连接切换到其它的任一个正常服务器，实现网站服务的无缝、透明切换，提高了网页服务的可靠性，提升了用户体验。
附图说明
通过参考下面的附图，可以更为完整地理解本发明的示例性实施方式：
图1为本发明优选实施方式的实现https双向验证的方法的流程图；
图2为本发明优选实施方式的实现https双向验证的装置的组成示意图；
图3为本发明优选实施方式的实现https双向验证的***的组成示意图。
具体实施方式
现在参考附图介绍本发明的示例性实施方式，然而，本发明可以用许多不同的形式来实施，并且不局限于此处描述的实施例，提供这些实施例是为了详尽地且完全地公开本发明，并且向所属技术领域的技术人员充分传达本发明的范围。对于表示在附图中的示例性实施方式中的术语并不是对本发明的限定。在附图中，相同的单元/元件使用相同的附图标记。
除非另有说明，此处使用的术语(包括科技术语)对所属技术领域的技术人员具有通常的理解含义。另外，可以理解的是，以通常使用的词典限定的术语，应当被理解为与其相关领域的语境具有一致的含义，而不应该被理解为理想化的或过于正式的意义。
公钥基础设施，Public Key Infrastructure，简称PKI。
证书签发机构，Certification Authority，简称CA。CA也可以指证书签发机构签发的证书。
验证证书合法，也即鉴别一个证书的真伪。具体地，使用该CA的公钥对证书的签名进行验证，一旦验证通过，该证书就被认为是有效/合法的。
大多数操作***/浏览器是默认安装了主流或常见的CA证书的，这些默认的CA证书由GoDaddy或VeriSign等知名的商业证书颁发机构颁发。
但是，如果操作***/浏览器/设备需要信任不知名的证书颁发机构，就需要安装该证书颁发机构的CA证书。
超文本传输协议(Hyper Text Transfer Protocol，简称http)是互联网上使用最广泛的一种协议。http协议传输的数据都是未加密的，也就是明文的，因此使用http协议传输隐私信息非常不安全。
安全的超文本传输协议(Hyper Text Transfer Protocol over Secure SocketLayer，简称https)使用安全套接层(Secure Sockets Layer，简称SSL)协议对原本经https协议传输的数据进行加密，来保证会话过程中的安全性。
SSL协议既用到了对称加密也用到了非对称加密(公钥加密)。在建立传输链路过程中，SSL将协商的用于对称加密的对称密钥使用公钥进行非对称加密；链路建立好之后，SSL对传输的数据进行对称加密。具体地，非对称加密，会用到公钥、私钥和证书；对称加密，只需要用到诸如随机数的对称密钥。
https双向认证除了客户端需要认证服务端以外，还包括服务端对客户端的认证。
具体地，https在建立Socket连接之前，客户端与服务端之间的双向认证过程包括：
(1)、服务端向客户端返回服务器CA，客户端使用服务端返回的服务器CA验证服务器的合法性，包括：
服务器证书是否过期；
发行服务器证书的CA是否可靠；
服务器返回的公钥是否能正确解开服务器证书中的数字签名；
服务器证书上的域名是否和服务器的实际域名相匹配；
验证通过后，将继续进行通信，否则，终止通信。
以上的场景，也即用户通过其终端设备中运行的浏览器中访问目标URL时，获取网站证书/服务器证书。
(2)、服务端要求客户端发送客户端证书，客户端将自己的证书发送至服务端；服务端验证客户端的证书，证书验证后，获得客户端公钥。
至此，服务端与客户端之间的身份验证完成，从而保证具有访问权限的客户端访问安全的服务端/网页/网站。
以下为数据传输用对称加密机制的协商步骤。
(1)、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择；
(2)、服务器端在客户端提供的加密方案中选择加密方式(如，选择加密程度最高的方案或选择加密速度最快的方案等)；
(3)、服务器端将选择的加密方案使用之前获取到的客户端公钥进行加密，得到加密方案密文，并返回给客户端；
(4)、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方案；
(5)、客户端产生与该加密方案对应的随机数，用作加密过程中的对称密钥，使用从服务端证书中获取到的服务端公钥进行加密后，发送给服务端；
(6)、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取该对称密钥；
至此，数据传输用对称加密机制协商结束，之后，按照协商确定的对称密钥、服务端公钥及客户端公钥进行会话/数据传输，即可保证通信过程中的信息安全。
C/S架构是第一种比较早的软件架构，主要用于局域网内。也叫客户机/服务器模式。
B/S结构(Browser/Server，浏览器/服务器模式)，是WEB兴起后的一种网络结构模式。WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将***功能实现的核心部分集中到服务器上，简化了***的开发、维护和使用。客户机上只要安装一个浏览器，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server同数据库进行数据交互。
https双向认证过程中，提供网页服务的每个服务器都需要有自己唯一的证书。本发明实施例实现https双向验证的方法通过CA级联证书模式使所有服务器的证书都对应同一个根证书。具体地，通过自签名的方式实现CA级联证书模式。这时，任一个client/服务器私钥签名不仅可以通过对应的client/服务器证书的公钥来验证，还可通过根证书的公钥进行验证。这样，在提供网页服务的任一个服务器崩溃/故障时，通过CA级联证书模式可以简化认证手续并提高认证效率，从而无缝、透明地由另一台服务器提供网页服务，改进用户体验。
具体地，由nigix协同PCRE安装包、OpenSSL安装包和ZLIB安装包生成一套CA根级证书，再借助该根级证书生成多个二级证书分别作为每个服务器的client证书。
如图1所示，本发明实施例的实现https双向验证的方法，包括：
步骤S110：在验证网站身份的合法性时，https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；
其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；
步骤S120：客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
步骤S130：客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
应该理解为，这里的客户端指向终端用户提供互联网业务的浏览器，运行在终端用户的移动终端或固定终端上。
需要说明的是，将客户端证书发送到服务器端，及在服务器端验证客户端证书采用现有技术中的方法，这里不再赘述。
具体地，所述的方法，还包括：
在与执行https任务的服务器协商对称加密密钥时，客户端根据服务器根级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥；或
在与执行https任务的服务器协商对称加密密钥时，客户端根据服务器二级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥。
具体地，所述的方法，
执行https任务的服务器有多个，其中，任一个执行https任务的服务器对应于服务器根级证书，其他执行https任务的服务器分别对应一个服务器二级证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
这时，多个具有级联证书的服务器互为热备份。在部署级联模式的证书时，将任一个执行https任务的服务器对应于服务器根级证书，其他执行https任务的服务器分别对应一个服务器二级证书。在任一服务器出现了证书有关的故障时，将其与客户端的连接切换到其它的任一个正常服务器，实现网站服务的无缝、透明切换，提高了网页服务的可靠性，提升了用户体验。
具体地，所述的方法，
执行https任务的服务器有多个，其中，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
这时，多个具有级联证书的服务器互为热备份。在部署级联模式的证书时，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书。在任一服务器出现了证书有关的故障时，将其与客户端的连接切换到其它的任一个正常服务器，实现网站服务的无缝、透明切换，提高了网页服务的可靠性，提升了用户体验。
应该理解为，还设置有服务器状态检测步骤和服务器切换步骤。其中，服务器状态检测步骤用于实时地检测提供网页服务的全部服务器的状态，其状态包括故障或正常。服务器切换步骤响应于服务器状态检测模块检测到的服务器状态，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
具体地，所述的方法，
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
具体地，所述的方法，
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
在与正常执行https任务的服务器协商对称加密密钥时，
客户端根据服务器根级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥；或
客户端根据服务器二级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥。
具体地，所述的方法，
所述https任务由nigix协同PCRE安装包、OpenSSL安装包和ZLIB安装包实现。
如图2所示，本发明实施例的实现https双向验证的装置，包括：
服务器证书发送模块210，用于：在验证网站身份的合法性时，使得https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；
其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；
https任务合法性验证模块220，用于使得客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
具体地，所述的装置，还包括：
对称密钥确定模块230，用于在与执行https任务的服务器协商对称加密密钥时，使得客户端根据服务器根级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥；或
在与执行https任务的服务器协商对称加密密钥时，使得客户端根据服务器二级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥。
如图3所示，本发明实施例的实现https双向验证的***，包括：
至少一个执行https任务的客户端310，
多个执行https任务的服务器320，其中，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上；
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证；
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
在与正常执行https任务的服务器协商对称加密密钥时，
客户端根据服务器根级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥；或
客户端根据服务器二级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥。
图3中，实线表示切换前的连接；虚线表示与该客户端连接的服务器故障后，该客户端可切换至的其他服务器。
本发明实施例的实现https双向验证的***中，多个具有级联证书的服务器互为热备份。在任一服务器出现了证书有关的故障时，将其与客户端的连接切换到其它的任一个正常服务器，实现网站服务的无缝、透明切换，提高了网页服务的可靠性，提升了用户体验。
Web服务器、网站服务器或网页服务器，是指驻留于因特网上某种类型计算机的程序，运行web页面需要的服务。如，可以处理浏览器等Web客户端的请求并返回相应响应；也可以放置网站文件，让全世界浏览；可以放置数据文件，让全世界下载。目前最主流的三个Web服务器是Apache、Nginx和IIS。
其中，Nginx功能上采用模块化结构设计，支持通用的语言接口，如Perl。Nginx支持SSL加密传输。Nginx作为Web服务器，可以处理静态文件、索引文件，自动索引的效率非常高。Nginx是专门为性能优化而开发的，实现上非常注重效率。它采用内核Poll模型，可以支持更多的并发连接，最大可以支持对5万个并发连接数的响应，而且只占用很低的内存资源。在稳定性方面，Nginx采取了分阶段资源分配技术，使得CPU与内存的占用率非常低。在高可用性方面，Nginx支持热部署，启动速度特别迅速，因此可以在不间断服务的情况下，对软件版本或者配置进行升级，即使运行数月也无需重新启动，几乎可以做到不间断地运行。
以下实施例中，以Nginx为例，说明实现https双向验证时的配置方法。以从官网下载的源码为例，该Nginx软件的版本为Nginx-1.9.0。
安装前准备
1)、准备安装包
从公开的网络资源分别获取PCRE安装包、OpenSSL安装包和ZLIB安装包。
其中，Perl兼容正则表达式库(Perl Compatible Regular Expressions，简称PCRE)是一个Perl库，也即Perl兼容的正则表达式库。
其中，OpenSSL是一个安全套接字层密码库，包括主流密码算法、常用密钥和证书封装管理功能及SSL协议。其作为一个开放源代码的软件库包提供丰富的应用程序供开发使用。OpenSSL应用程序使用OpenSSL安装包，广泛应用在网页服务器上，以进行安全通信，避免窃听，同时可以确认另一端连接者的身份。
其中，ZLIB是一个开放源代码的软件库包，提供数据压缩用的函式库(library)。
以下实施例中，这3个安装包的版本分别为pcre-8.36、openssl-1.0.2a、zlib-1.2.8。
在安装Nginx软件之前需要依次安装以上3个软件。如果确认操作***中已经包括上述软件，则不需要重复安装以上3个软件。
2)、安装PCER
具体地，采用以下命令行语句安装Perl兼容正则表达式库：
unzip"$CURRENT_PATH/$PCRE.zip"-d"$CURRENT_PATH"
cd"$CURRENT_PATH/$PCRE"
./configure
make
make install
3)、安装OpenSSL
具体地，采用以下命令行语句安装安全套接字层密码库：
tar-xvf"$CURRENT_PATH/$OpenSSL.tar.gz"-C"$CURRENT_PATH"
cd"$CURRENT_PATH/$OpenSSL"
./config shared--prefix＝/usr/local--openssldir＝/usr/local/ssl
make
make install
注：以上指定OpenSSL的安装目录为/usr/local，这时，OpenSSL的配置文件为/usr/local/ssl/目录下openssl.cnf。后续在创建CA根级证书步骤中需要使用到该OpenSSL配置文件。
该OpenSSL配置文件openssl.cnf中的很多设置不用修改就能直接使用；但是后续配置openssl相关事项是会使用到该文件。
4)、安装ZLIB
具体地，采用以下的语句安装数据压缩用函式库：
tar-xvf"$CURRENT_PATH/$ZLIB.tar.gz"-C"$CURRENT_PATH"
cd"$CURRENT_PATH/$ZLIB"
./configure
make
make install
5)、确认以上3个软件在操作***中安装成功之后，安装Nginx。
具体地，采用以下的语句：
tar-xvf"$CURRENT_PATH/$Nginx.tar.gz"-C"$CURRENT_PATH"
cd"$CURRENT_PATH/$Nginx"
./configure--prefix＝$Nginx_PATH--with-https_ssl_module
make
make install
注：在Nginx安装中，命令语句中必须要附加--with-https_ssl_module，用于设定SSL加密传输工作模式；如果在Nginx安装时，命令语句中没有附加--with-https_ssl_module，则Nginx安装成功之后无法配置https认证。
6)、OpenSSL目录配置准备
6.1)、配置OpenSSL需要的目录和文件
mkdir/etc/pki/ca_inorsight
cd/etc/pki/ca_inorsight
mkdir root server client newcerts
echo 01>serial
echo 01>crlnumber
touch index.txt
备注：Linux touch命令用于修改文件或者目录的时间属性，包括存取时间和更改时间。若文件不存在，***会建立一个新的文件。
6.2)、修改openssl配置
vi/usr/local/ssl/openssl.cnf
修改该文件内的如下参数：
dir＝/etc/pki/ca_inorsight
certificate＝$dir/root/ca.crt
private_key＝$dir/root/ca.key
备注：分别指定了证书文件和私钥文件的存储位置，用于存放CA根证书，证书数据库，以及为后续服务器生成的二级证书，密钥以及请求文件。
以下分别具体说明了CA根级证书和二级证书的生成方法。
7)、创建自建CA根级证书
7.1)、生成key：
openssl genrsa-out/etc/pki/ca_inorsight/root/ca.key
备注：用于用128位RSA算法生成RSA公/私密钥对，得到ca.key文件。RSA加密算法是一种被广泛使用的非对称加密算法。
7.2)、生成证书请求文件csr：
openssl req-new-key/etc/pki/ca_inorsight/root/ca.key-out/etc/pki/ca_inorsight/root/ca.csr
证书请求文件，Certificate Secure Request，简称CSR。
网站SSL证书可以用于证明网站的域名是安全可信的。在生成网站SSL证书时，CA机构要验证申请人的信息。因此，申请SSL证书的必要步骤之一是制作网站的CSR文件。制作网站的CSR文件需要以下信息：网站域名、运行/持有网站的公司名称、省份、城市、国家。
以上借助工具同时生成证书请求文件CSR和私钥文件ca.key。其中，证书请求文件，也即CSR文件和私钥文件这两个文件是相互匹配的，并保存在网站运行方/持有方。
7.3)、利用证书请求文件csr生成证书文件crt：
openssl x509-req-days 3650-in/etc/pki/ca_inorsight/root/ca.csr-signkey/etc/pki/ca_inorsight/root/ca.key-out/etc/pki/ca_inorsight/root/ca.crt
备注：伪命令x509可以像openssl ca一样对证书或请求执行签名动作。
随后，将证书请求文件CSR文件提交给CA来申请证书，CA根据CSR文件对申请人签发证书文件ca.crt。
申请人在收到证书文件后，将证书文件与私钥文件配合，生成或转化为与网站服务器对应的格式的文件，并部署在https服务器上。部署成功后，网站就成为了安全可信的网站。
公钥/私钥+额外的其他信息(比如所属的实体，采用的加密解密算法等)＝证书。
7.4)、生成crl：
openssl ca-gencrl-out/etc/pki/ca_inorsight/root/ca.crl-crldays 7
证书吊销列表，也即Certificate Revocation List，简称CRL，是PKI***中的一个结构化数据文件。该文件包含了证书颁发机构CA已经吊销的证书的序列号及其吊销日期。CRL文件中还包含证书颁发机构信息、吊销列表失效时间和下一次更新时间，以及采用的签名算法等。证书吊销列表最短的有效期为一个小时，一般为1天，甚至一个月不等，由各个证书颁发机构在设置其证书颁发***时设置。
如果一个证书的安全性曾经受到过威胁，那么这个证书就会被丢弃。也就是说，将其声明为无效。当一个证书被声明为无效时，CA不可能将其通知所有拥有该证书拷贝的人。相反，CA会发布一个证书撤销列表(CRL-Certificate Revocation/Abolishment List)。浏览器和其他使用数字证书的程序都可以验证这个证书已经被其属主或CA撤销了。
在证书验证时，会有个和CA的CRL通信：
a)如果CA服务器关闭了或者无法连接了，证书就有可能失效了；
b)如果是正常连接，但是CA服务器被Revoke,那么证书也会失效。
应该理解为以上步骤7.1)中生成的根级证书文件(包括私钥、证书和证书请求文件等)都保存在/etc/pki/ca_inorsight/root/目录下。
以上步骤中，配置了提供自签名CA的服务器，实现了自建CA；后续通过将自建CA导入浏览器来实现https。具体地，CA将自己的证书(公信凭证)交给浏览器厂商，由厂商将证书配置到各自浏览器。
网站将自己的证书交给CA，让CA使用私钥对证书进行签名，CA签名后发回给网站。在这个过程中，CA需要核实网站的真实性，网站发给CA签名的也不仅只是证书，其中网站证书(含网站URL)和网站公钥是必要的，还会包含一些其他信息一同签名。浏览器/用户向网站请求安全连接，网站把CA签名后的证书发给用户，浏览器会根据证书信息，检查是哪个CA做的签名，从浏览器自带的CA证书中找到对应公钥验证。如果验证通过，就证明了网站身份的合法性，浏览器/用户可以通过网站提供的公钥进行安全连接，和网站协商后续对称加密的密钥。
以上步骤生成了CA自签名根证书和RSA公/私密钥对。
8)、创建SERVER/client证书
8.1)、生成key：
openssl genrsa-des3-out/etc/pki/ca_inorsight/client/client.key 1024
备注：生成RSA公/私密钥对。
8.2)、生成csr：
openssl req-new-key/etc/pki/ca_inorsight/client/client.key-out/etc/pki/ca_inorsight/client/client.csr
备注：基于RSA公/私密钥对生成一个证书签名请求CSR文件；
8.3)、生成crt：
openssl ca-in/etc/pki/ca_inorsight/client/client.csr-cert/etc/pki/ca_inorsight/root/ca.crt-keyfile/etc/pki/ca_inorsight/root/ca.key-out/etc/pki/ca_inorsight/client/client.crt-days 3650
将该CSR文件发给在步骤7)中自建的CA服务器，注册一下。产生的client证书client.crt用于https服务器与CA服务器之间的认证。
重复步骤8)，可以创建多套二级client证书。这时，生成的多套二级client/服务器证书与步骤7)中自建的CA服务器的证书为级联证书。
因为是自建CA，所以服务器也是client。
说明：
a、-days参数可根据需要设置证书的有效期，这里默认为10年，也即3650天。
b、生成crt时可能会遇到如下报错：
openssl TXT_DB error number 2failed to update database
这时，可参照进行如下操作：将index.txt.attr中unique_subject＝no。在实际应用场景中，证书subject应该有所不同。
9)、配置Nginx
9.1)、配置Nginx.conf中，以下只列出需要配置的server段部分代码：
ssl_certificate/etc/pki/ca_inorsight/server/server.crt；#server公钥
ssl_certificate_key/etc/pki/ca_inorsight/server/server.key；#server私钥
ssl_client_certificate/etc/pki/ca_inorsight/root/ca.crt；#根级证书公钥，用于验证各个二级client
ssl_verify_client on；
9.2)、重启Nginx，使得以上配置生效。
至此，可以实现Nginx网站/网页/服务器的n:1认证模式。该n:1模式通过CA级联证书模式实现的。
以上步骤，首先生成一套CA根级证书，再借助该根级证书生成二级证书作为client证书。之后，利用client私钥生成的数字签名不仅可以通过对应的client公钥来验证，还可通过根证书的公钥进行验证。
本发明实施例的实现https双向验证的方法，在双向验证时，服务器必须检验客户端证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA是否可靠，发行CA的公钥能否正确解开客户端证书的发行CA的数字签名，检查客户的证书是否在证书废止列表CRL中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的预主密码，然后执行一系列步骤来产生主通讯密码，以及客户端也将通过同样的方法产生相同的主通讯密码。
本发明实施例的实现https双向验证的方法，保证了客户端和服务器端双向验证的安全性、有效性，简化了认证手续并提高了认证效率。
本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上已经通过参考少量实施方式描述了本发明。然而，本领域技术人员所公知的，正如附带的专利权利要求所限定的，除了本发明以上公开的其他的实施例等同地落在本发明的范围内。
通常地，在权利要求中使用的所有术语都根据他们在技术领域的通常含义被解释，除非在其中被另外明确地定义。所有的参考“一个//该[装置、组件等]”都被开放地解释为装置、组件等中的至少一个实例，除非另外明确地说明。这里公开的任何方法的步骤都没必要以公开的准确的顺序运行，除非明确地说明。

Claims (10)

1.一种实现https双向验证的方法，其特征在于，包括：
在验证网站身份的合法性时，https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；
其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；
客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
2.根据权利要求1所述的方法，其特征在于，还包括：
在与执行https任务的服务器协商对称加密密钥时，客户端根据服务器根级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥；或
在与执行https任务的服务器协商对称加密密钥时，客户端根据服务器二级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥。
3.根据权利要求1所述的方法，其特征在于，
执行https任务的服务器有多个，其中，任一个执行https任务的服务器对应于服务器根级证书，其他执行https任务的服务器分别对应一个服务器二级证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
4.根据权利要求1所述的方法，其特征在于，
执行https任务的服务器有多个，其中，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
5.根据权利要求3或4所述的方法，其特征在于，
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
6.根据权利要求3或4所述的方法，其特征在于，
在与客户端建立连接https任务切换到另一台正常执行https任务的服务器后，
正常执行https任务的服务器将服务器根级证书和/或与其对应的服务器二级证书发送至客户端；
在与正常执行https任务的服务器协商对称加密密钥时，
客户端根据服务器根级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥；或
客户端根据服务器二级证书的公钥，处理从https任务获取的加密后对称密钥，以确定https任务主张的对称密钥。
7.根据权利要求1所述的方法，其特征在于，
所述https任务由nigix协同PCRE安装包、OpenSSL安装包和ZLIB安装包实现。
8.一种实现https双向验证的装置，其特征在于，包括：
服务器证书发送模块，用于：在验证网站身份的合法性时，使得https任务响应于客户端发送的服务器证书请求，将服务器根级证书和/或服务器二级证书发送至客户端；
其中，服务器二级证书是根据服务器根级证书生成的级联证书，服务器二级证书的私钥签名可以通过服务器根级证书的公钥来验证；
https任务合法性验证模块，用于使得客户端根据服务器根级证书，对执行https任务的服务器进行合法性验证；或
客户端根据服务器二级证书，对执行https任务的服务器进行合法性验证。
9.根据权利要求8所述的装置，其特征在于，还包括：
对称密钥确定模块，用于在与执行https任务的服务器协商对称加密密钥时，使得客户端根据服务器根级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥；或
在与执行https任务的服务器协商对称加密密钥时，使得客户端根据服务器二级证书的公钥，处理从执行https任务的服务器获取的加密后对称密钥，以确定执行https任务的服务器主张的对称密钥。
10.一种实现https双向验证的***，其特征在于，包括：
至少一个执行https任务的客户端，
多个执行https任务的服务器，其中，任一个执行https任务的服务器分别对应一个服务器二级证书，且该服务器二级证书与服务器根级证书为级联证书；
在检测到客户端连接的执行https任务的服务器故障时，将与客户端建立连接的https任务切换到另一台正常执行https任务的服务器上。
CN202110411975.3A 2021-04-16 2021-04-16 实现https双向验证的方法、装置及*** Pending CN113301016A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110411975.3A CN113301016A (zh) 2021-04-16 2021-04-16 实现https双向验证的方法、装置及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110411975.3A CN113301016A (zh) 2021-04-16 2021-04-16 实现https双向验证的方法、装置及***

Publications (1)

Publication Number Publication Date
CN113301016A true CN113301016A (zh) 2021-08-24

Family

ID=77318771

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110411975.3A Pending CN113301016A (zh) 2021-04-16 2021-04-16 实现https双向验证的方法、装置及***

Country Status (1)

Country Link
CN (1) CN113301016A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114268655A (zh) * 2021-12-20 2022-04-01 山东浪潮通软信息科技有限公司 socket通信方法和***
CN114363073A (zh) * 2022-01-07 2022-04-15 中国联合网络通信集团有限公司 Tls加密流量分析方法、装置、终端设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106161435A (zh) * 2016-06-28 2016-11-23 天脉聚源(北京)传媒科技有限公司 一种基于Nginx的双向认证方法及装置
US20170026187A1 (en) * 2015-07-25 2017-01-26 Confia Systems, Inc. Device-level authentication with unique device identifiers
WO2018094268A1 (en) * 2016-11-18 2018-05-24 Veritas Technologies Llc Systems and methods for performing secure backup operations
WO2019109727A1 (zh) * 2017-12-08 2019-06-13 西安中兴新软件有限责任公司 身份验证方法及装置
CN110519304A (zh) * 2019-09-30 2019-11-29 四川虹微技术有限公司 基于tee的https双向认证方法
CN111404772A (zh) * 2020-03-09 2020-07-10 杭州迪普科技股份有限公司 Ssl代理网关的测试***和方法
US10790979B1 (en) * 2019-08-29 2020-09-29 Alibaba Group Holding Limited Providing high availability computing service by issuing a certificate

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170026187A1 (en) * 2015-07-25 2017-01-26 Confia Systems, Inc. Device-level authentication with unique device identifiers
CN106161435A (zh) * 2016-06-28 2016-11-23 天脉聚源(北京)传媒科技有限公司 一种基于Nginx的双向认证方法及装置
WO2018094268A1 (en) * 2016-11-18 2018-05-24 Veritas Technologies Llc Systems and methods for performing secure backup operations
WO2019109727A1 (zh) * 2017-12-08 2019-06-13 西安中兴新软件有限责任公司 身份验证方法及装置
US10790979B1 (en) * 2019-08-29 2020-09-29 Alibaba Group Holding Limited Providing high availability computing service by issuing a certificate
CN110519304A (zh) * 2019-09-30 2019-11-29 四川虹微技术有限公司 基于tee的https双向认证方法
CN111404772A (zh) * 2020-03-09 2020-07-10 杭州迪普科技股份有限公司 Ssl代理网关的测试***和方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114268655A (zh) * 2021-12-20 2022-04-01 山东浪潮通软信息科技有限公司 socket通信方法和***
CN114363073A (zh) * 2022-01-07 2022-04-15 中国联合网络通信集团有限公司 Tls加密流量分析方法、装置、终端设备及存储介质

Similar Documents

Publication Publication Date Title
US10630489B2 (en) Apparatus and method for managing digital certificates
US8458455B2 (en) Techniques for handling SSL certificate expiration and renewal
CN103081399B (zh) 认证设备和***
CN110401629B (zh) 一种激活授权的方法及相关装置
CN109639427B (zh) 一种数据发送的方法及设备
WO2019099149A1 (en) Decentralized enrollment and revocation of devices
CN109302369B (zh) 一种基于密钥验证的数据传输方法及装置
US11153100B2 (en) Achieving certificate pinning security in reduced trust networks
US20160315777A1 (en) Certificate updating
CA2513434A1 (en) Communication apparatus, certificate issuing apparatus, and communication system
CN113301016A (zh) 实现https双向验证的方法、装置及***
JP6571890B1 (ja) 電子署名システム、証明書発行システム、証明書発行方法及びプログラム
CN113810373A (zh) 一种基于国密算法的ceph可视化一键部署方法
US11528150B1 (en) Real-time certificate pinning list (RTCPL)
KR100890720B1 (ko) 웹 콘텐츠를 선택적으로 암호화하는 방법 및 그러한 방법을수행하는 프로그램이 기록된 컴퓨터 판독 가능 기록 매체
CN114598455A (zh) 数字证书签发的方法、装置、终端实体和***
EP4324159A1 (en) Secure root-of-trust enrolment and identity management of embedded devices
TWI698113B (zh) 電子裝置之認證方法及系統
WO2009066978A9 (en) Method and system for generating a proxy digital certificate to a grid portal in distributed computing infrastructure by data transfer across a public network
JP2005117277A (ja) ルート証明書更新システム、方法およびプログラムとサーバ装置およびクライアント装置
CN115883104B (zh) 终端设备的安全登录方法及装置、非易失性存储介质
US20240195641A1 (en) Interim root-of-trust enrolment and device-bound public key registration
CN107733659B (zh) 密钥证书处理方法、装置以及密钥证书认证方法和装置
IES20070726A2 (en) Automated authenticated certificate renewal system
CA3169475A1 (en) Method and apparatus for certifying an application-specific key and for requesting such certification

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination