CN115134088A

CN115134088A - Client certificate verification method and system and electronic equipment

Info

Publication number: CN115134088A
Application number: CN202210711684.0A
Authority: CN
Inventors: 殷浩文
Original assignee: Hangzhou DPTech Technologies Co Ltd
Current assignee: Hangzhou DPTech Technologies Co Ltd
Priority date: 2022-06-22
Filing date: 2022-06-22
Publication date: 2022-09-30

Abstract

The disclosure relates to a client certificate verification method, a system, an electronic device and a computer readable medium. The method comprises the following steps: the client side obtains return information for HTTPS bidirectional authentication from the server side; the client sends a client certificate to the load balancing equipment based on the return information; the load balancing equipment verifies the client certificate based on local storage data; and after the certificate passes verification, the client and the server continue to carry out HTTPS bidirectional authentication. The client certificate verification method, the system, the electronic equipment and the computer readable medium can avoid sending out a certificate information inquiry message when the equipment performs a bidirectional authentication business process, and reduce the phenomenon of slow or blind user access caused by waiting for inquiring the certificate state all the time.

Description

Client certificate verification method and system and electronic equipment

Technical Field

The present disclosure relates to the field of computer information processing, and in particular, to a method, a system, an electronic device, and a computer-readable medium for verifying a client certificate.

Background

Like various certificates in daily life, a digital certificate may become unusable before the expiration date due to a change in user information or a loss of a key medium. At this time, the CA needs to revoke the certificate in time and place the revoke certificate in the CRL, so as to improve the validity of the user when inquiring the certificate. Meanwhile, when a user receives a digital certificate, the user also needs to inquire whether the certificate is revoked. If the customer is still using a certificate that has been revoked, a significant safety hazard will result. Therefore, the frequency of updating certificate revocation information is very important.

The main difference between LDAP directories and conventional databases is the organization of data, which is a hierarchical, tree-like structure. The definition of the attributes of all the entries is a component of the object class and together form the schema. Through LDAP storage and inquiry of certificate revocation information, client inquiry efficiency can be effectively improved, and the problem of service blocking caused by network reasons is reduced.

The above information disclosed in this background section is only for enhancement of understanding of the background of the application and therefore it may contain information that does not constitute prior art that is already known to a person of ordinary skill in the art.

Disclosure of Invention

In view of this, the present application provides a method, a system, an electronic device, and a computer readable medium for verifying a client certificate, which can avoid sending a message for inquiring certificate information to the outside when a device performs a bidirectional authentication service process, thereby reducing a phenomenon of slow or blocked user access caused by waiting for inquiring a certificate status.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.

According to an aspect of the present application, a client certificate verification method is provided, where the method includes: the client side obtains return information for HTTPS bidirectional authentication from the server side; the client side sends a client side certificate to the load balancing equipment based on the return information; the load balancing equipment verifies the client certificate based on local storage data; and after the certificate passes verification, the client and the server continue to carry out HTTPS bidirectional authentication.

In an exemplary embodiment of the present application, further comprising: the load balancing equipment regularly acquires and stores revoke list information containing a plurality of client certificates.

In an exemplary embodiment of the present application, the periodically acquiring and storing revoke list information including a plurality of client certificates by the load balancing device includes: the load balancing equipment establishes connection with an LDAP site through a lightweight directory access protocol at regular time; obtaining revoke list information including a plurality of client certificates by the LDAP site based on the connection; storing the revocation list information locally.

In an exemplary embodiment of the present application, obtaining revoke list information including a plurality of client certificates by the LDAP site based on the connection comprises: sending a query request to the LDAP site based on the connection load balancing equipment; traversing data according to the configuration sequence of the LDAP sites when the response message of the query request meets a preset strategy; and acquiring revoke list information containing a plurality of client certificates by the LDAP site.

In an exemplary embodiment of the present application, storing the suspension pin list information locally includes: locally generating a file directory consistent with the LDAP site in the load balancing equipment; storing the revocation list information locally based on the file directory; and storing the acquisition time and the list number of the suspension pin list.

In an exemplary embodiment of the present application, further comprising: configuring an RSA certificate and a trusted issuer in the load balancing device; and starting an expense list site function in the load balancing equipment.

In an exemplary embodiment of the present application, verifying, by a load balancing device, the client certificate based on locally stored data includes: the load balancing equipment carries out credit granting authentication on the client certificate; and after the trust authentication is passed, revoking and confirming the client certificate based on the local storage data.

In an exemplary embodiment of the present application, revoking the client certificate based on locally stored data includes: when the client certificate is matched in the local storage data, determining that the client certificate is not verified; and when the client certificate is not matched in the local storage data, determining that the client certificate is verified.

According to an aspect of the present application, a client certificate verification system is provided, where the apparatus includes: the client is used for acquiring return information for HTTPS bidirectional authentication by the server; the client sends a client certificate to the load balancing equipment based on the return information; the load balancing equipment is used for verifying the client certificate based on local storage data; and the server is used for continuing to carry out HTTPS bidirectional authentication with the client after the certificate passes verification.

In an exemplary embodiment of the present application, the load balancing apparatus is further configured to: and regularly acquiring and storing revoke list information containing a plurality of client certificates.

According to an aspect of the present application, an electronic device is provided, the electronic device including: one or more processors; storage means for storing one or more programs; when executed by one or more processors, cause the one or more processors to implement a method as above.

According to an aspect of the application, a computer-readable medium is proposed, on which a computer program is stored, which program, when being executed by a processor, carries out the method as above.

According to the client certificate verification method, the system, the electronic equipment and the computer readable medium, return information for HTTPS bidirectional authentication is acquired by the server through the client; the client sends a client certificate to the load balancing equipment based on the return information; the load balancing equipment verifies the client certificate based on local storage data; after the certificate passes the verification, the client and the server continue to perform HTTPS bidirectional authentication, so that when the equipment performs a bidirectional authentication service process, a message for inquiring certificate information does not need to be sent outwards any more, and the phenomenon that the user is slow to access or is not communicated due to the fact that the user waits for inquiring the state of the certificate all the time is reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The above and other objects, features and advantages of the present application will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings. The drawings described below are only some embodiments of the present application, and other drawings may be derived from those drawings by those skilled in the art without inventive effort.

FIG. 1 is a schematic diagram illustrating a client certificate verification system in accordance with an exemplary embodiment.

Fig. 2 is a flow diagram illustrating a method of client certificate verification in accordance with an example embodiment.

Fig. 3 is a flowchart illustrating a method of client certificate verification, according to another example embodiment.

Fig. 4 is a flowchart illustrating a method of client certificate verification, according to another example embodiment.

FIG. 5 is a block diagram illustrating a client certificate verification system in accordance with an exemplary embodiment.

FIG. 6 is a block diagram illustrating an electronic device in accordance with an example embodiment.

FIG. 7 is a block diagram illustrating a computer-readable medium in accordance with an example embodiment.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The same reference numerals denote the same or similar parts in the drawings, and thus, a repetitive description thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the embodiments of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, systems, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

It will be understood that, although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one element from another. Thus, a first component discussed below could be termed a second component without departing from the teachings of the present concepts. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

It will be appreciated by those skilled in the art that the drawings are merely schematic representations of exemplary embodiments, and that the blocks or processes shown in the drawings are not necessarily required to practice the present application and are, therefore, not intended to limit the scope of the present application.

The technical abbreviations referred to in this application are explained as follows:

LDAP (Lightweight Directory Access Protocol) is an open, neutral and industry standard application Protocol, and provides Access control and maintains Directory information of distributed information through an IP (Internet Protocol).

HTTPS: hyper Text Transfer Protocol over Secure Socket Layer, Secure hypertext Transfer Protocol, ssl (Secure Sockets Layer) Protocol is used to encrypt data transmitted by Http Protocol, and ensure security in the session process. In the one-way authentication process, the client verifies the certificate sent by the server; in the process of bidirectional authentication, a client needs to verify a certificate sent by a server, the client needs to send the certificate to the server, and the server needs to verify the certificate sent by the client

The flow of HTTPS mutual authentication is as follows:

1. the client sends information such as SSL protocol version number, encryption algorithm type, random number and the like to the server.

2. The server side returns information such as SSL protocol version number, encryption algorithm type, random number and the like to the client side, and also returns a certificate of the server side, namely a public key certificate

3. The client side verifies the validity of the server by using the information returned by the server side, and the method comprises the following steps:

whether the certificate has expired

Whether CA of hairstyle server certificate is reliable

Whether the returned public key can correctly unlock the digital signature in the returned certificate

Whether the domain name on the server certificate matches the actual domain name of the server

After the verification is passed, the communication is continued, otherwise, the communication is terminated

The server requires the client to send the client certificate, and the client can send the client certificate to the server

Verifying the certificate of the client, and obtaining the public key of the client after verification

The client sends a symmetric encryption scheme which can be supported by the client to the server for the server to select

The server selects the encryption mode with the highest encryption degree from the encryption schemes provided by the client

The encryption scheme is encrypted by using the public key acquired before and returned to the client

4. After receiving the cipher text of the encryption scheme returned by the server, the client decrypts the cipher text by using the private key of the client to obtain a specific encryption mode, then generates a random code of the encryption mode to be used as a secret key in the encryption process, encrypts the random code by using the public key obtained from the certificate of the server before, and sends the random code to the server

5. After receiving the message sent by the client, the server decrypts the message by using the private key of the server to obtain the symmetric encryption key, and in the next session, the server and the client use the password to perform symmetric encryption, so that the information security in the communication process is ensured.

As shown in fig. 1, the system architecture 10 may include

clients

101, 102, 103, a network 104, and load balancing devices 105, servers 106. The network 104 is used between the

clients

101, 102, 103 and the load balancing device 105; the load balancing device 105 and the server 106 provide a medium for a communication link. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

clients

101, 102, 103 to interact with the server 106 through the load balancing device to receive or send messages, etc. The

clients

101, 102, 103 may have various communication client applications installed thereon, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox clients, social platform software, and the like.

Clients

101, 102, 103 may be a variety of electronic devices having display screens and supporting web browsing, including but not limited to smart phones, tablets, laptop and desktop computers, and the like.

The server 106 may be a server providing various services, such as a background management server providing support for shopping websites browsed by users using the

clients

101, 102, 103. The backend management server can analyze and process the received data such as the product information query request and feed back the processing result to the

clients

101, 102 and 103.

The

client

101, 102, 103 obtains the return information for HTTPS bidirectional authentication by the server 106; based on the return information, the

client

101, 102, 103 sends a client certificate to the load balancing device 105; the load balancing device 105 verifies the client certificate based on locally stored data; after the certificate verification is passed, the

clients

101, 102, 103 and the server 106 continue to perform HTTPS mutual authentication.

The load balancing apparatus 105 periodically acquires and stores revocation list information including a plurality of client certificates.

The load balancing device 105 may be an entity server, and may also be, for example, a gateway, a firewall, and other devices, it should be noted that the client certificate verification method provided in this embodiment may be executed by the load balancing device 105, and accordingly, the client certificate verification system may be disposed in the load balancing device 105.

In a specific embodiment, in the client certificate verification system disclosed in the present application, the load balancing device may be deployed in an enterprise network, and periodically acquire and store revoke list information of a certificate from an LDAP site in advance through an LDAP protocol. When the bidirectional authentication service flow of HTTPS exists and the client sends the certificate, the equipment can directly inquire the LDAP directory to check whether the certificate is revoked or not, and does not need to inquire a certificate revocation list from a certificate server to confirm whether the certificate is available or not.

When the client sends the certificate and performs the bidirectional authentication business process, the certificate verification process can be accelerated, and the user access rate is improved. It is worth mentioning that the scheme in the application, preferably, can regularly maintain the LDAP site; if the station only adds the own revoke list information and does not delete the own revoke list information, the revoke list information acquired by the equipment occupies a large amount of kernel space, and the load traffic of the equipment is seriously influenced.

Fig. 2 is a flowchart illustrating a method of client certificate verification, in accordance with an example embodiment. The client certificate verification method 20 includes at least steps S202 to S208.

As shown in fig. 2, in S202, the client acquires, by the server, return information for HTTPS mutual authentication.

In S204, the client sends a client certificate to the load balancing device based on the return information.

In S206, the load balancing device verifies the client certificate based on the locally stored data. The load balancing equipment can carry out credit authorization on the client certificate; and after the trust authentication is passed, revoking and confirming the client certificate based on the local storage data.

In one embodiment, an RSA certificate and a trusted issuer are configured in the load balancing device; and starting an expense list site function in the load balancing equipment.

In S208, after the certificate is verified, the client and the server continue to perform HTTPS mutual authentication.

When the client certificate is matched in the local storage data, determining that the client certificate is not verified;

wherein the client certificate is determined to be validated when the client certificate is not matched in the locally stored data.

According to the client certificate verification method, return information for HTTPS bidirectional authentication is acquired by a server through a client; the client side sends a client side certificate to the load balancing equipment based on the return information; the load balancing equipment verifies the client certificate based on local storage data; after the certificate passes the verification, the client and the server continue to perform HTTPS bidirectional authentication, so that when the equipment performs a bidirectional authentication service process, a message for inquiring certificate information does not need to be sent outwards any more, and the phenomenon that the user is slow to access or is not communicated due to the fact that the user waits for inquiring the state of the certificate all the time is reduced.

It should be clearly understood that this application describes how to make and use particular examples, but the principles of this application are not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.

In one embodiment, further comprising: the load balancing equipment regularly acquires and stores revoke list information containing a plurality of client certificates. More specifically, the load balancing device establishes connection with the LDAP site through a lightweight directory access protocol at regular time; obtaining revoke list information including a plurality of client certificates by the LDAP site based on the connection; storing the revoke list information locally.

Wherein obtaining revoke list information including a plurality of client certificates by the LDAP site based on the connection comprises: sending a query request to an LDAP site based on the connection load balancing equipment; traversing data according to the configuration sequence of the LDAP sites when the response message of the query request meets a preset strategy; and acquiring revoke list information containing a plurality of client certificates by the LDAP site.

Wherein storing the revoke list information locally comprises: locally generating a file directory consistent with the LDAP site in the load balancing equipment; storing the revocation list information locally based on the file directory; and storing the acquisition time and the list number of the suspension pin list.

Fig. 3 is a flowchart illustrating a method of client certificate verification, according to another example embodiment. The process 30 shown in fig. 3 is a supplementary description of the process shown in fig. 2.

As shown in fig. 3, in S302, the load balancing apparatus sets a timing update configuration. The LDAP site information may be configured as follows:

1. IP address of LDAP site

Base DN configured as the designated directory path to be fetched, in this example, get crl _01 and crl _02 as examples:

cn＝crl,cn＝test,o＝dp,c＝cn

3. configuring the automatic updating time to be 1 hour, namely every 1 hour, the equipment sends a request to the LDAP site to acquire the current revoke list information stored by the site

In S304, the load balancing device sends a request to the LDAP site.

In S306, whether a response message of LDPA is received.

In S308, "tentative information" is displayed.

In S310, whether the response packet contains preset target data is determined. LDAP sites deposit revocation lists of certificates to attributes: certificateRevocationList; in the binary, after receiving the information of the site, the device actively identifies the attribute name, and creates a directory according to the Distinguished Name (DN) of the site, and stores the attribute value. When the condition of certificate revocation is required to be inquired, the equipment traverses the database from top to bottom according to the configuration sequence of the sites to acquire the information of the certificate revocation list.

In S312, a directory is locally generated and data is stored.

After the configuration is completed, the equipment immediately sends a request to the LDAP site to acquire the revoke list information under the directory corresponding to the Base DN. After successful acquisition, a corresponding column is configured in the station, and the time for acquiring the station revoke list information and the number of the acquired revoke lists (defined according to the number of binary) are displayed. When the acquisition fails, displaying 'temporary information' in a state column of the site, and at the moment, confirming whether the intercommunication between the equipment and the LDAP site is available, whether data stored in the LDAP site is wrong, and whether an attribute value certificateRevocationList exists; and (4) binary.

The load balancing equipment periodically sends an LDAP request to the site by configuring an LDAP site, acquires a revocation certificate list of the site under a specified directory, and stores the revocation certificate list in a database of the load balancing equipment. When the client and the load balancing equipment perform a bidirectional authentication service process and the client sends a certificate to the equipment, the equipment directly queries the cancellation condition of the certificate in the database under the LDAP directory.

Fig. 4 is a flowchart illustrating a method of client certificate verification, in accordance with another exemplary embodiment. The flow 40 shown in fig. 4 is a detailed description of S206 "the load balancing apparatus verifies the client certificate based on the locally stored data" in the flow shown in fig. 2.

As shown in fig. 4, in S402, the client sends a certificate to the load balancing apparatus.

More specifically, first, on the load balancing device, the HTTPS service is configured:

1. the method comprises the steps that the equipment imports an RSA certificate and a trusted issuer;

2. configuring SSL strategy, referring RSA certificate in step 1, configuring protocol as TLS1.2 and algorithm as

TLS _ RSA _ WITH _ AES _256_ CBC _ SHA, TLS _ RSA _ WITH _ AES _128_ CBC _ SHA, TLS _ ECDHE _ RSA _ WITH _ AES _256_ CBC _ SHA384, the client authentication configured as "the client must send a certificate", the trusted issuer references the trusted issuer in step 1, the revoke list site function is enabled, and the configured LDAP site is placed into a selected field;

3. configuring a real service Server1, a Server2 and a Server3 to provide HTTP service;

4. configuring a real service group, simultaneously quoting 3 real services in the step 3, and configuring a scheduling algorithm as a polling algorithm;

5. configuring virtual service, wherein the mode is seven layers, the protocol is TCP, the port is 443, and the default real service group is the real service group in the step 4; in the policy, the SSL acceleration policy refers to the SSL policy of step 2.

At S404, it is a credit issuer.

In S406, "certificate error" is replied.

In S408, the revocation list in the local LDPA directory is queried.

In S410, whether the certificate serial number is matched.

In S412, whether or not the pin has been lifted.

In S414, a reply "certificate has been revoked".

In S416, the client certificate is verified.

According to the client certificate verification method, in a bidirectional authentication service process, when equipment receives a certificate sent by a client, whether the certificate is issued by a trusted issuer configured with a strategy is confirmed: if not, a prompt of certificate error is returned to the client; if the certificate is matched with the LDAP directory, the equipment queries the LDAP directory from top to bottom according to the serial number of the certificate: after the serial numbers are matched, the revoking date of the certificate is checked, and if the certificate is revoked, the revoked information of the certificate of the client side is returned; if the client certificate is not revoked, the client certificate passes authentication; if the serial number is not matched, the certificate is not revoked, and the client certificate passes authentication.

The invention can ensure that the equipment stores the revoke list information in the LDAP website directory, and only the revoke list information stored by the equipment needs to be inquired when the equipment carries out the bidirectional authentication service flow without sending a message for inquiring the certificate information to the outside. When the system can not communicate with the LDAP site, the information query of the certificate can still be completed, and the phenomenon that the user access is slow or is not communicated due to the fact that the user waits for querying the state of the certificate all the time is reduced.

Those skilled in the art will appreciate that all or part of the steps implementing the above embodiments are implemented as computer programs executed by a CPU. When executed by the CPU, performs the functions defined by the methods provided herein. The program may be stored in a computer readable storage medium, which may be a read-only memory, a magnetic or optical disk, or the like.

Furthermore, it should be noted that the above-mentioned figures are only schematic illustrations of the processes involved in the method according to exemplary embodiments of the present application, and are not intended to be limiting. It will be readily understood that the processes shown in the above figures are not intended to indicate or limit the chronological order of the processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, e.g., in multiple modules.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

FIG. 5 is a block diagram illustrating a client certificate verification system in accordance with an exemplary embodiment. As shown in fig. 5, the client certificate verification system 50 includes: client 502, load balancing device 504, and server 506.

The client 502 is used for the server to obtain the return information for the HTTPS bidirectional authentication; the client side sends a client side certificate to the load balancing equipment based on the return information;

the load balancing device 504 is configured to verify the client certificate based on locally stored data; the load balancing device is further configured to: and regularly acquiring and storing revoke list information containing a plurality of client certificates.

The server 506 is used for continuing to perform HTTPS bidirectional authentication with the client after the certificate verification is passed.

According to the client certificate verification system, return information for HTTPS bidirectional authentication is acquired by a server through a client; the client side sends a client side certificate to the load balancing equipment based on the return information; the load balancing equipment verifies the client certificate based on local storage data; after the certificate passes the verification, the client and the server continue to perform HTTPS bidirectional authentication, so that when the equipment performs a bidirectional authentication service process, a message for inquiring certificate information does not need to be sent outwards any more, and the phenomenon that the user is slow to access or is not communicated due to the fact that the user waits for inquiring the state of the certificate all the time is reduced.

An electronic device 600 according to this embodiment of the present application is described below with reference to fig. 6. The electronic device 600 shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 6, the electronic device 600 is in the form of a general purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 that connects the various system components (including the storage unit 620 and the processing unit 610), a display unit 640, and the like.

Wherein the storage unit stores program code executable by the processing unit 610 to cause the processing unit 610 to perform steps according to various exemplary embodiments of the present application described in the present specification. For example, the processing unit 610 may perform the steps as shown in fig. 2, 3, 4.

The storage unit 620 may include readable media in the form of volatile storage units, such as a random access memory unit (RAM)6201 and/or a cache storage unit 6202, and may further include a read-only memory unit (ROM) 6203.

The memory unit 620 may also include a program/utility 6204 having a set (at least one) of program modules 6205, such program modules 6205 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 630 may be one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 600 may also communicate with one or more external devices 600' (e.g., keyboard, pointing device, bluetooth device, etc.), such that a user can communicate with devices with which the electronic device 600 interacts, and/or any device (e.g., router, modem, etc.) with which the electronic device 600 can communicate with one or more other computing devices. Such communication may occur via an input/output (I/O) interface 650. Also, the electronic device 600 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network such as the Internet) via the network adapter 660. The network adapter 660 may communicate with other modules of the electronic device 600 via the bus 630. It should be appreciated that although not shown in the figures, other hardware and/or software modules may be used in conjunction with the electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, to name a few.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, and may also be implemented by software in combination with necessary hardware. Therefore, as shown in fig. 7, the technical solution according to the embodiment of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, or a network device, etc.) to execute the above method according to the embodiment of the present application.

The software product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The computer readable storage medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable storage medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a readable storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In situations involving remote computing devices, the remote computing devices may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to external computing devices (e.g., through the internet using an internet service provider).

The computer readable medium carries one or more programs which, when executed by a device, cause the computer readable medium to perform the functions of: the client side obtains return information for HTTPS bidirectional authentication from the server side; the client sends a client certificate to the load balancing equipment based on the return information; the load balancing equipment verifies the client certificate based on local storage data; and after the certificate passes verification, the client and the server continue to carry out HTTPS bidirectional authentication. The computer readable medium may also implement the following functions: the load balancing equipment regularly acquires and stores revoke list information containing a plurality of client certificates.

Those skilled in the art will appreciate that the modules described above may be distributed in the apparatus according to the description of the embodiments, or may be modified accordingly in one or more apparatuses unique from the embodiments. The modules of the above embodiments may be combined into one module, or further split into multiple sub-modules.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiment of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiment of the present application.

Exemplary embodiments of the present application are specifically illustrated and described above. It is to be understood that the application is not limited to the details of construction, arrangement or method of operation set forth herein; on the contrary, the application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A method for client certificate verification, comprising:

the client side obtains return information for HTTPS bidirectional authentication from the server side;

the client side sends a client side certificate to the load balancing equipment based on the return information;

the load balancing equipment verifies the client certificate based on local storage data, wherein the load balancing equipment configures specified directories for a plurality of LDAP sites, establishes connection with the LDAP sites through a lightweight directory access protocol at regular time, sends LDAP requests to the plurality of LDAP sites, acquires revoke certificate lists of the plurality of LADP sites under the specified directories as revoke list information, and stores the revoke certificate lists as local storage data in a database of the load balancing equipment;

and after the certificate passes verification, the client and the server continue to carry out HTTPS bidirectional authentication.

2. The method as claimed in claim 1, wherein sending an LDAP request to a plurality of LDAP sites, obtaining a list of revoke certificates specifying a plurality of LADP sites under a directory as revoke list information, comprises:

traversing data according to the configuration sequence of the LDAP sites when the response message of the query request meets a preset strategy;

and acquiring revoke list information containing a plurality of client certificates by the LDAP site.

3. The method of claim 1, wherein storing it as locally stored data in its own database comprises:

locally generating a file directory consistent with the LDAP site in the load balancing equipment;

storing the revocation list information locally based on the file directory;

and storing the acquisition time and the list number of the suspension pin list.

4. The method of claim 1, further comprising:

configuring an RSA certificate and a trusted issuer in the load balancing device;

and starting an expense list site function in the load balancing equipment.

5. The method of claim 1, wherein the load balancing device verifying the client certificate based on locally stored data comprises:

the load balancing equipment carries out credit authorization on the client certificate;

and after the trust authentication is passed, revoking and confirming the client certificate based on the local storage data.

6. The method of claim 5, wherein revoking the client certificate based on locally stored data comprises:

and when the client certificate is not matched in the local storage data, determining that the client certificate is verified.

7. A client certificate verification system comprising:

the client is used for acquiring return information for HTTPS bidirectional authentication by the server; the client side sends a client side certificate to the load balancing equipment based on the return information;

the load balancing equipment is used for verifying the client certificate based on local storage data, configuring specified directories for a plurality of LDAP sites, establishing connection with the LDAP sites through a lightweight directory access protocol at regular time, sending LDAP requests to the plurality of LDAP sites, acquiring revoke certificate lists of the plurality of LADP sites under the specified directories as revoke list information, and storing the revoke certificate lists as local storage data in a database of the load balancing equipment;

and the server is used for continuing to carry out HTTPS bidirectional authentication with the client after the certificate passes verification.

8. The client certificate verification system according to claim 7, wherein the load balancing device obtains revoke list information including a plurality of client certificates from the LDAP site by traversing data according to a configuration order of the LDAP site when a response packet of the query request satisfies a preset policy.

9. The client certificate verification system according to claim 7, wherein the load balancing device configures an RSA certificate and a trusted issuer and enables an revoke list site function, and revokes the client certificate by performing trust authentication on the client certificate and after the trust authentication is passed, based on locally stored data.

10. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method recited in any of claims 1-6.