Certificate Fallback Authentication for Secure Session Continuity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The publication of a new issuer certificate can cause delays in secure communication sessions, particularly in critical systems like Business Continuity and Disaster Recovery (BCDR), as entities may update their certificates at different times, leading to authentication failures and interruptions in services such as incremental backups or financial transactions.

Innovation Solution

A system and method that store both current and old issuer digital certificates and corresponding entity digital certificates, allowing for fallback authentication during new issuer certificate implementation latency, with the backup entity checking for updates more frequently than the client entity to ensure continuous secure communication sessions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If entities update their certificates at different times during issuer certificate rollout, then certificate validity is maintained, but authentication failures occur causing service interruptions

Engineering Contradiction:
Improveauthentication success rateVSAvoidcertificate update timing flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system performs preliminary actions by storing multiple versions of issuer certificates and entity certificates before the actual certificate rollout. Each entity maintains a certificate store containing both the old issuer certificate and the new issuer certificate, along with corresponding entity certificates signed by each. This preliminary preparation ensures that when certificate updates occur at different times, authentication can succeed using the appropriate certificate version, preventing service interruptions.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If the backup entity checks for certificate updates more frequently than the client entity, then continuous secure communication is ensured, but communication latency and overhead increase

Engineering Contradiction:
Improvecontinuous secure communicationVSAvoidcertificate checking time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements periodic action through asymmetric certificate checking intervals. The backup entity checks for certificate updates at a first cadence (more frequently), while the client entity checks at a second cadence (less frequently). This periodic checking strategy ensures that the backup entity maintains up-to-date certificates to initiate secure sessions, while reducing the overall system overhead by not requiring both entities to check at the same high frequency. The differential periodic action maintains reliability while minimizing time loss.

Inventive Principle:
Principle #19Periodic action

Data Source

PatentUS11509487B2System for rollout of certificates to client and server independent of public key infrastructure
Publication Date: 2022.11.22 DATTO LLC
  • US11509487B2 patent drawing
  • US11509487B2 patent drawing
  • US11509487B2 patent drawing

AI summary

A first entity stores an issuer digital certificate published by a certificate authority (CA) and signed by the issuer certificate; and also stores an old issuer digital certificate published by the CA prior to publication of the issuer digital certificate and an old first entity digital certificate signed by the old issuer digital certificate. The first entity attempts to initiate a secure communication session with a second entity by receiving a second entity digital certificate from the second entity via an electronic network, and sending either the first entity digital certificate or the old first entity digital certificate to the second entity based on which of the issuer digital certificate or the old issuer digital certificate is effective to authenticate the second entity digital certificate received from the second entity. The secure communication session is conducted only if the attempt to initiate the secure communication session is successful.