Concepts: Certificates, PKI, Digital Signatures

What Is a Digital Certificate?

A digital certificate is an electronic document that links a public key to an identity. It says, in effect: “This public key belongs to sbi.co.in, and we — DigiCert — vouch for that.”

Think of it like a government-issued ID card. Your Aadhaar card says “This photo and biometrics belong to this person, and the Government of India vouches for it.” A digital certificate says “This public key belongs to this domain, and this Certificate Authority vouches for it.”

A certificate contains:

• The domain name it is issued for (e.g., sbi.co.in)
• The public key of the server
• The name of the Certificate Authority (CA) that issued it
• The validity period (start date and expiry date)
• A digital signature from the CA (more on this below)

Certificate Authorities — The Internet’s Notary System

A Certificate Authority (CA) is an organisation that verifies identities and issues certificates. When you apply for a certificate for your website, the CA checks that you actually own the domain. Once satisfied, they issue a certificate with their digital signature on it.

The notary analogy: when you sign a property document, you need a notary public to stamp it. The notary checks your identity and then puts their official stamp on the document. Anyone who sees the stamp knows the notary vouched for the signer. CAs are the internet’s notaries.

Well-known CAs include DigiCert, Sectigo, and GlobalSign (commercial, paid), and Let’s Encrypt (free, automated — used by millions of websites).

The Chain of Trust

No browser trusts individual website certificates directly. Instead, there is a hierarchy:

Root CA (e.g., DigiCert Global Root G2)
    └── Intermediate CA (e.g., DigiCert TLS RSA SHA256 2020 CA1)
            └── Site Certificate (e.g., sbi.co.in)

Root CAs are the top-level authorities. Their certificates come pre-installed in your device’s operating system and browser — Apple, Google, Microsoft, and Mozilla each maintain a list of Root CAs they trust. Getting onto this list requires passing rigorous audits. There are fewer than 200 Root CAs trusted globally.

Intermediate CAs sit between Root CAs and individual websites. Root CAs issue certificates to Intermediate CAs, vouching for them. Intermediate CAs then issue the certificates that websites use. This structure protects Root CA keys — if a Root CA key were ever compromised, it would be catastrophic. Keeping Root CA keys offline and rarely used reduces that risk.

Site Certificates are what individual websites hold. sbi.co.in has a certificate issued by an Intermediate CA.

When your browser connects to sbi.co.in, it:

1. Receives the site certificate and the intermediate certificate
2. Checks that the intermediate certificate is signed by a Root CA it already trusts
3. Checks that the site certificate is signed by that intermediate CA
4. Verifies the site certificate is for the domain you are visiting (sbi.co.in)
5. Verifies the certificate has not expired
6. Verifies the certificate has not been revoked

All of this happens before the page loads.

What Happens When Verification Fails?

You have probably seen browser certificate warnings. Now you know what they mean:

• “Certificate has expired” — the validity period on the certificate is in the past. The site owner forgot to renew it. This does not necessarily mean the site is malicious, but you cannot verify its identity.
• “Certificate is not valid for this domain” — the certificate was issued for sbi.co.in but you are connecting to sbi.co.in.update.xyz. The domain does not match.
• “Certificate authority is not trusted” — the certificate was not signed by any CA in your device’s trust list. This could be a self-signed certificate (no CA vouched for it) or a certificate from an organisation your device has not approved.
• “Certificate has been revoked” — the CA has explicitly cancelled this certificate, usually because the private key was compromised.

Digital Signatures — Proving Authenticity

A digital signature is how a CA proves it issued a certificate. It is also how you can prove you wrote a document.

Here is how it works:

1. You have a private key (only you have it) and a public key (shared with everyone)
2. When you sign a document, your software creates a unique “fingerprint” of the document (called a hash) and encrypts that fingerprint with your private key
3. Anyone with your public key can decrypt that fingerprint and verify it matches the document

If the document had been changed after signing, the fingerprint would no longer match. The signature would fail verification. This proves two things:

• Authenticity — the document came from you (only your private key could have created that signature)
• Integrity — the document has not been modified since you signed it

Non-repudiation is the property that means you cannot deny signing something. Because only your private key could have created the signature, and only you (theoretically) have your private key, you cannot credibly claim “I didn’t sign that.” This is why digital signatures are stronger than handwritten signatures in some respects — they are mathematically tied to the signer.

PKI — Public Key Infrastructure

The whole system we have been describing — certificate authorities, trust chains, public and private keys, digital signatures — is called PKI (Public Key Infrastructure). It is the backbone of internet security.

PKI is not one company or one piece of software. It is a system of policies, organisations, software, and hardware that together make secure communication possible. When you use HTTPS, you are relying on PKI. When you use WhatsApp’s end-to-end encryption, you are relying on PKI. When you log into your bank or send email — PKI is there too.

Putting It Together: Deepa’s Banking App

When Deepa opens her SBI app:

1. The app connects to SBI’s API server
2. The server presents its certificate: “I am api.sbi.co.in, here is my certificate signed by DigiCert”
3. The app checks the chain: DigiCert → Intermediate → api.sbi.co.in
4. The app verifies DigiCert is in its trusted root list (it is — pre-installed on her Android phone by Google)
5. The app verifies the domain name matches
6. The app verifies the certificate has not expired
7. The TLS handshake completes
8. Deepa sees her balance

If any step fails — if the chain is broken, the domain does not match, or the certificate has expired — the app would refuse to connect. Not warn. Refuse. Banking apps are strict about this for good reason.