Method and system for implementing multi-ca dynamic certificate authentication tcp gateway based on netty

Abstract

The application provides a Netty-based multi-CA dynamic certificate verification TCP gateway implementation method and system, and the method comprises the following steps: S1, starting the gateway and realizing module initialization; S2, the client initiates a TCP connection, the gateway receives the connection and initializes a channel; S3, performing SSL security handshake authentication; S4, performing vehicle-mounted data security transmission interaction based on an encrypted link; and S5, dynamically expanding a certificate authority and accessing a new device; the application realizes certificate acquisition and issuing authority information through a dynamic TrustManager module, matches a corresponding trust manager from a preset internal mapping table to complete certificate chain verification, does not need to traverse all CAs, the handshake time consumption does not increase with the increase of the number of CAs, and the large-scale device access performance is improved; a unified server certificate and a single listening port are adopted to complete the SSL handshake, no additional port and domain name are occupied, and the deployment and operation and maintenance complexity is reduced.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for implementing multi-CA dynamic certificate verification TCP gateways based on Netty. Background Technology

[0002] In the fields of IoT, IoV, industrial internet and 5G communication, a large number of heterogeneous devices (such as T-BOX devices, 5G terminals and various sensors) need to be connected to the cloud or back-end service platform through a unified TCP gateway. To ensure the security of communication links, the industry generally adopts the SSL / TLS protocol to achieve two-way authentication, that is, the server presents the server certificate to the client and the client presents the client certificate to the server, and the two parties complete the mutual identity verification. In actual deployments, different organizations and different equipment manufacturers typically use their own independent CAs (Certificate Authorities) to issue client certificates; For example, T-BOX devices use certificates issued by T-BOX CA, 5G devices use certificates issued by 5G CA, and in-vehicle terminals from different car manufacturers use certificates issued by their own CAs. As a unified entry point, the TCP gateway needs to simultaneously verify client certificates from different organizations and issued by different CAs; currently, there are two common implementation methods: (1) The gateway configuration contains a trust store containing multiple CA root certificates. When verifying client certificates, it iterates through them one by one until a certain CA is verified. (2) Assign independent listening ports or domain names to different institutions and equipment (through SNI extension), and bind a unique CA certificate to each port / domain name; Netty, as a high-performance asynchronous event-driven network application framework, is the mainstream choice for building TCP gateways. It provides SSL / TLS support through SslHandler and SslContextBuilder, but the standard certificate verification mechanism is static mode - when building SslContext, TrustManager or TrustManagerFactory is fixed, and the verification logic cannot be dynamically switched according to the client certificate during the handshake process. In summary, the existing technology has the following drawbacks: Multiple CA support is inefficient: If multiple CA root certificates are placed in a single trust store, all CAs need to be traversed when verifying the client certificate. As the number of CAs increases, the handshake time increases linearly, affecting the performance of large-scale device access. Port / domain resource waste: If different ports or domains are assigned to different CAs, multiple IP ports or multiple domains need to be occupied or managed, which increases the deployment and maintenance costs of the gateway and is not suitable for scenarios where the device has fixed hard-coded ports / domains. Unable to dynamically expand CA: When a new organization's device needs to be connected, traditional solutions often require modifying the gateway configuration and restarting the service, causing existing connections to be interrupted and failing to meet high availability requirements. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a method and system for implementing multi-CA dynamic certificate verification TCP gateways based on Netty.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A Netty-based multi-CA dynamic certificate verification TCP gateway system includes a Netty server module, a unified server certificate module, a multi-CA certificate management module, a dynamic TrustManager module, a TrustManagerFactory wrapper module, an SSL context configuration module, and a runtime configuration update module. The Netty server module includes a terminal initializer, which is used to start the gateway, bind the listening port, receive client TCP connections, initialize the network connection channel through the terminal initializer, add an SSL processor and complete the establishment of an encrypted link. The unified server certificate module is used to store server certificates and private keys, and during the SSL handshake, it enables the gateway to send a server greeting message to the client to initiate the SSL handshake. The multi-CA certificate management module is used to load the certificate chain and create an independent trust manager for each certificate authority. The dynamic TrustManager module is used to parse client certificates, obtain certificate authority information, match the corresponding trust manager, and complete certificate verification. The TrustManagerFactory wrapper module is used to encapsulate the trust manager; The SSL context configuration module is used to build the SSL context and enable mandatory client certificate authentication. The runtime configuration update module is used to receive requests for new organizations and forward relevant information.

[0005] This invention also proposes a method for implementing multi-CA dynamic certificate verification TCP gateway based on Netty, the method comprising the following steps: S1: Start the gateway and initialize the modules; The Netty server module starts the gateway and triggers the initialization of each module in the system. After the module initialization is complete, the Netty server module binds to the communication port configured on the gateway and listens for network connections.

[0006] S2: The client initiates a TCP connection, the gateway receives the connection and initializes the channel; When the Netty server module listens for a TCP connection request from a client to the gateway through the communication port, it receives the TCP connection request through the ServerBootstrap and initializes the processor link pipeline for each network connection channel through the TerminalChannelInitializer.

[0007] S3: Perform SSL secure handshake authentication; Includes the following sub-steps: S31: Determine if SSL is enabled; The SSL is Secure Sockets Layer; The terminal initializer in the Netty server module determines whether the SSL context configuration module has successfully built and holds a valid SslContext instance. If it has been successfully built and held, SSL is determined to be enabled, and the process proceeds to step S32; otherwise, SSL is determined to be disabled, and the process proceeds to step S4. S32: Add an SSL processor; If SSL is enabled, the terminal initializer in the Netty server module adds an SSL processor to the header of the processor pipeline. The SSL processor uses an SslContext instance built by the SSL context configuration module. S33: SSL handshake interaction, client certificate verification and link establishment; S331: Initiate the SSL handshake and request the client to upload its certificate; The gateway uses the SSL processor to call the pre-loaded server certificate and private key in the unified server certificate module, sends a server greeting message to the client, and initiates the SSL handshake. The SSL processor sends a certificate request message to the client, requesting the client to submit its own client certificate; The client responds to the request and uploads its client certificate and certificate chain, wherein the client certificate is issued by a vehicle terminal certificate authority or similar body. S332: The SSL processor calls the dynamic trust manager module to verify the client certificate; The dynamic trust manager module calls the checkClientTrusted method to parse the client certificate, obtain the certificate authority information, and match the corresponding trust manager from the internal mapping table stored in the dynamic trust manager module based on the certificate authority information. The internal mapping table contains the correspondence between certificate authority information and trust managers. The dynamic trust manager module will match and compare the certificate authority information obtained from the client certificate with the multiple pre-configured certificate authority information in the internal mapping table one by one. When an entry that is completely consistent with the current certificate authority information is found, the trust manager corresponding to that entry will be selected. The dynamic trust manager module uses the trust manager to verify the digital signature, validity period, and integrity of the certificate chain uploaded by the client. If the verification passes, the SSL processor establishes an encrypted link between the gateway and the vehicle client; if the verification fails, the handshake is terminated and the connection between the two parties is disconnected. The certificate chain contains certificates at each level and certificate information at each level. The certificate information at each level includes the corresponding digital signature, validity period, and public key of the superior certificate.

[0008] S4: Secure transmission and interaction of in-vehicle data based on encrypted links; The vehicle terminal generates corresponding business data, including location information and sensor data. The data is transmitted to the gateway through an established encrypted link. The SSL processor decrypts the received business data and transmits the decrypted data to the processor link. The processor link parses the data sequentially through the decoder and the business processor and forwards the parsed data to the backend business system.

[0009] S5: Dynamically expands certificate authorities to connect new devices; The operations and maintenance personnel call the management interface provided by the runtime configuration update module to initiate a request to add a certificate authority to the system's runtime configuration update module; the request to add a certificate authority includes information about the new certificate authority and the certificate chain storage path. The runtime configuration update module receives the request and sends the new certificate authority information and certificate chain storage path to the multi-CA certificate management module. The multi-CA certificate management module loads the corresponding certificate chain according to the certificate chain storage path and creates an independent trust manager for the new certificate authority. The dynamic trust manager module adds the new certificate authority information and the corresponding trust manager to the internal mapping table; The SSL context configuration module reconstructs the SSL context based on the updated mapping table. For existing network connections, the original SSL context continues to be used, and communication is unaffected; for newly established network connections, the updated SSL context is used.

[0010] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention uses a dynamic TrustManager module to parse certificates and obtain issuing authority information, matches the corresponding trust manager from a preset internal mapping table, and uses the trust manager to complete certificate chain verification. It does not require traversing all CA root certificates, and the handshake time does not increase linearly with the number of CAs, effectively improving the performance of large-scale device access. This invention uses a unified server certificate and a single listening port to implement SSL handshake. The entire process uses only one IP port and one set of server certificates to complete the authentication of all clients. There is no need to allocate independent ports or domain names for different CAs, which does not occupy additional network resources or increase the cost of managing multiple domain names. At the same time, it is suitable for access scenarios where the device port / domain name is fixed and hardcoded, which greatly reduces the complexity of gateway deployment and operation and maintenance. This invention receives new CA requests through a runtime configuration update module, loads the new certificate chain and creates an independent trust manager through a multi-CA certificate management module, and synchronizes the new issuing authority information with the trust manager to the internal mapping table. The SSL context configuration module rebuilds the SSLContext. During the update process, existing connections maintain their original SSL context without interruption, and only new connections use the updated configuration. There is no need to restart the gateway service, thus meeting the high availability requirements. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the steps of the Netty-based multi-CA dynamic certificate verification TCP gateway implementation method proposed in this invention. Detailed Implementation

[0012] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0013] A Netty-based multi-CA dynamic certificate verification TCP gateway system includes a Netty server module, a unified server certificate module, a multi-CA certificate management module, a dynamic TrustManager module, a TrustManagerFactory wrapper module, an SSL context configuration module, and a runtime configuration update module. The Netty server module includes a terminal initializer, which is used to start the gateway, bind the listening port, receive client TCP connections, initialize the network connection channel through the terminal initializer, add an SSL processor and complete the establishment of an encrypted link. The unified server certificate module is used to store server certificates and private keys, and during the SSL handshake, it enables the gateway to send a server greeting message to the client to initiate the SSL handshake. The multi-CA certificate management module is used to load the certificate chain and create an independent trust manager for each certificate authority. The dynamic TrustManager module is used to parse client certificates, obtain certificate authority information, match the corresponding trust manager, and complete certificate verification. The TrustManagerFactory wrapper module is used to encapsulate the trust manager; The SSL context configuration module is used to build the SSL context and enable mandatory client certificate authentication. The runtime configuration update module is used to receive requests for new organizations and forward relevant information.

[0014] Please refer to the reference. Figure 1 This invention also proposes a method for implementing a multi-CA dynamic certificate verification TCP gateway based on Netty, the method comprising the following steps: S1: Start the gateway and initialize the modules; The Netty server module starts the gateway and triggers the initialization of each module in the system; after the module initialization is complete, the Netty server module binds to the communication port configured on the gateway and listens for network connections. Specifically, the unified server certificate module initializes and loads the server certificate and private key; the multi-CA certificate management module initializes and creates independent trust managers for each certificate issuer according to the configuration; the dynamic TrustManager module establishes the mapping relationship between issuers and trust managers; the TrustManagerFactory wrapper module encapsulates and adapts the trust managers; the SSL context configuration module builds the SSL context and enables mandatory client certificate authentication; after the module initialization is completed, the Netty server module binds to and listens on the specified TCP port, waiting for client connections.

[0015] S2: The client initiates a TCP connection, the gateway receives the connection and initializes the channel; When the Netty server module listens for a TCP connection request from a client to the gateway through the communication port, it receives the TCP connection request through the ServerBootstrap and initializes the processor link pipeline for each network connection channel through the TerminalChannelInitializer.

[0016] S3: Perform SSL secure handshake authentication; Includes the following sub-steps: S31: Determine if SSL is enabled; The SSL is Secure Sockets Layer; The terminal initializer in the Netty server module determines whether the SSL context configuration module has successfully built and holds a valid SslContext instance. If it has been successfully built and held, SSL is determined to be enabled, and the process proceeds to step S32; otherwise, SSL is determined to be disabled, and the process proceeds to step S4. S32: Add an SSL processor; If SSL is enabled, the TerminalChannelInitializer in the Netty server module adds an SSL handler (SslHandler) to the beginning of the processor pipeline. The SSL handler (SslHandler) uses an SslContext instance built by the SSL context configuration module. S33: SSL handshake interaction, client certificate verification and link establishment; S331: Initiate the SSL handshake and request the client to upload its certificate; The gateway uses the SSL processor to call the pre-loaded server certificate and private key in the unified server certificate module, and sends a server greeting message to the client to initiate the SSL handshake. The SSL processor sends a Certificate Request message to the client, requesting the client to submit its own client certificate. The client responds to the request and uploads its client certificate and certificate chain, wherein the client certificate is issued by a vehicle terminal certificate authority or similar body. S332: The SSL processor calls the dynamic trust manager module to verify the client certificate; The dynamic trust manager module calls the checkClientTrusted method to parse the client certificate, obtain the certificate authority information, and match the corresponding trust manager from the internal mapping table stored in the dynamic trust manager module based on the certificate authority information. The internal mapping table contains the correspondence between certificate authority information and trust managers. The dynamic trust manager module will match and compare the certificate authority information obtained from the client certificate with the multiple pre-configured certificate authority information in the internal mapping table one by one. When an entry that is completely consistent with the current certificate authority information is found, the trust manager corresponding to that entry will be selected. The dynamic trust manager module uses the trust manager to verify the digital signature, validity period, and integrity of the certificate chain uploaded by the client. If the verification passes, the SSL processor establishes an encrypted link between the gateway and the vehicle client; if the verification fails, the handshake is terminated and the connection between the two parties is disconnected. The certificate chain contains certificates at various levels and certificate information at each level. The certificate information at each level includes the corresponding digital signature, validity period, public key of the superior certificate, and other information. Specifically, the trust manager retrieves certificates from the certificate chain level by level and obtains the corresponding public key of the superior certificate from the certificate information at each level. It then uses the public key of the superior certificate to decrypt the digital signature corresponding to the current certificate to obtain the original hash digest. The trust manager recalculates the hash digest of the current certificate content. If the original hash digest and the hash digest are consistent, the digital signature verification is successful; otherwise, the digital signature verification is unsuccessful. The trust manager compares the validity period of the certificate chain with the current system time. If the current system time is within the validity period, the validity period verification passes; otherwise, the validity period verification fails. The trust manager traverses the certificates at each level of the certificate chain in sequence. If there are no gaps in the chain, the certificate integrity check passes; otherwise, the certificate integrity check fails.

[0017] S4: Secure transmission and interaction of in-vehicle data based on encrypted links; The vehicle terminal generates corresponding business data, including location information and sensor data. The data is transmitted to the gateway through an established encrypted link. The SSL processor decrypts the received business data and transmits the decrypted data to the processor link. The processor link parses the data sequentially through the decoder and the business processor and forwards the parsed data to the backend business system.

[0018] S5: Dynamically expands certificate authorities to connect new devices; The operations and maintenance personnel call the management interface provided by the runtime configuration update module to initiate a request to add a certificate authority to the system's runtime configuration update module; the request to add a certificate authority includes information about the new certificate authority and the certificate chain storage path. The runtime configuration update module receives the request and sends the new certificate authority information and certificate chain storage path to the multi-CA certificate management module. The multi-CA certificate management module loads the corresponding certificate chain according to the certificate chain storage path and creates an independent trust manager for the new certificate authority. The dynamic trust manager module adds the new certificate authority information and the corresponding trust manager to the internal mapping table; The SSL context configuration module reconstructs the SSL context based on the updated mapping table. For existing network connections, the original SSL context continues to be used, and communication is unaffected; for newly established network connections, the updated SSL context is used.

[0019] This invention encapsulates the trust manager through the TrustManagerFactory wrapper module, injects the SSL context configuration module to build the SSL context, and adds the SSL processor in the channel processor link by the Netty server module, deeply adapting to Netty native components and making full use of Netty's asynchronous event-driven features.

[0020] This invention enables accurate and rapid verification of multiple CA client certificates under the same port and unified server certificate. It supports dynamic expansion of CAs at runtime without interrupting business operations. It is deeply adapted to Netty asynchronous architecture, has low resource consumption, strong compatibility and scalability, significantly reduces operation and maintenance costs and ensures high availability, and comprehensively solves the efficiency, cost and availability problems of TCP gateway access in multi-CA scenarios.

[0021] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for implementing multi-CA dynamic certificate verification TCP gateway based on Netty, characterized in that: Includes the following steps: S1: Start the gateway and initialize the modules; The Netty server module starts the gateway and triggers the initialization of each module in the system; after the module initialization is complete, the Netty server module binds to the communication port configured on the gateway and listens for network connections. S2: The client initiates a TCP connection, the gateway receives the connection and initializes the channel; S3: Perform SSL secure handshake authentication; S31: Determine if SSL is enabled; S32: Add an SSL processor; S33: SSL handshake interaction, client certificate verification and link establishment; S4: Secure transmission and interaction of in-vehicle data based on encrypted links; S5: Dynamically expands certificate authorities to connect new devices.

2. The method for implementing a multi-CA dynamic certificate verification TCP gateway based on Netty as described in claim 1, characterized in that: In step S2, when the Netty server module listens for a TCP connection request from a client to the gateway through the communication port, it receives the TCP connection request through the ServerBootstrap and initializes the processor link pipeline for each network connection channel through the TerminalChannelInitializer.

3. The method for implementing a multi-CA dynamic certificate verification TCP gateway based on Netty as described in claim 1, characterized in that: The specific details of step S3 are as follows: S31: Determine if SSL is enabled; The SSL is Secure Sockets Layer; The terminal initializer in the Netty server module determines whether the SSL context configuration module has successfully built and holds a valid SslContext instance. If it has been successfully built and held, SSL is determined to be enabled, and the process proceeds to step S32; otherwise, SSL is determined to be disabled, and the process proceeds to step S4. S32: Add an SSL processor; If SSL is enabled, the terminal initializer in the Netty server module adds an SSL processor to the header of the processor pipeline. The SSL processor uses an SslContext instance built by the SSL context configuration module. S33: SSL handshake interaction, client certificate verification and link establishment.

4. The method for implementing a multi-CA dynamic certificate verification TCP gateway based on Netty as described in claim 3, characterized in that: The specific details of step S33 are as follows: S331: Initiate the SSL handshake and request the client to upload its certificate; The gateway uses the SSL processor to call the pre-loaded server certificate and private key in the unified server certificate module, sends a server greeting message to the client, and initiates the SSL handshake. The SSL processor sends a certificate request message to the client, requesting the client to submit its own client certificate; The client responds to the request and uploads its client certificate and certificate chain; S332: The SSL processor calls the dynamic trust manager module to verify the client certificate; The dynamic trust manager module calls the checkClientTrusted method to parse the client certificate, obtain the certificate authority information, and match the corresponding trust manager from the internal mapping table stored in the dynamic trust manager module based on the certificate authority information. The internal mapping table contains the correspondence between issuing authority information and trust managers; The dynamic trust manager module will match and compare the certificate authority information obtained from the client certificate with multiple pre-configured certificate authority information in the internal mapping table one by one. When an entry that is completely consistent with the current certificate authority information is found, the trust manager corresponding to that entry will be selected. The dynamic trust manager module uses the trust manager to verify the digital signature, validity period, and integrity of the certificate chain uploaded by the client. If the verification passes, the SSL processor establishes an encrypted link between the gateway and the vehicle client. If the verification fails, the handshake will terminate and the connection between the two parties will be broken. The certificate chain contains certificates at each level and information about each level of certificates. The information about each level of certificates includes the corresponding digital signature, validity period, and public key information of the superior certificate.

5. The method for implementing a multi-CA dynamic certificate verification TCP gateway based on Netty as described in claim 1, characterized in that: In step S4, the vehicle terminal generates corresponding service data, which includes location information and sensor data. The data is transmitted to the gateway via the established encrypted link. The SSL processor decrypts the received business data and transmits the decrypted data to the processor link. The processor link then parses the data sequentially through the decoder and the business processor and forwards the parsed data to the backend business system.

6. The method for implementing a multi-CA dynamic certificate verification TCP gateway based on Netty as described in claim 1, characterized in that: In step S5, the operations and maintenance personnel call the management interface provided by the runtime configuration update module to initiate a request to add a certificate authority to the system's runtime configuration update module; the request to add a certificate authority includes information about the new certificate authority and the certificate chain storage path; The runtime configuration update module receives the request and sends the new certificate authority information and certificate chain storage path to the multi-CA certificate management module; The multi-CA certificate management module loads the corresponding certificate chain according to the certificate chain storage path and creates an independent trust manager for the new certificate authority. The dynamic trust manager module adds the new certificate authority information and the corresponding trust manager to the internal mapping table; The SSL context configuration module reconstructs the SSL context based on the updated mapping table. For existing network connections, the original SSL context continues to be used, and communication is unaffected; for newly established network connections, the updated SSL context is used.

7. A Netty-based multi-CA dynamic certificate verification TCP gateway system for implementing the method of any one of claims 1-6, characterized in that: It includes the Netty server module, unified server certificate module, multi-CA certificate management module, dynamic TrustManager module, TrustManagerFactory wrapper module, SSL context configuration module, and runtime configuration update module; The Netty server module includes a terminal initializer, which is used to start the gateway, bind the listening port, receive client TCP connections, initialize the network connection channel through the terminal initializer, add an SSL processor and complete the establishment of an encrypted link. The unified server certificate module is used to store server certificates and private keys, and during the SSL handshake, it enables the gateway to send a server greeting message to the client to initiate the SSL handshake. The multi-CA certificate management module is used to load the certificate chain and create an independent trust manager for each certificate authority. The dynamic TrustManager module is used to parse client certificates, obtain certificate authority information, match the corresponding trust manager, and complete certificate verification. The TrustManagerFactory wrapper module is used to encapsulate the trust manager; The SSL context configuration module is used to build the SSL context and enable mandatory client certificate authentication. The runtime configuration update module is used to receive requests for new organizations and forward relevant information.

Images