Certificate Authority and Chain of Trust

Introduction

Secure communication needs more than encryption. A browser may encrypt data using a server’s public key, but it must first know whether that public key actually belongs to the real server.

This is the problem solved by Certificate Authorities, Public Key Infrastructure, and the chain of trust. Together, they help systems verify identity before trusting a public key.

Why Public Keys Need Verification

In asymmetric cryptography, a public key can be shared openly. Anyone can see it, copy it, or send it across the network. The problem is not that the public key is visible. The real problem is knowing whether the public key belongs to the correct entity.

For example, when a browser connects to bank.com, it receives a public key from the server. If an attacker tricks the browser into accepting the attacker’s public key, the browser may encrypt sensitive data for the wrong party.

So the main question becomes: Is this public key really owned by the website or server I am trying to contact?

What Is a Certificate Authority?

A Certificate Authority, or CA, is a trusted organization that issues digital certificates. A digital certificate connects a public key with an identity such as a domain name, company, server, user, or device.

A CA verifies ownership or identity before issuing a certificate. After verification, the CA digitally signs the certificate using its own private key.

A certificate commonly contains:

• Domain or identity: The website, user, server, or organization the certificate belongs to.

• Public key: The public key associated with that identity.

• Issuer: The Certificate Authority that issued the certificate.

• Validity period: The time range during which the certificate is valid.

• Digital signature: The CA’s signature proving that the certificate was issued by that CA.

If a browser trusts the CA and the certificate is valid, it can trust that the public key belongs to the claimed identity.

Chain of Trust

The chain of trust is the certificate path that connects a website or server certificate back to a trusted root CA.

A common certificate chain looks like:

Website certificate => Intermediate CA certificate => Root CA certificate

The browser or client checks each certificate in the chain. If every signature is valid and the chain ends at a trusted root CA, the certificate can be accepted.

During certificate validation, a client usually checks:

• Certificate signature: Was each certificate signed by the correct issuer?

• Domain name: Does the certificate match the website being visited?

• Validity period: Has the certificate expired?

• Revocation status: Has the certificate been revoked?

• Trusted root: Does the chain end at a root CA trusted by the browser or operating system?

If any important check fails, the browser shows a certificate warning or blocks the connection.

Root CA vs Intermediate CA

Root CAs are highly trusted and must be protected carefully. If a root CA is compromised, trust in many certificates below it may be affected.

For safety, root CAs usually do not issue website certificates directly. Instead, they sign intermediate CA certificates, and intermediate CAs issue certificates to websites and services.

This hierarchy helps reduce risk. If an intermediate CA has a problem, it can be revoked or replaced without directly exposing the root CA.