# US 12,015,690 B2 · Automated validation of data sources in a managed network > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 12,015,690 B2 - Document ID: US12015690B2 - Status: Granted - Kind: B2 - Application number: 17/668,192 - Filed: 2022-02-09 - Published: 2023-08-10 - Granted: 2024-06-18 - Earliest claimed: 2022-02-09 - Assignees: Ivanti, Inc. - Applicants: Ivanti, Inc. - Inventors: Gregory Paul Olsen; Blake Alan Thompson; Tanner Reese Lindsay - Web page: https://patentgrep.com/patent/US12015690B2 ## CPC - H04L 9/006: {involving public key infrastructure [PKI] trust models (network architecture or network communication protocol for supporting authentication of entities using certificates in a packet data network H04L63/0823)} - H04L 9/3265: {using certificate chains, trees or paths; Hierarchical trust model} - H04L 9/3268: {using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]} - H04L 63/0823: {using certificates (cryptographic mechanisms or cryptographic arrangements for entity authentication involving certificates H04L9/3263)} - H04L 63/166: {at the transport layer} - H04L 67/1091: {Interfacing with client-server systems or between P2P systems} - H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M) ## Abstract An embodiment includes a method of client-server trust management. The method includes receiving, at a client device, a public key of a system server and locally seeding the public key in a secure storage at the client device. The method includes receiving a certificate list signed by a private key of the system server and verifying a source of the certificate list using the seeded public key. The method includes initiating a handshake process with a second device during which a digital device certificate of the second device is received. The method includes halting the handshake process and validating the second device by matching the digital device certificate with a certificate included on the verified certificate list. Based on the validation, the method includes managing a communication session with the second device to enable or prevent data transfer between the client device and the second device. ## Claims ### Claim 1 A method of client-server trust management, the method comprising: receiving, at a client device, a public key of a system server; locally seeding the public key in a secure storage at the client device, wherein the seeding occurs when an agent is loaded on the client device; receiving a certificate list signed by a private key of the system server, the certificate list including one or more trusted device certificates associated with devices that are trusted by the system server; verifying a source of the certificate list using the seeded public key; initiating a communication session handshake process between the client device and a second device; receiving during the handshake process, a digital device certificate of the second device; halting the handshake process with the second device; during the halted handshake process, validating the second device using the digital device certificate of the second device based on the received certificate list having the verified source, the validating including: matching the received digital device certificate with one of the one or more trusted device certificates; responsive to a failure to match the received digital device certificate with the one or more trusted device certificates on the certificate list: communicating to the system server a request for a current certificate list, wherein the current certificate list includes one or more current trusted device certificates, and wherein the current certificate list is signed by the private key of the system server; verifying, by the client device, a signature on the current certificate list using the seeded public key; and reattempting to match the received digital device certificate of the second device with one of the one or more current trusted device certificates on the current certificate list; and based on the validating of the second device, managing a communication session with the second device to enable data transfer and performance of an operation by the client device. ### Claim 2 (depends on 1) The method of claim 1, wherein the validating further includes responsive to a successful match during the reattempt: identifying the second device as a trusted device; continuing the handshake process; communicating data with the second device related to the operation; and performing the operation. ### Claim 3 (depends on 1) The method of claim 1, further comprising responsive to a mismatch during the reattempt: identifying the second device as an untrusted device; and discontinuing the handshake process, wherein the re-attempt occurs only once. ### Claim 4 (depends on 1) The method of claim 1, wherein the communication session handshake process includes: a transport layer security (TLS) handshake process; or a secure sockets layer (SSL) handshake process. ### Claim 5 (depends on 1) The method of claim 1, further comprising: receiving core data from the system server, the received core data being signed by the private key of the system server; and validating the received core data using the seeded public key to ensure the received core data originates at the system server. ### Claim 6 (depends on 1) The method of claim 1, wherein the initiating the handshake process includes directly accessing the second device using an internet protocol address of the second device without a domain name system (DNS) name of the second device. ### Claim 7 (depends on 1) The method of claim 1, further comprising caching the received certificate list at the client device, wherein the received certificate list is cached for a particular period of time. ### Claim 8 One or more non-transitory computer-readable media storing one or more programs that are configured, in response to execution by one or more processors, to cause a system to execute or control execution of operations, the operations comprising: receiving, at a client device, a public key of a system server; locally seeding the public key in a secure storage at the client device, wherein the seeding occurs when an agent is loaded on the client device; receiving a certificate list signed by a private key of the system server, the certificate list including one or more trusted device certificates associated with devices that are trusted by the system server; verifying a source of the certificate list using the seeded public key; initiating a communication session handshake process between the client device and a second device; receiving during the handshake process, a digital device certificate of the second device; halting the handshake process with the second device; during the halted handshake process, validating the second device using the digital device certificate of the second device based on the received certificate list having the verified source, the validating including: matching the received digital device certificate with one of the one or more trusted device certificates; responsive to a failure to match the received digital device certificate with the one or more trusted device certificates on the certificate list: communicating to the system server a request for a current certificate list, wherein the current certificate list includes one or more current trusted device certificates, and wherein the current certificate list is signed by the private key of the system server; verifying, by the client device, a signature on the current certificate list using the seeded public key; and reattempting to match the received digital device certificate of the second device with one of the one or more current trusted device certificates on the current certificate list; and based on the validating of the second device, managing a communication session with the second device to enable data transfer and performance of an operation by the client device. ### Claim 9 (depends on 8) The non-transitory computer-readable media of claim 8, wherein the validating further includes responsive to a successful match during the reattempt: identifying the second device as a trusted device; continuing the handshake process; communicating data with the second device related to the operation; and performing the operation. ### Claim 10 (depends on 8) The non-transitory computer-readable media of claim 8, wherein the operations further comprise responsive to a mismatch during the reattempt: identifying the second device as an untrusted device; and discontinuing the handshake process, wherein the re-attempt occurs only once. ### Claim 11 (depends on 8) The non-transitory computer-readable media of claim 8, wherein the communication session handshake process includes: a transport layer security (TLS) handshake process; or a secure sockets layer (SSL) handshake process. ### Claim 12 (depends on 8) The non-transitory computer-readable media of claim 8, wherein the operations further comprise: receiving core data from the system server, the received core data being signed by the private key of the system server; and validating the received core data using the seeded public key to ensure the received core data originates at the system server. ### Claim 13 (depends on 8) The non-transitory computer-readable media of claim 8, wherein the initiating the handshake process includes directly accessing the second device using an internet protocol address of the second device without a domain name system (DNS) name of the second device. ### Claim 14 (depends on 8) The non-transitory computer-readable media of claim 8, wherein the operations further comprise caching the received certificate list at the client device, wherein the received certificate list is cached for a particular period of time.