CN113242239A - Method, device and system for realizing https bidirectional authentication - Google Patents
Method, device and system for realizing https bidirectional authentication Download PDFInfo
- Publication number
- CN113242239A CN113242239A CN202110505238.XA CN202110505238A CN113242239A CN 113242239 A CN113242239 A CN 113242239A CN 202110505238 A CN202110505238 A CN 202110505238A CN 113242239 A CN113242239 A CN 113242239A
- Authority
- CN
- China
- Prior art keywords
- client
- public key
- server
- access request
- trust library
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000002457 bidirectional effect Effects 0.000 title claims abstract description 23
- 238000004891 communication Methods 0.000 claims description 5
- 238000010276 construction Methods 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 3
- 230000003993 interaction Effects 0.000 abstract description 3
- 230000006870 function Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000008569 process Effects 0.000 description 5
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/604—Tools and structures for managing or administering access control systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- 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
- 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3268—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2137—Time limited access, e.g. to a computer or data
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Automation & Control Theory (AREA)
- Computing Systems (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention relates to a method, a device and a system for realizing https mutual authentication. The method comprises the following steps: loading a pre-constructed trust library; a client public key is stored in the trust library; after loading is successful, starting an https bidirectional authentication function to receive an access request of an https interface sent by a client; the access request is generated after a trust library is loaded by a client; identifying a client public key in the access request; and comparing the client public key in the access request with the client public key in the trust library, and if the comparison is passed, returning the required data of the client. In the method, the client and the server use the code loading certificate to carry out https interaction, so that the authentication security is improved.
Description
Technical Field
The invention relates to the technical field of network communication, in particular to a method, a device and a system for realizing https bidirectional authentication.
Background
When developing projects related to a terminal, data are often required to be encrypted, and the modes with better encryption effect are one-way authentication and two-way authentication of https. The one-way authentication is to hang a CA certificate to a server; the bidirectional authentication needs to mount a CA certificate at the same time at a server and a client to be used. The security index of the mutual authentication method is the highest.
The most common method for bidirectional authentication at present is as follows: the method comprises the steps that a CA certificate of a purchasing server is mounted on a server, a CA certificate of a purchasing client is mounted on a client, and the client can access the server only when the client wants to access the server by purchasing the CA certificate of the client first and installing the CA certificate.
Disclosure of Invention
In view of this, the present invention provides a method, an apparatus and a system for implementing https mutual authentication to overcome the deficiencies of the prior art. The problem that only CA certificates can be purchased to realize communication between the server and the client at present is solved.
In order to achieve the purpose, the invention adopts the following technical scheme:
a method for realizing https mutual authentication is applied to a server side, and the method comprises the following steps:
loading a pre-constructed trust library; a client public key is stored in the trust library;
after loading is successful, starting an https bidirectional authentication function to receive an access request of an https interface sent by a client; the access request is generated after the client loads the trust library;
identifying a client public key in the access request;
and comparing the client public key in the access request with the client public key in the trust library, and if the comparison is passed, returning the required data of the client.
Optionally, the method further includes:
calling a keytool to generate the server certificate and the client certificate;
and storing the server public key in the server certificate and the client public key in the client certificate into the trust library.
Optionally, the method further includes:
sending a second access request to the client, and receiving target data fed back by the client; the second access request comprises the server public key; and the target data is sent after the client verifies that the server public key passes through.
A method for realizing https mutual authentication, the method being applied to a client, the method comprising:
loading a pre-constructed trust library; the trust library is generated by calling keytools from a server side;
acquiring a client public key stored in the trust library;
generating an access request containing the client public key;
sending the access request to the server and receiving required data fed back by the server; and the required data is sent after the server side verifies that the client public key passes through.
Optionally, the trust library further includes: a server public key;
further comprising:
receiving a second access request sent by the client; the second access request comprises a server public key and a target data request;
comparing the server public key in the second access request with the server public key in the trust library;
and after the comparison is passed, acquiring target data according to the target data request, and sending the target data to the server.
An apparatus for implementing https mutual authentication, comprising:
the first trust library loading module is used for loading a pre-constructed trust library; a client public key is stored in the trust library;
the client access request receiving module is used for starting an https bidirectional authentication function after successful loading so as to receive an access request of an https interface sent by a client;
the client public key identification module is used for identifying a client public key in the access request;
and the public key verification module is used for comparing the client public key in the access request with the client public key in the trust library, and returning the required data of the client if the comparison is passed.
Optionally, the method further includes:
the certificate generation module is used for calling the keytool and generating the server certificate and the client certificate;
and the trust library construction module is used for storing the server public key in the server certificate and the client public key in the client certificate into the trust library.
An apparatus for implementing https mutual authentication, comprising:
the second trust library loading module is used for loading a pre-constructed trust library; the trust library is generated by calling keytools from a server side;
the client public key acquisition module is used for acquiring a client public key stored in the trust library;
the client access request generating module is used for generating an access request containing the client public key;
the client access request sending module is used for sending the access request to the server and receiving the required data fed back by the server; and the required data is sent after the server side verifies that the client public key passes through.
A system for implementing https mutual authentication, comprising:
the system comprises a server and a client in communication connection with the server;
the server is used for executing the method for realizing https mutual authentication;
the client is used for executing the method for realizing https mutual authentication.
The technical scheme provided by the application can comprise the following beneficial effects:
the application discloses a method for realizing https mutual authentication, which comprises the following steps: loading a pre-constructed trust library; the trust repository has a client public key stored therein. After the trust library is loaded successfully, starting an https bidirectional authentication function to receive an access request of an https interface sent by a client; the access request is generated after the client loads the trust library. Then identifying a client public key in the access request; and comparing the client public key in the access request with the client public key in the trust library, and if the comparison is passed, returning the required data of the client. In the bidirectional authentication process, the client certificate and the trust library which are generated by the server are used, the certificate expiration date can be set by self, the trust libraries are loaded on the server and the client respectively for https interaction, and the safety factor is improved to the utmost extent within a limited range.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a flowchart of a https mutual authentication method applied to a server according to an embodiment of the present invention;
fig. 2 is a flowchart of a method for https mutual authentication applied to a client according to an embodiment of the present invention;
fig. 3 is a structural diagram of an apparatus for https mutual authentication applied to a server according to an embodiment of the present invention;
fig. 4 is a structural diagram of an apparatus for https mutual authentication applied to a client according to an embodiment of the present invention;
fig. 5 is a structural diagram of a system for implementing https mutual authentication according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the technical solutions of the present invention will be described in detail below. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the examples given herein without any inventive step, are within the scope of the present invention.
The application provides a method for carrying out https interaction by a server (Java) and a client (android) by using a code loading certificate, and specifically introduces a bidirectional authentication implementation process from two angles of the server and the client. The method comprises the following specific steps:
now, details will be described by taking an example in which a client sends an access request to a server.
Fig. 1 is a flowchart of a https mutual authentication method applied to a server according to an embodiment of the present invention. Referring to fig. 1, a method for implementing https mutual authentication includes:
step 101: loading a pre-constructed trust library; the trust library has a client public key stored therein. The construction process of the trust library comprises the following steps: calling a keytool to generate a server certificate and a client certificate; and then storing the server public key of the server certificate and the client public key of the client certificate into a trust library. And when the server and the client need to perform bidirectional authentication, the two sides load the trust library to perform identity authentication.
Step 102: after loading is successful, starting an https bidirectional authentication function to receive an access request of an https interface sent by a client; the access request is generated after the client loads the trust library. And after the server successfully loads the trust library, acquiring a server public key and a client public key in the trust library. When the server side sends an access request to the client side, the access request comprises a server side public key, and the client side verifies the client side according to the server side public key. When the client sends an access request to the server, the access request sent by the client contains a client public key, and then the server verifies that the client public key in the access request is compared with a client public key in a trust library acquired by the server.
Step 103: a client public key in the access request is identified. When the client sends an access request, the access request comprises a client public key, and the server performs identity authentication on the client according to the client public key.
Step 104: and judging that the client public key in the access request is consistent with the client public key in the trust library.
Step 105: and if the comparison is passed, returning the required data of the client. When the client public key sent by the client is consistent with the client public key loaded in the trust library by the server and represents that the client identity authentication is passed, the server identifies a required data request in an access request sent by the client, determines data required by the client according to the required data request, and then calls the corresponding required data and feeds the data back to the client.
Meanwhile, when the client sends an access request to the server, the operation of the client is as follows:
fig. 2 is a flowchart of a method for https mutual authentication applied to a client according to an embodiment of the present invention. Referring to fig. 2, a method for implementing https mutual authentication includes:
step 201: loading a pre-constructed trust library; the trust library is generated by calling keytool by a server side. When https mutual authentication is performed, both the client and the server need to load a trust library, and a client public key and a server public key in the trust library are obtained.
Step 202: and acquiring a client public key stored in the trust library.
Step 203: and generating an access request containing the client public key. After the client public key in the trust library is obtained, the client generates an access request, and the access request comprises the client public key and a required data request.
Step 204: sending the access request to the server and receiving required data fed back by the server; and the required data is sent after the server side verifies that the client public key passes through. After the access request is sent to the server, the server can identify the access request to authenticate the client, and the data required by the client is returned after the authentication is passed.
On the basis of the above embodiment, the bidirectional authentication method in the present application further supports the service end to send an access request to the client end, specifically: the server side sends a second access request to the client side, the client side identifies the server side public key in the second access request after receiving the second access request, then the client side identifies the server side public key in the identified second access request and the server side public key in the loaded trust library, whether the server side public key and the server side public key are consistent or not is judged, if the server side public key and the server side public key are consistent, the client side identifies the target data request in the second access request, and then target data corresponding to the target data request are obtained and fed back to the server side.
In the method, a client certificate, a server certificate and a trust library are generated by using keytools, and a client public key and a server public key are led into the trust library. And then placing the trust library and the certificate into android and java projects for loading, firstly, java loads the service end and the trust library and starts https bidirectional authentication, at the moment, only the access request of the client end loaded by the client end certificate can be accessed, the client end certificate and the trust library are loaded at the android end, the https interface request is sent, and at the moment, the service end response can be obtained.
It should be noted that the bidirectional authentication method in the present application can open not only 443 ports but also 80 ports, and support both http and https requests.
The self-generated certificate is used in the application, the certificate expiration date can be set by self, the most suitable project is that the project is not high in safety degree and does not need to spend money to buy the ca certificate, the certificates are loaded at java and android ends respectively, and the safety factor is improved to the utmost extent within a limited range.
Corresponding to the https bidirectional authentication method provided by the embodiment of the invention, the embodiment of the invention also provides a https bidirectional authentication device. Please see the examples below.
Fig. 3 is a structural diagram of an apparatus for https mutual authentication applied to a server according to an embodiment of the present invention. Referring to fig. 3, an apparatus for implementing https mutual authentication includes:
a first trust library loading module 301, configured to load a pre-constructed trust library; a client public key is stored in the trust library;
the client access request receiving module 302 is configured to start an https bidirectional authentication function after successful loading, so as to receive an access request of an https interface sent by a client;
a client public key identification module 303, configured to identify a client public key in the access request;
and the public key verification module 304 is configured to compare the client public key in the access request with the client public key in the trust library, and if the comparison is passed, return the required data of the client.
Still further, the above apparatus further comprises:
the certificate generation module is used for calling the keytool and generating the server certificate and the client certificate;
and the trust library construction module is used for storing the server public key in the server certificate and the client public key in the client certificate into the trust library.
The second access request sending module is used for sending a second access request to the client and receiving target data fed back by the client; the second access request comprises the server public key; and the target data is sent after the client verifies that the server public key passes through.
Fig. 4 is a structural diagram of an apparatus for https mutual authentication applied to a client according to an embodiment of the present invention. Referring to fig. 4, an apparatus for implementing https mutual authentication includes:
a second trust library loading module 401, configured to load a pre-constructed trust library; the trust library is generated by calling keytools from a server side;
a client public key obtaining module 402, configured to obtain a client public key stored in the trust repository;
a client access request generating module 403, configured to generate an access request including the client public key;
a client access request sending module 404, configured to send the access request to the server, and receive required data fed back by the server; and the required data is sent after the server side verifies that the client public key passes through.
Further comprising:
the second access request receiving module is used for receiving a second access request sent by the client; the second access request comprises a server public key and a target data request;
the server public key comparison module is used for comparing the server public key in the second access request with the server public key in the trust library;
and the server data feedback module is used for acquiring target data according to the target data request after the comparison is passed, and sending the target data to the server.
In order to more clearly introduce a hardware system for implementing the embodiment of the present invention, in correspondence to the https bidirectional authentication method provided in the embodiment of the present invention, an embodiment of the present invention further provides a system for implementing https bidirectional authentication. Please see the examples below.
Fig. 5 is a structural diagram of a system for implementing https mutual authentication according to an embodiment of the present invention. Referring to fig. 5, a system for implementing https mutual authentication includes:
a server 501 and a client 502 in communication connection with the server 501;
the server 501 is configured to execute the above https mutual authentication method;
the client 502 is configured to perform the method for implementing https mutual authentication as described above.
The device or equipment solves the problem of https mutual authentication used for encrypting information when a java end interacts with an android end, and can set the expiration date of a certificate by itself by using a self-generated certificate.
It is understood that the same or similar parts in the above embodiments may be mutually referred to, and the same or similar parts in other embodiments may be referred to for the content which is not described in detail in some embodiments.
It should be noted that the terms "first," "second," and the like in the description of the present invention are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. Further, in the description of the present invention, the meaning of "a plurality" means at least two unless otherwise specified.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and alternate implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.
In addition, functional units in the embodiments of the present invention may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.
The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.
Claims (9)
1. A method for realizing https mutual authentication is applied to a server side, and the method comprises the following steps:
loading a pre-constructed trust library; a client public key is stored in the trust library;
after loading is successful, starting an https bidirectional authentication function to receive an access request of an https interface sent by a client; the access request is generated after the client loads the trust library;
identifying a client public key in the access request;
and comparing the client public key in the access request with the client public key in the trust library, and if the comparison is passed, returning the required data of the client.
2. The method of claim 1, further comprising:
calling a keytool to generate the server certificate and the client certificate;
and storing the server public key in the server certificate and the client public key in the client certificate into the trust library.
3. The method of claim 2, further comprising:
sending a second access request to the client, and receiving target data fed back by the client; the second access request comprises the server public key; and the target data is sent after the client verifies that the server public key passes through.
4. A method for realizing https mutual authentication is applied to a client, and the method comprises the following steps:
loading a pre-constructed trust library; the trust library is generated by calling keytools from a server side;
acquiring a client public key stored in the trust library;
generating an access request containing the client public key;
sending the access request to the server and receiving required data fed back by the server; and the required data is sent after the server side verifies that the client public key passes through.
5. The method of claim 4, wherein the trust library further comprises: a server public key;
further comprising:
receiving a second access request sent by the client; the second access request comprises a server public key and a target data request;
comparing the server public key in the second access request with the server public key in the trust library;
and after the comparison is passed, acquiring target data according to the target data request, and sending the target data to the server.
6. An apparatus for implementing https mutual authentication, comprising:
the first trust library loading module is used for loading a pre-constructed trust library; a client public key is stored in the trust library;
the client access request receiving module is used for starting an https bidirectional authentication function after successful loading so as to receive an access request of an https interface sent by a client;
the client public key identification module is used for identifying a client public key in the access request;
and the public key verification module is used for comparing the client public key in the access request with the client public key in the trust library, and returning the required data of the client if the comparison is passed.
7. The apparatus of claim 6, further comprising:
the certificate generation module is used for calling the keytool and generating the server certificate and the client certificate;
and the trust library construction module is used for storing the server public key in the server certificate and the client public key in the client certificate into the trust library.
8. An apparatus for implementing https mutual authentication, comprising:
the second trust library loading module is used for loading a pre-constructed trust library; the trust library is generated by calling keytools from a server side;
the client public key acquisition module is used for acquiring a client public key stored in the trust library;
the client access request generating module is used for generating an access request containing the client public key;
the client access request sending module is used for sending the access request to the server and receiving the required data fed back by the server; and the required data is sent after the server side verifies that the client public key passes through.
9. A system for implementing https mutual authentication, comprising:
the system comprises a server and a client in communication connection with the server;
the server is used for executing the method for realizing https mutual authentication according to any one of claims 1-3;
the client is used for executing the method for realizing https mutual authentication according to any one of claims 4-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110505238.XA CN113242239A (en) | 2021-05-10 | 2021-05-10 | Method, device and system for realizing https bidirectional authentication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110505238.XA CN113242239A (en) | 2021-05-10 | 2021-05-10 | Method, device and system for realizing https bidirectional authentication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113242239A true CN113242239A (en) | 2021-08-10 |
Family
ID=77133172
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110505238.XA Pending CN113242239A (en) | 2021-05-10 | 2021-05-10 | Method, device and system for realizing https bidirectional authentication |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113242239A (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107566393A (en) * | 2017-09-26 | 2018-01-09 | 山东浪潮商用系统有限公司 | A kind of dynamic rights checking system and method based on trust certificate |
| CN110519304A (en) * | 2019-09-30 | 2019-11-29 | 四川虹微技术有限公司 | HTTPS mutual authentication method based on TEE |
| CN111769949A (en) * | 2020-06-23 | 2020-10-13 | 上海擎感智能科技有限公司 | Management/execution method/system, medium, management/agent terminal for mutual authentication |
| CN112035215A (en) * | 2020-08-31 | 2020-12-04 | 腾讯科技（深圳）有限公司 | Node autonomous method, system and device of node cluster and electronic equipment |
-
2021
- 2021-05-10 CN CN202110505238.XA patent/CN113242239A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107566393A (en) * | 2017-09-26 | 2018-01-09 | 山东浪潮商用系统有限公司 | A kind of dynamic rights checking system and method based on trust certificate |
| CN110519304A (en) * | 2019-09-30 | 2019-11-29 | 四川虹微技术有限公司 | HTTPS mutual authentication method based on TEE |
| CN111769949A (en) * | 2020-06-23 | 2020-10-13 | 上海擎感智能科技有限公司 | Management/execution method/system, medium, management/agent terminal for mutual authentication |
| CN112035215A (en) * | 2020-08-31 | 2020-12-04 | 腾讯科技（深圳）有限公司 | Node autonomous method, system and device of node cluster and electronic equipment |
Non-Patent Citations (7)
| Title |
|---|
| CHONGMINGLIU: "Android HTTPS 自制证书实现双向认证(OkHttp + Retrofit + Rxjava)", 《简书，HTTPS://WWW.JIANSHU.COM/P/64172CCFB73B》 * |
| CHONGMINGLIU: "Android HTTPS 自制证书实现双向认证(OkHttp + Retrofit + Rxjava)", 《简书，HTTPS://WWW.JIANSHU.COM/P/64172CCFB73B》, 12 December 2016 (2016-12-12) * |
| 安骏洲: "基于电商平台和审批工作流的报销管理系统的设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
| 安骏洲: "基于电商平台和审批工作流的报销管理系统的设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》, 15 July 2018 (2018-07-15), pages 5 * |
| 朱隆海等: "基于SSL的加密通信的Java实现", 《微机发展》, no. 04, 10 April 2004 (2004-04-10) * |
| 涛哥: "HTTPS实战之单向验证和双向验证", 《HTTPS://MP.WEIXIN.QQ.COM/S/UIGEZXOCN3F66NRZ_T9CRA》 * |
| 涛哥: "HTTPS实战之单向验证和双向验证", 《HTTPS://MP.WEIXIN.QQ.COM/S/UIGEZXOCN3F66NRZ_T9CRA》, 9 June 2018 (2018-06-09) * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110291757B (en) | Method for providing simplified account registration service, user authentication service, and authentication server using the same | |
| CN109961292B (en) | Block chain verification code application method, equipment and storage medium | |
| CN110362990A (en) | Using the security processing of installation, apparatus and system | |
| CN111526111B (en) | Control method, device and equipment for logging in light application and computer storage medium | |
| CN111199037B (en) | Login method, system and device | |
| CN105933374B (en) | A kind of mobile terminal data backup method, system and mobile terminal | |
| CN110247917B (en) | Method and apparatus for authenticating identity | |
| TW202213217A (en) | Secure service request processing methods and apparatuses | |
| CN113132363B (en) | Front-end and back-end security verification method and equipment | |
| CN111241523B (en) | Authentication processing method, device, equipment and storage medium | |
| US11431727B2 (en) | Security of code between code generator and compiler | |
| CN114499892B (en) | Firmware starting method and device, computer equipment and readable storage medium | |
| WO2022088710A1 (en) | Mirror image management method and apparatus | |
| CN112653673B (en) | Multi-factor authentication method and system based on single sign-on | |
| CN110602700B (en) | Seed key processing method and device and electronic equipment | |
| CN113242239A (en) | Method, device and system for realizing https bidirectional authentication | |
| US12010146B2 (en) | Method, system and apparatus for unified security configuration management | |
| CN115879074B (en) | Identity authentication method, device and system based on blockchain | |
| CN117880090A (en) | Configuration updating method, device, terminal equipment and storage medium | |
| CN114584324B (en) | Identity authorization method and system based on block chain | |
| US20190342448A1 (en) | Methods and devices for verifying a communication number | |
| CN114553449A (en) | Encryption and decryption method, device, system, electronic equipment and storage medium based on HTTPS | |
| CN111786936A (en) | Method and device for authentication | |
| CN110248166B (en) | Video information processing method, client, electronic device and storage medium | |
| CN117040930B (en) | Resource processing method, device, product, equipment and medium of block chain network |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210810 |