AN ADDICTION GRAPH-BASED CERTIFICATION SYSTEM

Abstract

This invention relates to a system (1) that enables the automatic resolution of certificate-related trust relationship problems by monitoring the dependencies between digital certificates and the trust repositories and services in which they are used.

Description

1 TARIFF AN ADDICTION GRAPH-BASED CERTIFICATION SYSTEM Technical Area This invention relates to digital certificates and the trust vaults and services in which they are used. 5 by monitoring the dependencies between them, trust relationship problems arising from certificates It relates to a system that enables automatic resolution. Previous Tech 10 Current systems generally use the following methods: • Periodically checking the certificate expiration date, • Generating an email or alarm before the time limit expires, 15 • Automatic renewal of the certificate from the certificate authority, • Uploading the renewed certificate to the server or load balancer, • Automatic certificate generation in Kubernetes environments. renewal, • Certificates and keys are stored in central vaults, 20 • Manually updating Truststore and certificate files, • TLS errors are reviewed by operations teams via logs. cert-manager, Kubernetes, and OpenShift are included in the known state of the art. Certificates are created for shipments and renewed before their expiration date. 25 However, the core function of cert-manager is certificate generation and lifecycle management. It is the administration. 2 The following technical deficiencies exist in the known state of the art: • Even though the certificate has been renewed, the application continues to store the old certificate in memory. • Mounting an older version of the secret instead of the current one, • The certificate is correct but the truststore is missing, 5 • One TLS terminator offering a different certificate than others, • Selecting a different certificate due to an incorrect SNI or route, • Which services and customer operations will be affected by the same certificate error inability to determine, • There is a true causal relationship between the log error and the infrastructure change. inability to establish • The fix could not be tested with different client profiles before production, • Inability to perform automatic rollback after faulty automation, • Inability to demonstrate the level of confidence and uncertainty in the system decision. Additionally, if the technique is known, scanning the certificates on the network, certificate creating records, identifying certificates that are about to expire, and renewal creating the request and installing the renewed certificate on the target server. providing service calls, active TLS tests, configuration and runtime deriving a dynamic dependency graph from the data in this form, certificate 20 that simply being distributed is not considered sufficient; that it is installed by the application Verify that it is not installed and whether it works with client truststores. Various solutions have been found that provide this. However, under the known state of the art, the certificate is only issued if it has been distributed and 25 Not that it doesn't exist; it's the expected, mounted, runtime loaded, and live TLS. joint verification of the certificate statuses observed in the connection, Certificate / Truststore changes are not made in a single step, but are based on the Trust Epoch. It should be implemented through the “PREPARE–COMMIT–RETIRE” process and be dependent on the same 30 that ensures the new trust status is not activated until the services are ready 3 Detecting different trust versions in the service group using trust split-brain. and only faulty / stale instances are selectively removed from traffic Among the possible fixes for a TLS error, improvement refers to failed trust. Calculation of a repair set with minimum technical impact that improves the roads, The new trust domain created after the truststore change is defined as “trust-surface delta” with a value of 5. control and actions that unnecessarily expand the trust area preventing the new trust status from being established after the change, runtime TLS Proven by verification and, if necessary, only on the platform instead of the entire platform. Enables selective rollback to be applied to affected targets. No solutions are being found. 10 United States Regulation US2022239503A1, which is included in the known state of the art. patent document container arrangement systems services certificate, key This describes the automatic management of repository and trust repository information. 15 In the system, the certificate issuer detects the certificate request for the service and issues the certificate. Obtaining the certificate and private key information from the cloud certificate manager, it is kept confidential. It saves the data to storage and provides the relevant storage location to the service. Additionally, the certificate issuer has a certificate, key store, and trust store. Monitoring creation and update events in resources; a service's own 20 Trust is established by using certificates of upper and lower services linked through a certificate chain. creating a repository and storing that trust repository secretly in the cloud environment. The transfer to storage is explained. A security breach related to a service has been detected. when done, key and trust stores are recreated with new certificates and the restart of the related services are also described. By the user 25 In addition to obtaining and storing the certificate, confidentiality is also required in the provided requests. The storage area can be a key repository or a secure repository, and the system It is explicitly protected that it can operate in a container management environment. 4 However, the document in question, US2022239503A1, states that the certificate only... It's not about whether it's distributed or not; it's about what's expected, mounted, loaded at runtime, and from the simultaneous verification of certificate statuses observed in the live TLS connection, Certificate / Truststore changes are not made in a single step, but are based on the Trust Epoch. It is carried out through the “PREPARE–COMMIT–RETIRE” process and the dependent 5 not activating the new trust status before the services are ready It is not mentioned. Brief Description of the Invention 10 The purpose of this invention is to determine, in this case, whether the certificate has been distributed or not. No; it's expected, mounted, loaded at runtime, and on a live TLS connection. verifying the observed certificate statuses together, certificate / truststore The changes are not implemented in a single step, but rather through the Trust Epoch-based “PREPARE–COMMIT–15 This should be done through the "RETIRE" process, and new services should not be launched before dependent services are ready. different services within the same service group that prevent the trust status from being activated The trust versions are detected as trust split-brain and only faulty / stale versions are allowed to be detected. Selectively removing instances from traffic and rehabilitating them, for a TLS error Among the possible fixes, the minimum technical 20 that corrects the failed trust paths. Calculating the set of repairs that have an impact after a truststore change. The newly formed trust area should be controlled with "trust-surface delta" and unnecessary elements should be removed. preventing actions that expand the sphere of trust in this way, changes subsequently, the new state of trust must be proven with runtime TLS verification, and Selective rollback on affected targets instead of the entire platform when needed 25 a dependency graph-based certificate that enables implementation The goal is to implement the system. Detailed Description of the Invention 30 To achieve the purpose of this invention, an "Addiction Graph-Based Analysis" was carried out. The "Certification System" is shown in the diagram; Figure 1 Schematic of a dependency graph-based certificate system, the subject of the invention. 5 It is the appearance. The parts shown in the figure are individually numbered, and the corresponding numbers correspond to these numbers. It is given below. 1. System 2. Data collection server 3. Analytics server Digital certificates and the trust vaults and services where they are used. Automated identification of certificate-related trust issues by monitoring dependencies. a certificate based on the dependency graph that enables the elimination of the invention. system (1); - Connecting with various services, platforms, and communication infrastructures, certificate 20 and numerous issues related to identifying truststore problems. to ensure that technical data is collected, including the certificate serial number. Certificate fingerprint, Validity start and end dates, Certificate authority, Subject and Subject Alternative Name fields, Public key and signature algorithm, Certificate Certificate chain, certificate revocation status, endpoints and services where the certificate was used 25 Collecting Certificate and Certificate Authority Inventory data in this form, on Truststore file path, Truststore type, File hash value, Alias ​​list, Included root and intermediate certificates, Secret name and version, Secret update time, Volume and Mount information, truststore parameters used by the application, file access and The trust base in the form of readability status and the collection of confidential data 30 6 to ensure, certificate expiration, hostname and SAN mismatch, Inability to create a valid certificate chain, Missing intermediate certificate, Untrusted root. certificate, Empty or unopenable truststore, Incorrect truststore password, TLS protocol or cipher mismatch, private key and certificate mismatch error in TLS and to enable the collection of data in the form of application logs, on 5 Deployment and pod versions, Container status, Secret, and ConfigMap. References, Volume and mount path information, Instance startup time, Application Restart and reload information, certificate fingerprint used during runtime, Server and system clock, JVM or application startup parameters Enabling Kubernetes and Server Health data collection, on NS 10 Records, route and ingress definitions, virtual host information, SNI mapping rules, TLS termination type, endpoint and port information, and relevant certificate assignments. Enabling the collection of data such as Route, DNS and SNI Settings, Service call traces, client and server relationships, deployment times, certificates. Renewal records, Secret updates, Route and DNS changes, Restart and 15 Reload operations, manual operation logs, and previous rollback information are all traceable data. To enable the collection of data in the form of (Trace) and Change Records. at least one data collection server (2) is configured and - connects to the data collection server (2), on the data collection server (2) The collected Certificate and Certificate Authority Inventory data is from Truststore and Secret 20 Data, TLS and Application Logs, Kubernetes and Server Status data, Route, DNS and SNI settings, Trace and Change Logs to enable the analysis of the data, to enable at least one data Running the data collection and normalization module, data collection and normalization. 25 on the data sent from the data collection server (2) with the module Checks should be carried out by local agents, errors from different applications. converting the texts into common error classes, as defined in the configuration. the certificate can be compared with the certificate that the application is actually using, The correct certificate file is created using data collected from Route, DNS, and SNI settings. Despite being found, a different certificate was issued due to an incorrect route or SNI rule. 7 to enable its use in identifying problems such as the presentation of inter-service calls collecting changes made in relationships and infrastructure, thereby enabling TLS which change caused the error to start and whether the change affected the error. to determine whether there is a causal effect, data collection on it and Certificate and 5 transmitted from the data collection server (2) with the normalization module Certificate Authority Inventory data, Truststore and Secret data, TLS and Application logs, Kubernetes and server health data, routing, DNS, and SNI settings, trace data, and change logs form a common dataset. conversion to the model in the aforementioned data collection and normalization module Extraction of certificate fingerprints, 10 duplicate records belonging to the same certificate merging, converting timestamps to a common time format, Log categorizing messages into error classes, Service, endpoint, certificate and trust. Matching repository identities, missing or outdated data. To ensure that data sources are marked and a data quality score is calculated for each data source. then, both event 15 on the data obtained as a result of normalization To ensure that the data is transferred to both the database and the dependency graph database, then the storage and association module on it should be run, storage and Event Database and Dependency Graph within the association module Ensuring the database is operational requires a step in the storage and association module. Event database TLS connection results, Handshake error rates, Application error 20 records, certificate expiration information, Truststore verification results, deployment and Change times, Synthetic test results, Canary metrics, Rollback records, Time-based technical events and measurements in the form of human approval and rejection outcomes Ensuring storage, Dependency in the storage and association module. The Graph Database displays technical assets and their relationships in a graph structure. to ensure it is stored, then with the causality and scoring module on it. at least running a scoring engine, the scoring engine and its telemetry Dependency graph of the database and error analysis by retrieving data from the database. implementation, score engine certificate and truststore anomalies determining, comparing the expected situation with the actual situation, possible root 30 8 the formation of reasons, the calculation of risk and impact area, decision confidence and Identifying the uncertainty and outlining the possible corrective actions. to provide, with the deviation and error detection module in the causality and scoring module. The certificate expected to be used in the configuration is on Secret or mount. The certificate found is the same as the certificate used by the application during runtime. comparing the information, and the certificate validity period is critical through the comparison process. Level issues, SAN and hostname mismatch, missing certificate chain, Truststore Lack of the necessary certificate, Incorrect secret version, Different sessions (Instance) using a different certificate, Incorrect SNI or route matching, System clock 10 deviations, such as deviations in the form of TLS protocol incompatibility, can be detected. to provide, the Risk Score located in the causality and scoring module on it. The calculation module assigns a risk between 0 and 100 to each potential error or risk. the calculation of the score, found in the causality and scoring module on it Multiple root causes related to the errors identified by the Root Cause Analysis module. to ensure the candidate is produced, the candidate with the highest score is identified as the root cause with 15 If multiple candidates receive close scores, the uncertainty score will be higher for their selection. to enable its upgrade, live with the Digital Twin and Synthetic Test module on it. creating a technical copy of the certificate and trust relationships in the environment, root why the correction suggestion generated by the engine is first on the digital twin If the error disappears after the correction, then the root cause is considered to be identified. To improve its score, the Digital Twin and Synthetic Test module on it Correction applied to the digital twin using the Synthetic TLS Test Engine within it To enable testing whether it works under different client conditions, Current And clients using the old truststore, different SNI values, true and false. Hostname, Missing intermediate certificate chain, Different TLS protocol versions, Different cipher 25 Sets, Clients with time discrepancies, Different networks and geographic regions, Old secrets or synthetic discrepancies in certificate version, private key, and certificate. enabling the generation of scenarios, bidirectional digital twin and synthetic test engine. his study, a new error found during testing, was added to the digital twin model. transfer, and the new correction made to the digital twin will also be re-submitted to synthetic tests 30 9 to ensure its submission, policy in the Decision and Approval Mechanism the use of the engine, digital twin and synthetic test with the policy engine evaluating the results and deciding how to proceed with the action to ensure that the policy engine, with the same TLS error, has lower confidence expansion and When an alternative is found that corrects with a smaller area of ​​change, a larger 5 To prevent the system from automatically selecting comprehensive repair, use "trust-surface delta". If it exceeds the policy boundary, the action should be directed towards human approval or, more narrowly, towards a narrower approach. to ensure comprehensive repair is sought, policy engine that reduces safety automatic blocking of actions, certificate verification Closing or trusting all certificates is a normal automated action 10 to ensure that it cannot be implemented as such, in the Decision and Approval Mechanism Automatic Canary with confidence and uncertainty decision point function The application involves submitting to human approval, generating solution proposals, collecting additional data, and to ensure that decisions are made to prevent the action, on Action Orchestration and Target Services module with Action Orchestration 15 feasible technical steps of the remediation plan selected by the policy engine conversion, actions API calls, configuration management tools, Kubernetes / OpenShift APIs, Deployment automation, Certificate management Platform integration, script or runbook automation, RPA robots. to ensure that it is carried out using methods such as these, 20 in Action Orchestration Certificate renewal, Adding missing intermediate certificate to the chain, Root or intermediate certificate to Truststore Adding certificates, updating secret version, correcting incorrect mount path, Apply a hot reload to the application, restart the problematic instance, or use SNI. Correcting route matching, assigning the certificate to the load balancer. To enable the implementation of processes, Action Orchestration and Target Services 25 With this module, the selected action's certificate vault, truststore, or keystore, Kubernetes / OpenShift secret object, Application pod, Virtual or physical server, API Gateway, Load balancer, Reverse proxy, Route or ingress, WebLogic or application to one or more of the targets in the form of an application server to ensure that the change is not applied directly to the entire platform / service, but only for the first 30 as the smallest and most representative target group possible to ensure it is selected, within the Verification and Automatic Rollback module on it. canary verification is performed, correction is applied in canary verification. Then, LS handshake success rate, certificate verification error rate, application error rate. Rate, Critical operation success rate, Connection latency, Instance health status, New 5 Certificate fingerprint usage rate, connection result of different client profiles. Ensuring that metrics such as these are monitored, before and after the change. Enabling comparison of metrics, Validation and Automatic Rollback module. The metrics measured by the Metric Decision Point within it are defined in the policy engine. To ensure that it is within the limits, Metrics limits 10 If it is within a limited instance, the change is considered successful. to the group, then to specific traffic rates, and finally to the entire target system. To ensure the changes spread gradually, from each phase of diffusion. then ensure that health checks are performed again, Metrics If it goes beyond the limits, an automatic rollback will be initiated, and during the rollback 15 The modified target is removed from traffic, the previous certificate, truststore or Restoring the secret version, previous route or configuration Implementation, performing the necessary restart or reload, old certificate Verification of fingerprint reuse, TLS and critical operation testing. To enable the process of restarting, Rollback 20 To ensure that the result is sent to the learning layer as a failed action, The verification should be based not only on the service health metric, but also on the performance of the new trust version. To ensure it also relies on whether it was actually activated in a timely manner, For successful propagation, the target session must use the expected trust epoch, Correct. The certificate or truststore must be mounted, ensuring the correct certificate is installed at runtime. This involves displaying the expected certificate fingerprint on a live TLS connection. to ensure that it demonstrates the following conditions, within the same service group only if certain sessions do not meet the conditions in question, then all Instead of reversing the spread, these sessions are being selectively quarantined. The old security version can only be obtained if critical services are stable in the new version 30. 11 After verification of its status, ensure it is switched to "RETIRE" status. Successful deployment of the Evidence Package and Self-Learning module. or the creation of a technical evidence package related to the incident following a rollback, evidence When the data package is created, the Event ID and time information, Affected certificate and Trust Store, Certificate fingerprints, Related logs and telemetry records, Dependency 5 The relevant section of the graph includes: Risk score, Root cause candidates, Confidence and uncertainty. scores, digital twin results, synthetic test results, policy engine decision, human Approval or rejection information, actions taken, pre- and post-change metrics. To enable the use of information such as Canary result and Rollback result. 10 in the evidence package audit, security review and post-failure analysis to enable its use, in the Evidence Package and Self-Learning module In self-learning processes, correctly identified root causes are incorrect. Positive alerts, Successful fixes, Failed fixes, Rollbacks Processes, Human-modified suggestions, Recurring errors, New error The results of the operation in the form of combinations are fed back into an AI model. to ensure that it is fed, so that the data collection server (2) communicates with it. Risk weights and root cause ranking related to certificates on the network, Action success probabilities, confidence thresholds, synthetic test scenarios. to ensure it is updated over time, including the Evidence Package and Self-Aid. Performing the federative learning processes included in the learning module, from one to 20 raw materials are used in excess of data centers, company units, or country environments. without the technical data being sent to him via the data collection server (2) To enable the implementation of "federated learning," each environment has its own local data. generating model updates on it, to central computing modules only anonymized model parameters should be sent, so that the different 25 While collaborative learning is achieved from error patterns in different environments, certification, service and protecting the confidentiality of infrastructure information, and the model being updated as a result of learning; artificial intelligence, causality, and sending it back to the scoring engine, thus closing it off. to ensure continuous improvement of decision accuracy within the cycle It includes at least one configured analytics server (3). 30 12 The invention concerns the Storage and Analysis Server (3) on the system (1) located in the invention system. Certificates are located within the Dependency Graph Database in the Association module. Certificate authority, Truststore, Secret, Application, Pod or server, Endpoint, DNS and the nodes in the form of SNI registration, Route, Client service, Critical operation flow are 5 the certificate being kept in a secret, the secret being a Adding it to the application, the application obtains the specific certificate at runtime. using, the endpoint providing a specific certificate, the client service using the relevant endpoint Calling, trusting the trusted store to a specific root certificate, critical operation. 10. It is structured accordingly. The invention concerns the Storage and Analysis Server (3) on the system (1) located in the invention system. With the association module, the technical data transmitted from the data collection server (2) The dependency graph created shows which services and processes are affected by a certificate error. to be used in determining how it can affect, configuration for each relationship, live traffic, certificate fingerprint, and relationship trust score based on time alignment the ability to create, graph nodes also active and expected trust version information that can be associated with application or instance nodes The expected certificate in the configuration, the mounted certificate, operation 20 the certificate that was uploaded on time and the certificate observed in the live TLS connection to enable them to be maintained as separate features, graph during certificate rotation. on it, for each consumer, “CURRENT_EPOCH”, “TARGET_EPOCH” and The graph should only store "READINESS_STATE" states, thus allowing for the preservation of only the "READINESS_STATE" states. Not in dependency analysis, but in which services the distributed trust transition is implemented. to ensure that it can also be used to track that it has reached the stage It is being structured. Score in the causality and scoring module on the analysis server (3) By starting the engine, the artificial intelligence learns from past events and creates similar 30 13 to enable the recognition of error patterns, but the results produced should not be used in policy making. to ensure that it is limited by rules and explainability mechanisms, Live with expected technical status via deviation and error detection module. by comparing the situation occurring in the environment and the different values ​​obtained. 5 as a deviation in certificate dissemination or operating time. It is structured to enable evaluation. Deviation and causality and scoring module on the analysis server (3) The error detection module ensures the security of different sessions using different certificates. to enable evaluation on a version basis, some 10 in the same service group The new trust version of the sessions ensures that others use the previous version. marking it as split-brain, in split-brain condition Certificate fingerprint, mount information, and live TLS proof for the erroneous or corrupted session. to be determined through and only the improvement objective of those sessions in question It is structured to enable its transformation. 15 Risk Score in the causality and scoring module on the analysis server (3) Calculation module for remaining certificate validity period, hostname mismatch, Certificate chain integrity, Truststore health status, Secret or mount deviation, Live TLS error rate, Number of affected services, Service criticality, Traffic volume, 20 Using factors such as recent changes, this used in high-traffic areas or critical payment processes. to ensure that the impact score of the certificates is calculated higher It is being structured. Risk Score in the causality and scoring module on the analysis server (3) with the calculation module and the technical data transmitted from the data collection server (2) In calculating the risk score for each relevant event, the formula is: “Risk Score = 0.18 × Time” Risk”, “Risk Score = 0.15 × Hostname Risk”, “Risk Score = 0.15 × Chain Risk”, 14 “Risk Score = 0.15× Truststore Risk”, “Risk Score = 0.12× Mount / Runtime "Deviation", "Risk Score = 0.10 × Live TLS Error Rate", "Risk Score = 0.10 × The different types of effects are "Service Effect" and "Risk Score = 0.05 x Last Change Proximity". using formulas, so that expired but non-critical Payment services' common network 5 with certificate not used by the platform preventing the certificate used at the border crossing from having the same risk value to ensure the number of services, traffic volume, and critical operations in the dependency graph. to improve the service impact score of the connection It is being structured. The root found in the causality and scoring module on the analysis server (3) The reason for the error identified by the cause analysis module is the expiration of the certificate. The certificate has been renewed but it is not being installed in the application, indicating that the trust store is required. not containing the root certificate, mounting the wrong secret version, 15 The application is keeping the old certificate in memory, which means the incorrect SNI rule is using a different certificate. generating sample candidates such as the selection being based on a faulty system clock. to ensure the error message regarding the candidates and the reason for the error are consistent, Candidate The component's position in the dependency graph, the time of error onset and change. Active TLS test results, Configuration and runtime data, Past 20 similar results. The events are evaluated using data in the form of digital twin intervention results. It is structured to provide this. Digital twin in the Digital Twin and Synthetic Test module on the Analysis server (3) Running the simulation within the digital twin: Certificates, Truststore 25 Contents, Secret versions, Mount definitions, Application instances, Route and SNI Rules, TLS terminators, Client-service relationships, Traffic distribution modeling the information in this form, the error being caused by the old certificate remaining in memory. If it is thought to have originated from there, reload the relevant session in the digital twin. 30 to ensure that the digital twin also simulates trust version transitions, a new trust The virtual stages for the period are "PREPARE", "COMMIT" and "RETIRE". the ability to conduct operations in the environment, especially with the new Trust Anchor, to inform consumers in advance whether adding it disrupts existing connections, and whether the new server certificate is active. which consumers were unable to connect and the old Trust Anchor 5 whether there are any remaining addictions after it is removed to enable evaluation, a confidence that the critical TLS path has been broken in the digital twin. to ensure that the version cannot be delivered to the live environment It is being structured. Certificate in the Digital Twin and Synthetic Test module on the analysis server (3) or if possible, actions that change the truststore trust status. not implemented step-by-step, a new trust for each trust change Creation of the Trust Epoch version and the transition with “PREPARE”, “COMMIT” and The process should be carried out as a controlled operation consisting of 15 stages of “RETIRE”. The certificate to be modified via the dependency graph during the REPARE phase, services, clients, and workflows that depend on the truststore or certificate chain determining the session times, root to be used in the new trust version The certificate, intermediate certificate, or truststore entries are primarily required from the consumer. distribution to platforms, at this stage existing and operational trust 20 The entries should not be removed, a new truststore for each critical consumer or session. or whether the certificate version reached the target system, the expected secret or Whether the mount version is being used, and whether the new trust version is working. whether it was actually loaded on time, with the candidate certificate chain or TLS or Whether the mTLS connection was established, Certificate 25 observed in the live connection. checks to see if the fingerprint matches the expected value It is structured to ensure its implementation. 16 One or more of the Digital Twin and Synthetic Test modules on the analysis server (3) if more critical dependencies are determined not to be ready for the new trust release The decision was made not to proceed to the "COMMIT" phase, to maintain the current state of trust, and COMMIT to ensure that unsuccessful consumers are subjected to a correction or review process. During this phase, all critical dependencies or those identified by the policy engine in phase 5 The identified mandatory critical cluster is ready for the new confidence release. The new certificate or trust configuration becomes active once verified. to ensure that it is brought up after the server or client certificate is changed It is important not to just look at the configuration record, but also to ensure the new certificate is working. It was actually loaded on time and the new certificate was in live TLS traffic. Verification that the permission was used, from sessions in the same service group. Some are using the new security version while others remain on the previous version. If detected, the situation should be marked as "trust split-brain," in which case all Instead of restarting the service group, only the old and faulty trust issues are resolved. In this case, the remaining sessions should be selectively included in the "remediation" process. 15 It is structured to provide this. Digital Twin and Synthetic Test module on the analysis server (3) During the "RETIRE" phase, the new trust version is stable in live traffic. It is working, critical clients can connect, and the expected certificate chain is 20 After its use has been verified, the previous trusted version will be retired. previous certificate, intermediate certificate or truststore entries that are no longer needed but only after the runtime verification of the new confidence status is complete removal, thus premature termination of the old trust relationship for the client preventing the disconnection of connections at any stage of the transition 25 If the verification fails, the transaction will not be considered complete. Enabling targets to be maintained at the previous trust version or to roll back when needed. to initiate the process, and also to ensure that the action to be taken is registered in a truststore. Before and after changes, if adding a new root or intermediate certificate is required. It is structured to enable the comparison of effective confidence sets. 30 17 Digital Twin and Synthetic Test module on the analysis server (3) During the “RETIRE” phase, the fix will be outside of the services associated with the error. The action is taken automatically if it is determined that unnecessary new trust relationships have been created. not applying it, seeking more limited alternative repairs, or the procedure being performed by human 5 sending it for approval, a TLS error can be resolved through multiple technical methods In cases where this can be resolved, the failed trust paths in the dependency graph can be re-evaluated. Comparison of candidate actions that enable their validation, Number of nodes to be modified, number of trust stores, instances requiring a restart or reload Number, traffic impact, service criticality, safety risk, and rollback cost 10 by evaluating the repair plan with the lowest possible technical impact. implementation, so that certificate and truststore changes are only applied. It's not based on the logic of "update the certificate and restart the service"; it's dependent. Preparing platforms for the new security situation, during operation Verification, controlled rollout to the new version, and only successful 15 Distributed and rollback, where the old trust status is removed after verification. to ensure that it is implemented as an accessible trust transition protocol It is being structured. Policy 20 within the Decision and Approval Mechanism on the Analysis Server (3) Risk score, Root cause confidence score, Uncertainty score, Service criticality, with its engine. Number of affected systems, Reversibility of the fix, Canary applicability, Maintenance window, Security policies, Success rate of previous similar actions, minimum trust repair set result, Trust-surface delta, Target trust epoch readiness rate, number of sessions found in Split-brain, 25 critical consumers to the new trust version to enable the evaluation of criteria such as readiness level It is being structured. Trust and included in the Decision and Approval Mechanism on the analysis server (3) If the Confidence score is above 85 using the uncertainty decision point function, then Uncertainty is 30. 18 If the score is below 15, the scope of the fix is ​​limited, a rollback operation will be performed. If possible, the correction should be done automatically if the digital twin and synthetic tests are successful. To ensure suitability for canary breeding environments; confidence score in the range of 70–84. when or when the service is critical, the action is sent for human approval to provide the user with the detected error, possible root cause, 5 on the confirmation screen. Affected services, Risk and confidence scores, Sources of uncertainty, Recommended Correction, Digital twin result, Synthetic test result, Canary and rollback plan. to ensure that information in this format is displayed on the confirmation screen It is being structured. Trust and included in the Decision and Approval Mechanism on the analysis server (3) When the uncertainty decision point function and the confidence score are in the range of 50–69 The system should not perform the automated process; the operations team should be notified of the possible root cause. Reasons, Missing data, Suggested checks, Possible corrective steps To ensure that information in this format is provided; Action 15 if the confidence score is below 50. If the application is not implemented, in this case the new TLS probe is run, Runtime certificate Fingerprints are taken, missing graph relationships are investigated, and new log and trace data are collected. The data will be re-analyzed if a human review task is required. It is configured to ensure that it is transmitted to the layers. Action Orchestration and Target services on the Analysis server (3) With action orchestration in the module, RPA can be used on older platforms without an API. enabling the execution of defined actions through management screens, RPA only performs actions in the policy engine's signed action plan. to be able to implement, the action orchestrator's 25 in certificate and truststore changes also ensure that the trusted version of the state machine is executed, word The relevant states are “CREATED, PREPARING, READY, COMMITTING, It can be in the form of ACTIVE, RETIRING, RETIRED, failure in these cases: “PREPARING → BLOCKED” or “COMMITTING → The ability to switch to "rollback" states, obtained from the dependency graph, 30 19 Changes to services outside the minimum trust repair set It is structured to ensure that its implementation is preferred. In one of the inventions, the AI ​​model on the analysis server (3) graph database, digital twin infrastructure, data collection agents, RPA and orchestration tools 5 rule-based engines that provide the same functions instead, different databases, To enable the use of simulation environments and automation platforms, also real-time threat intelligence, certificate authority reputation score, HSM integration, behavioral anomaly detection, and broader client profiles The processing mechanism on the synthetic test library containing 10 It is configured to allow it to be added to the configuration. Industrial application of the invention In the system subject to the invention, (1) Certificate, truststore, log, server, route and change The data is collected from the data collection server (2). Analysis server (3) telemetry by normalizing the data transmitted from the data collection server (2) It enables the recording of data in the database and dependency graph. Then Deviation, risk and root cause analysis in the AI ​​engine with the analysis server (3) 20 enabling the implementation, possible correction on the digital twin. It enables implementation, correcting the problem with Synthetic TLS tests on different clients. The study confirms that the policy engine is trust, uncertainty, and impact. It enables the system to make action decisions based on its values, and the appropriate action is determined via the API. TLS, 25 enables application to a limited canary group via automation or RPA. This ensures that application and critical process metrics are monitored, and if successful... The changes are rolled out gradually, and if that fails, it is automated. A rollback is ensured, the entire process is recorded in the evidence package, and the result... Feedback is provided to the learning engine. The structure in this system (1) Thanks to this, certificate and truststore errors are not only monitored; their technical cause is identified. determined, tested before production, approved according to its risk, controlled a closed-loop self-healing process that is applied and automatically undone if it fails The process is being created. In the case of the system (1) which is the subject of the invention, the certificate is only distributed and 5 Not that it doesn't exist; it's the expected, mounted, runtime loaded, and live TLS. Joint verification of the certificate statuses observed in the connection, Certificate / Truststore changes are not made in a single step, but are based on the Trust Epoch. Implemented through the “PREPARE–COMMIT–RETIRE” process and dependent services. Failure to activate the new trust status before it is ready, 10 in the same service group Detecting different trust versions as trust split-brain and only Selectively removing and rehabilitating faulty / stale instances from traffic is a TLS process. Among the possible fixes for the error, the minimum that corrects the failed trust paths. Calculation of the repair set with technical impact, truststore change subsequently, the newly formed trust area is checked with "trust-surface delta" and 15 Preventing actions that unnecessarily expand the sphere of trust, change subsequently, the new state of trust is verified with runtime TLS validation, and Selective rollback on only affected targets instead of the entire platform when needed. The implementation is ensured. The system in question (1) is within the scope of the Personal Data Protection Law (KVKK). It operates. The subject of the invention is a dependency graph based certificate system (1) for a wide variety of It is possible to develop its applications, and the invention is supported by the examples described herein. It cannot be restricted, it is essentially as stated in the claims.

Claims

21 REQUESTS 1. Digital certificates and the trust vaults and services where they are used. by monitoring the dependencies between them, trust relationship problems arising from certificates 5 that enables automatic resolution - a certificate that connects with various services, platforms, and communication infrastructures. and numerous issues related to identifying truststore problems. to ensure that technical data is collected, including the certificate serial number. Certificate fingerprint, Validity start and end dates, Certificate authority, Subject and Subject Alternative Name fields, Public key and signature algorithm, Certificate 10 Certificate chain, certificate revocation status, endpoints and services where the certificate was used. Collecting Certificate and Certificate Authority Inventory data in this form, on Truststore file path, Truststore type, File hash value, Alias ​​list, Included root and intermediate certificates, Secret name and version, Secret update time, Volume and Mount information, truststore parameters used by the application, file access and 15 trust in the form of readability status and the collection of confidential data to ensure, certificate expiration, hostname and SAN mismatch, Inability to create a valid certificate chain, Missing intermediate certificate, Untrusted root. certificate, Empty or unopenable truststore, Incorrect truststore password, TLS protocol or cipher mismatch, private key and certificate mismatch error in TLS 20 and to enable the collection of data in the form of application logs, Deployment and pod versions, Container status, Secret, and ConfigMap. References, Volume and mount path information, Instance startup time, Application Restart and reload information, certificate fingerprint used during runtime, Server and system clock, JVM or application startup parameters are 25 Enabling Kubernetes and Server Health data collection, on which NS is applied. Records, route and ingress definitions, virtual host information, SNI mapping rules, TLS termination type, endpoint and port information, and relevant certificate assignments. Enabling the collection of data such as Route, DNS and SNI Settings, Service call traces, client and server relationships, deployment times, certificate 30 22 Renewal records, Secret updates, Route and DNS changes, Restart and Reload operations, manual operation logs, and previous rollback information are all traceable data. To enable the collection of data in the form of (Trace) and Change Records. at least one data collection server (2) is configured and - connects to the data collection server (2), on the data collection server (2) 5 The collected Certificate and Certificate Authority Inventory data is shared with Truststore and Secret. Data, TLS and Application Logs, Kubernetes and Server Status data, Route, DNS and SNI settings, Trace and Change Logs to enable the analysis of the data, to enable at least one data Running the data acquisition and normalization module, data acquisition and normalization 10 The necessary data is sent from the data collection server (2) with the module. Checks should be carried out by local agents, errors from different applications. converting the texts into common error classes, as defined in the configuration. the certificate can be compared with the certificate that the application is actually using, The correct certificate file is determined using data collected from Route, DNS, and SNI settings. 15 Despite being found, a different certificate was used due to an incorrect route or SNI rule. to enable its use in identifying problems such as the presentation of inter-service calls collecting changes made in relationships and infrastructure, thereby enabling TLS which change caused the error to start and whether the change affected the error. To determine whether there is a causal effect, data collection on it 20 and Certificate transmitted from the data collection server (2) with the normalization module and Certificate Authority Inventory data, Truststore and Secret data, TLS and Application logs, Kubernetes and server health data, routing, DNS, and SNI settings, trace data, and change logs form a common dataset. the conversion to the model, in the data collection and normalization module in question 25 Extracting fingerprints from certificates, duplicate records belonging to the same certificate. merging, converting timestamps to a common time format, Log categorizing messages into error classes, Service, endpoint, certificate and trust. Matching repository identities, missing or outdated data. To ensure that each data source is marked and a data quality score is calculated, 30 23 then both the event on the data obtained as a result of normalization To ensure that the data is transferred to both the database and the dependency graph database, then the storage and association module on it should be run, storage and Event Database and Dependency Graph within the association module Ensuring the database runs requires step 5 in the storage and association module. Event database of TLS connection results, handshake error rates, application errors. records, certificate expiration information, Truststore verification results, deployment and Change times, Synthetic test results, Canary metrics, Rollback records, Time-based technical events and measurements in the form of human approval and rejection outcomes To ensure storage, Dependency 10 in the storage and association module. The Graph Database displays technical assets and the relationships between them in a graph structure. to ensure it is stored, then with the causality and scoring module on it. at least running a scoring engine, the scoring engine and its telemetry Dependency graph of the database and error analysis by retrieving data from the database. implementation, score engine certificate and truststore anomalies 15 determining, comparing the expected situation with the actual situation, possible root causes the formation of reasons, the calculation of risk and impact area, decision confidence and Identifying the uncertainty and outlining the possible corrective actions. to provide, with the deviation and error detection module in the causality and scoring module. The certificate expected to be used in the configuration is 20 on Secret or mount. The certificate found is the type of certificate that the application uses during runtime. comparing the information, and the certificate validity period is critical through the comparison process. Level issues, SAN and hostname mismatch, missing certificate chain, Truststore Lack of the necessary certificate, Incorrect secret version, Different sessions (Instance) using a different certificate, Incorrect SNI or route mismatch, System clock 25 Detecting deviations such as TLS protocol incompatibility. to provide, the Risk Score located in the causality and scoring module on it. The calculation module assigns a risk between 0 and 100 to each potential error or risk. the calculation of the score, found in the causality and scoring module on it Multiple root causes related to the errors identified with the Root Cause Analysis module are listed below. 24 to ensure the candidate is produced, the candidate with the highest score is identified as the root cause If multiple candidates receive close scores, the uncertainty score will be higher for their selection. to enable its upgrade, live with the Digital Twin and Synthetic Test module on it. creating a technical copy of the certificate and trust relationships in the environment, root Why is the correction suggestion generated by the engine first displayed on the digital twin? If the error disappears after the correction, then the root cause of the problem is considered to be the culprit. To improve its score, the Digital Twin and Synthetic Test module on it Correction applied to the digital twin using the Synthetic TLS Test Engine within it To enable testing whether it works under different client conditions, Current And clients using the old truststore, different SNI values, true and false 10 Hostname, Missing intermediate certificate chain, Different TLS protocol versions, Different cipher Sets, Clients with time discrepancies, Different networks and geographic regions, Old secrets or synthetic discrepancies in certificate version, private key, and certificate. enabling the generation of scenarios, bidirectional digital twin and synthetic test engine. The study revealed a new error found during testing that affected the digital twin model by 15. transfer, and the new correction made on the digital twin is also re-submitted to synthetic tests. to ensure its submission, policy in the Decision and Approval Mechanism the use of the engine, digital twin and synthetic test with the policy engine evaluating the results and deciding how to proceed with the action to ensure that the policy engine, with the same TLS error, has lower confidence expansion and 20 a wider range when an alternative is found that corrects it with a smaller area of ​​change To prevent the system from automatically selecting comprehensive repair, use "trust-surface delta". If it exceeds the policy boundary, the action should be directed towards human approval or, more narrowly, towards a narrower approach. to ensure comprehensive repair is sought, policy engine that reduces safety automatic blocking of actions, certificate verification 25 Closing or trusting all certificates is a normal automated action. to ensure that it cannot be implemented as such, in the Decision and Approval Mechanism Automatic Canary with confidence and uncertainty decision point function The application involves submitting to human approval, generating solution proposals, collecting additional data, and to ensure that decisions are made to prevent the action, 30 Action Orchestration and Action Orchestration in the Target Services module feasible technical steps of the remediation plan selected by the policy engine conversion, actions API calls, configuration management tools, Kubernetes / OpenShift APIs, Deployment automation, Certificate management Platform integration, script or runbook automation, RPA robots 5 to ensure that it is achieved through methods such as these, in Action Orchestration Certificate renewal, Adding missing intermediate certificate to the chain, Root or intermediate certificate to Truststore Adding certificates, updating secret version, correcting incorrect mount path, Apply a hot reload to the application, restart the problematic instance, or use SNI. Correcting route matching, assigning the certificate to the load balancer (10 steps) Enabling the implementation of processes, Action Orchestration and Target services. With this module, the selected action's certificate vault, truststore, or keystore, Kubernetes / OpenShift secret object, Application pod, Virtual or physical server, API Gateway, Load balancer, Reverse proxy, Route or ingress, WebLogic or 15 to ensure that the change is not applied directly to the entire platform / service, but rather initially as the smallest and most representative target group possible to ensure it is selected, within the Verification and Automatic Rollback module on it. canary verification is performed, correction is applied in canary verification. Then, LS handshake success rate, Certificate verification error rate, Application error 20 Rate, Critical operation success rate, Connection latency, Instance health status, New Certificate fingerprint usage rate, connection result of different client profiles. Ensuring that metrics such as these are monitored, before and after the change. Enabling comparison of metrics, Validation and Automatic Rollback module. The metrics measured by the Metric Decision Point within it are defined in the policy engine as 25. To ensure that it is within the limits, Metrics limits If it is within a limited instance, the change is considered successful. to the group, then to specific traffic rates, and finally to the entire target system. To ensure the changes spread gradually, from each phase of diffusion. then ensure that health checks are carried out again, Metrics 30 26 If it goes beyond the limits, an automatic rollback is initiated, during the rollback... The modified target is removed from traffic, the previous certificate, truststore or Restoring the secret version, previous route or configuration Implementation, performing the necessary restart or reload, old certificate Verification of fingerprint reuse, TLS and critical operation tests 5 To enable the process of restarting the machine, Rollback To ensure that the result is sent to the learning layer as a failed action, The verification should be based not only on the service health metric, but also on the performance of the new trust version. To ensure it also relies on whether it was actually activated in a timely manner, For successful propagation, the target session must use the Expected trust epoch, Correct 10. The certificate or truststore must be mounted, ensuring the correct certificate is loaded at runtime. This involves displaying the expected certificate fingerprint on a live TLS connection. to ensure that it demonstrates the following conditions, within the same service group only if certain sessions do not meet the conditions in question, then all Instead of reversing the spread, these sessions were selectively quarantined. 15 This allows the old security version to be used, but critical services can only be stable in the new version. After verification of its status, ensure it is switched to "RETIRE" status. Successful deployment of the Evidence Package and Self-Learning module. or the creation of a technical evidence package related to the incident following a rollback, evidence When the package is created, Event ID and time information, Affected certificate and 20 Trust store, certificate fingerprints, related logs and telemetry records, dependency. The relevant section of the graph includes: Risk score, Root cause candidates, Confidence and uncertainty. scores, digital twin results, synthetic test results, policy engine decision, human Approval or rejection information, actions taken, pre- and post-change metrics. Enabling the use of information such as Canary result and Rollback result, 25 evidence package audit, security review and post-failure analysis to enable its use, in the Evidence Package and Self-Learning module In self-learning processes, correctly identified root causes are incorrect. Positive alerts, Successful fixes, Failed fixes, Rollbacks Processes, Human-modified suggestions, Recurring errors, New error 30 27 returning the results of the operation, in the form of combinations, to an AI model to ensure that it is fed, so that the data collection server (2) communicates with it. Risk weights and root cause ranking related to certificates on the network, Action success probabilities, confidence thresholds, synthetic test scenarios. to ensure it is updated over time, including the Evidence Pack and Self-5. The learning module involves performing federative learning processes, from one to another. raw materials are used in excess of data centers, company units, or country environments. without the technical data being sent to him via the data collection server (2) To enable the implementation of "federated learning," each environment has its own local data. generating model updates on it, central computing modules 10 only anonymized model parameters should be sent, so that different While collaborative learning is achieved from error patterns in different environments, certification, service and protecting the confidentiality of infrastructure information, and the model being updated as a result of learning; artificial intelligence, causality, and sending it back to the scoring engine, thus closing it off. 15 to ensure continuous improvement of decision accuracy within the cycle dependency characterized by having at least one analysis server (3) configured a graph-based certificate system (1).

2. Dependency graph located in the storage and association module on it. Within the database, there are certificates, certificate authorities, truststores, secrets, applications, pods, or 20s. Server, endpoint, DNS and SNI record, route, client service, critical operation. the holding of nodes in the form of a flow, with the certificate inside a secret finding, adding the secret to an application, the application obtaining a specific certificate using it at runtime, the endpoint providing the specific certificate, the client The service calling the relevant endpoint requires the trust store to assign a specific root certificate to 25. relationships where trust is required and critical transaction flows depend on the relevant service. characterized by the analysis server (3) configured to provide storage. A dependency graph based certificate system as in Request 1 (1). 28 3. From the storage and association module on it, from the data collection server. (2) dependency graph created with transmitted technical data, a certificate error to be used in determining which services and operations might be affected, each configuration for the relationship, live traffic, certificate fingerprint, and time the ability to generate a relationship confidence score based on compatibility, and the graph nodes also being 5 being able to associate active and expected trust version information with the application or The certificate expected in the configuration related to the instance nodes, mount the registered certificate, the certificate loaded at runtime, and the live TLS To enable the certificate observed in the connection to be maintained as separate properties, During certificate rotation, the graph shows “CURRENT_EPOCH” for each consumer, 10 The ability to store the "TARGET_EPOCH" and "READINESS_STATE" states, Thus, the graph is used not only for dependency analysis but also for determining which distributed trust transition it is. It can also be used to track which stage the services have reached. Claim 1 or 2 characterized by the analysis server (3) configured for a dependency graph based certificate system (1). 15 4. The scoring engine in the causality and scoring module on it. By running it, artificial intelligence learns from past events and avoids similar mistakes. to enable the recognition of patterns, but to ensure that the results produced are in line with policy rules and to ensure that it is limited by the explainability mechanism, the deviation on it is 20 and the expected technical status and the actual situation in the live environment with the error detection module. by comparing the situation and noting the difference in the values ​​obtained, the certificate to ensure it is evaluated as a spread or runtime deviation from the above requests characterized by the configured analysis server (3) a dependency graph based certificate system like any other (1). 25 5. Deviation and error detection module in the causality and scoring module. different sessions use different certificates based on the trust version. to ensure evaluation, new trust for some sessions in the same service group version 30, others using the previous version, trust, divided brain 29 marking is incorrect or defective in the case of split-brain. via session certificate fingerprint, mount information and live TLS proof to determine and only those sessions with the improvement objective with the analysis server (3) configured to enable its conversion The dependency graph is 5, as in any of the above-characterized requests. a certificate system based on (1).

6. Calculating the risk score in the causality and scoring module. The module checks the remaining validity period of the certificate and addresses hostname mismatches. Certificate chain integrity, truststore health status, secret or mount deviation, 10 live TLS error rate, number of affected services, service criticality, traffic volume, proximity by using factors such as changes in time, thus certificates used in high-traffic or critical payment transactions Analysis structured to enable a higher impact score calculation. 15 as in any of the above requests characterized by server (3). a dependency graph based certificate system (1).

7. Calculating the risk score in the causality and scoring module. every event related to the technical data transmitted from the data collection server (2) with the module In calculating the risk score, the following formulas are used: “Risk Score = 0.18 × Time Risk”, “Risk Score = 20 0.15 × Hostname Risk”, “Risk Score = 0.15 × Chain Risk”, “Risk Score = 0.15× Truststore Risk”, “Risk Score = 0.12 × Mount / Runtime Deviation”, “Risk Score = 0.10 × Live TLS Error Rate”, “Risk Score = 0.10 × Service Impact” and “Risk Score Using different formulas such as "= 0.05x Last Modification Proximity", this thanks to the fact that its term is about to expire but is not being used by any critical platform 25 unused certificate used in the payment services' common gateway To prevent the certificate from acquiring the same risk value, to prevent dependency. the number of services, traffic volume, and critical transaction links in the graph show the service impact. with the analysis server (3) configured to ensure the score is increased The dependency graph is similar to that in any of the above-characterized requests. a certificate system based on (1).

8. Root cause analysis found in the causality and scoring module. The error detected by the module is related to the expiration of the certificate, certificate 5. Renewed but not installed, the required root of the trust store is needed. not including the certificate, mounting (introducing) the wrong secret version, The application is keeping the old certificate in memory, which means the incorrect SNI rule is using a different certificate. generating sample candidates such as the selection being based on a faulty system clock. to ensure the error message regarding the candidates in question matches the candidate reason, candidate 10 The component's position in the dependency graph, error onset and change time, active TLS test results, configuration and runtime data, historical comparisons events are evaluated using data in the form of digital twin intervention results. characterized by the analysis server (3) configured to provide A dependency graph-based certificate, like any of the above requirements, is 15 system (1).

9. Digital twin simulation in the digital twin and synthetic test module on it. execution within the digital twin: certificates, truststore contents, secrets versions, mount definitions, application instances, route and SNI rules, TLS 20 Information such as termination points, client-service relationships, and traffic distribution. modeling showed that the error was caused by the old certificate remaining in memory. If this is considered, reloading the relevant session onto the digital twin and to ensure that the error has been eliminated, the digital twin It should also simulate trust release transitions, 25 for a new trust period. The stages "PREPARE", "COMMIT" and "RETIRE" are carried out in a virtual environment. the implementation of the new trust anchor, especially by adding it to consumers' accounts in advance. whether it disrupts existing connections when the new server certificate becomes active. which consumers were unable to connect and when the old trust anchor was removed to enable an assessment of whether any remaining addictions exist, 30 31 A trusted version of the digital twin, in which the critical TLS path was broken, was delivered to the live environment. characterized by the analysis server (3) configured to ensure that it cannot be detected. a dependency graph based on any of the above requests certificate system (1).

10. Certificate or truststore security on the digital twin and synthetic test module. If possible, take single-step actions to change the situation. not being implemented, a new trust version for each trust change (Trust The creation of the Epoch and the transition through “PREPARE”, “COMMIT” and “RETIRE” REPARE phase 10 should be carried out as a controlled process consisting of stages. certificate, truststore or certificate to be modified via dependency graph during process sessions of services, clients and runtime that depend on the chain determining which root certificate, intermediate certificate, or new trust version will be used in the new trust release. The primary goal is to distribute truststore entries to the necessary consumer platforms, not removing existing and functioning trust inputs at each critical stage, 15 the new truststore or certificate version for the consumer or session to the target system whether it was reached, whether the expected secret or mount version was used whether it was used, whether the new security version was actually installed at runtime not loaded, whether a TLS or mTLS connection has been established with the candidate certificate chain It could not be established, the certificate fingerprint observed in the live connection is 20 times the expected value. to ensure that checks are carried out to determine whether they are compliant from the above requests characterized by the configured analysis server (3) a dependency graph based certificate system like any other (1).

11. One or more critical 25 on its digital twin and synthetic test module If it is determined that the dependency is not ready for the new trusted version, “COMMIT” avoiding the next stage, maintaining the current state of trust, and failing the process of bringing consumers into the correction or review process, COMMIT phase during which all critical dependencies or by the policy engine The identified mandatory critical cluster is ready for the new confidence release on 30. 32 The new certificate or trust configuration becomes active once verified. to ensure that it is brought up after the server or client certificate is changed It is important not to just look at the configuration record, but also to ensure the new certificate is working. It was indeed loaded on time and the new certificate was detected in live TLS traffic. Verification that the permission was used, from 5 sessions in the same service group. Some are using the new security version while others remain on the previous version. If detected, the situation should be marked as "trust split-brain," in which case all Instead of restarting the service group, only the old and faulty trust issues are resolved. in this case, the remaining sessions are selectively included in the "remediation" process. 10 characterized by the analysis server (3) configured to provide a dependency graph-based certificate like in any of the above requirements system (1).

12. The “RETIRE” phase in the digital twin and synthetic test module on it. During this time, the new trust version was working stably in live traffic, critical 15 clients can connect and the expected certificate chain is used. Once verified, the previous trusted version will be retired, the previous certificates, intermediate certificates, or truststore entries that are no longer needed, however after the runtime verification of the new confidence status is complete removal, thus premature termination of the old trust relationship, client 20 preventing the disconnection of connections at any stage of the transition If the verification fails, the transaction will not be considered complete. Enabling targets to be maintained at the previous trust version or to roll back when needed. to initiate the process, and also to ensure that the action to be taken is registered in a truststore. If adding a new root or intermediate certificate is required, 25 before and after the change. Analysis structured to enable comparison of effective confidence sets. as in any of the above requests characterized by its server (3) a dependency graph based certificate system (1). 33 13. The “RETIRE” phase in the digital twin and synthetic test module on it. During the correction process, unnecessary new trust outside of the services associated with the error was avoided. If it is determined that relationships have been established, the action should not be applied automatically. seeking more limited alternative repairs or requiring human approval for the procedure. 5 that a TLS error can be resolved using multiple technical methods in these cases, the failed confidence paths in the dependency graph are re-validated. Comparison of candidate actions that enable the implementation, node to be changed number of instances, trust store count, number of instances requiring a restart or reload, traffic impact, by evaluating service criticality, safety risk and rollback cost, as is possible. implementing the repair plan with the lowest technical impact, thus 10 Certificate and Trust Store changes can only be made by clicking "Update Certificate and Service". Not with a "restart" mentality; but with a new trust status for dependent platforms. preparation, time-testing, and controlled release of the new version. the previous trust status is restored only after successful verification. 15 as a distributed and reversible trust transition protocol in the form of removal characterized by the analysis server (3) configured to enable its execution. a dependency graph based on any of the above requests certificate system (1).

14. Risk score, with the policy engine within the decision-making and approval mechanism, 20 root cause confidence score, uncertainty score, service criticality, number of affected systems, Reversibility of the fix, Canary applicability, maintenance window, security policies, success rate of previous similar actions, minimum trust repair set The results include trust-surface delta, target trust epoch readiness ratio, and split-brain findings. The number of sessions, the readiness of critical consumers for the new trust release, is 25. Analysis server configured to enable evaluation of criteria (3) dependency as in any of the above demands characterized by a graph-based certificate system (1). 34 15. Trust and uncertainty in the decision-making and approval process. If the confidence score, calculated using the point function, is above 85, then the uncertainty score is below 15. if below, if the scope of the correction is limited, if a rollback operation is possible, digital twin And if the synthetic tests are successful, the correction is automatically applied to the canary environment. to ensure it can be implemented; when the confidence score is between 70–84 or service 5 Ensuring that the action is sent for human approval when it is critical, approval The screen displays the detected error, possible root cause, affected services, risk, and other information to the user. confidence scores, sources of uncertainty, proposed correction, digital twin result, Information such as synthetic test results, canary and rollback plan appears on the confirmation screen. 10 characterized by the analysis server (3) configured to enable its display. a dependency graph based on any of the above requests certificate system (1).

16. Trust and uncertainty in the decision-making and approval mechanism. When the confidence score is between 50 and 69 using the point function, the system automatically sets it to 15. the failure to perform the operation, possible root causes, missing data, Providing information in the form of suggested checks and possible corrective steps. to ensure that no action is taken if the confidence score is below 50, in which case The new TLS probe is started, runtime certificate fingerprinting is performed, missing graph is added. Relationships are investigated, new log and trace data are collected, and if necessary, human investigation tasks are assigned. 20 To ensure that the generated data is transmitted back to the analysis layers. The above is characterized by the analysis server (3) which is configured for the above. a dependency graph based certificate system like any of the requests (1).

17. Action orchestration and action in the target services module 25 RPA on older platforms without API orchestration, management screens enabling actions defined through it, RPA only Certificate enables the policy engine to implement the actions in the signed action plan. and the action orchestrator also applies to truststore changes and trust version status. to ensure that the machine is also operated, 30 of the aforementioned situations 35 “CREATED, PREPARING, READY, COMMITTING, ACTIVE, RETIRING, It should be in the form of RETIRED, and in case of failure: “PREPARING → Statuses of "BLOCKED" or "COMMITTING → ROLLBACK" the minimum confidence repair set obtained from the dependency graph to enable it to be passed 5. To ensure that changes are not applied to services other than those specified. The above is characterized by the analysis server (3) which is configured for the above. a dependency graph based certificate system like any of the requests (1).

18. The artificial intelligence model, graph database, digital twin infrastructure, and data on which it is based. Rule 10: Instead of collection agents, RPA, and orchestration tools, use tools that provide the same functionality. based engines, different databases, simulation environments and automation enabling the use of platforms, as well as real-time threat intelligence, certificate authority reputation score, HSM integration, behavioral anomaly detection and synthetic testing involving broader client profiles 15 characterized by the analysis server (3) configured to provide a dependency graph-based certificate like in any of the above requirements system (1). 25