To communicate securely, a distributed system uses three processes; Encryption, Authentication, and Integrity. This article discusses the underline architecture of Authentication.
Now that we have a way to obfuscate messages transmitted across networks But how can a client verify the identity of the server? How can the client know the transmitted message is going to the right server?
The client will need to authenticate the server to verify it’s who it claims to be. It does this by verifying that the Public key provided by the server is authentic. This eliminates the listing of anonymous entries in a Network.
At the start of a TLS (Transport Layer Security)session, the receiving client requires the sending server to submit a client TLS certificate for authentication.
A TLS certificate also known as a digital certificate, identity certificate, or public key certificates, are digital files that are used to certify the ownership of a public key.
A TLS certificate includes information about the owning entity, expiration date, public key, and a digital signature of the entity that issued the certificate.
The certificate’s issuing entity is called a certificate authority (CA), which is also represented with a certificate. This is a chain of certificates that starts with the client certificate and ends with a certificate issued by a root CA.
For a TLS certificate to be trusted by a device, the certificate, or one of its ancestors, must be present in the trusted store of the client. Root CAs are included in the client’s trusted store by default by the operating system vendor.
Root CAs issue and sign intermediate roots for intermediate CAs, which in turn issue client certificates, protecting root CAs from being compromised through insulation.
When a TLS connection is opened, the client sends the full certificate chain to the server, starting with the client’s certificate and ending with the root CA. The server verifies the client’s certificate by scanning the certificate chain until a certificate is found that it trusts. Then the certificates are verified in the reverse order from that point in the chain. The server knows which CAs are trusted because.
The verification checks several things, like the certificate’s expiration date and whether the digital signature was actually signed by the issuing CA. If the verification reaches the last certificate in the path without errors, the path is verified, and the server is authenticated.
