# A Blockchain based PKI Validation System based on Rare Events Management
## 4 A New Approach to X.509 Certificate Management Using Distributed Ledger Technology (DLT)
### The Smart Contract Structure and Its Relationships with the Consensus Algorithm
In this case, the agreement comes from a smart contract that checks that many unrelated clients with sparse locations start the TLS connection with the same server using the same certificate and the same IP address  
```
1 Procedure Validate (certificate, domainName, ipAddress)
2{//Return values: VALID, REVOKED, EXPIRED, FAKE
3 findvalue forkey=(certificate,domainName,ipAddress)
4 if(found)
5{
6 Ifvalue is in (REVOKED,EXPIRED, FAKE)
7 returnvalue
8 else if (the tuple =(certificate,domainName,ipAddress) is in the blockchain and has been flagged as correct )
9
10 returnvalid
11 else
12{
13 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
14
15 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
16 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
27 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
28 **ok =** check the certificate on internet (try to connect to the server) and verify that the certificate sent by the server is identical to the checked certificate
29 **ok =** check the certificate on internet (try to connect to



The main steps of the Validate smart contract are as follows:

* The smart contract checks the tuple, particularly the couple (certificate, domain name), locally, like a browser, to see if the certificate is malformed, if the issuing CA is a trusted CA, and if the other static and structural checks have been done. Validate returns (and appends a simple log to the blockchain to support possible litigations) the status FAKE or EXPIRED or MALFORMED for a negative result in one of these checks. Otherwise, the following steps are done:
* The smart contract checks if the tuple (certificate, domain name, IP address) is already in the blockchain. There are five possible cases where the tuple is already in the blockchain:
* The CA and/or the server belong to the blockchain and have appended the tuple at the certificate issuing event;
* The tuple is marked as revoked or expired (by the issuer CA, by the server that owns it);
* The tuple has been checked in the past (validated) with a positive result;
* The tuple has been checked in the past (validated) with a negative result;
* The tuple (certificate, domain name, IP) is in the blockchain with a different IP address and with a positive validation (Case c). * The tuple (certificate, domain name, IP) is in the blockchain with a different IP address and with a negative validation (Case d). In all these instances the Validate procedure terminates--in (a, c, e) with a positive result; in the other situations with a negative result. If the tuple is not already available in the blockchain, it needs a \"further check\". The \"further check\" comprises the connection of the peer to the server, receipt of the certificate, and making a local check of the tuple itself together with the received certificate. If all the checks are positive, the Validate procedure terminates with a VALID return value (and the tuple is appended to the blockchain with a positive evaluation). To better understand the step \"further check\", let us consider a man in the middle attack. The tuple to be further checked is shared by the client peer to the random subset of the peers chosen in by the consensus algorithm. Each one of these peers executes the validation smart contract on the tuple, and if only one of these peers is not under attack (with the man in the middle), he will receive the correct certificate from the real server (solved by a real DNS server), and its validation smart contract returns the value of FAKE.