What is PKI? Public key infrastructure explained

Public key infrastructure (PKI) is the system of certificates, certificate authorities, trust stores and rules that lets software trust that a public key really belongs to a particular website, person or device. A certificate authority checks an identity and signs a certificate binding it to a public key; your browser or app accepts that certificate because it can follow the signatures back to a root it already trusts. PKI is what makes HTTPS, India's Digital Signature Certificates and mutual TLS work at scale.

The trust problem PKI solves

Public-key cryptography has a gap. Anyone can generate a key pair and claim it belongs to your bank, your course platform or you. If an attacker can swap their public key for the real one, encryption and signatures work perfectly, just for the wrong party. That is the man-in-the-middle problem described in our guide to Diffie-Hellman key exchange.

There are three broad ways to decide whose key is whose:

• Check it yourself. Compare a key's fingerprint through another channel, or trust it the first time and alert if it ever changes, as SSH does. Fine for a few servers; impossible for the whole web.
  
  
• A web of trust. People vouch for each other's keys. It never caught on beyond technical communities.
  
  
• A trusted third party. An authority everyone agrees to trust checks identities and signs statements binding names to keys. This is PKI, and it runs the web.
  
  

Certificates and chains

The signed statement is a certificate, almost always in the X.509 format defined in RFC 5280. Its main fields are:

• Subject and subject alternative names: whom the certificate is for, such as the domains a website certificate covers or the person a DSC names.
  
  
• Public key: the key being vouched for.
  
  
• Issuer: the authority that signed it.
  
  
• Validity: not-before and not-after dates.
  
  
• Extensions: what the key may be used for, and whether this certificate may itself issue certificates.
  
  
• Signature: the issuer's digital signature over all of the above.
  
  

Certificates link into a chain. A website's certificate is signed by an intermediate CA, which is signed by a root CA. Roots are self-signed and ship inside operating systems and browsers, in lists called trust stores. Root keys are kept offline and used rarely; intermediates do the day-to-day issuing, so a compromised intermediate can be replaced without touching every device in the world. A chain can also include a cross-signed certificate, where an older, widely trusted root vouches for a newer one so that old devices accept it.

Try it: read a real chain

# Show the certificate chain a server sends
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Summarise the site's own certificate
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

In the first command's output, each certificate is listed with an "s:" (subject) and an "i:" (issuer) line. The issuer of certificate 0 is the subject of certificate 1, and so on up the chain. The second command shows the domains covered and the expiry date, the two details behind most certificate outages.

Certificate authorities, public and private

Public CAs are trusted by default on almost every device. In exchange, they must follow the CA/Browser Forum's Baseline Requirements and each browser's and operating system's root programme, pass regular audits, and record every TLS certificate in public Certificate Transparency logs so domain owners can spot mis-issuance. Domain-validated certificates are increasingly issued and renewed automatically through the ACME protocol.

Private CAs are ones you run yourself. Only machines you configure will trust them, which is exactly the point: they identify your own servers, services and devices, not public websites.

India's licensed certifying authorities

India runs a separate, statutory PKI for digital signatures. Under the Information Technology Act, 2000, the Controller of Certifying Authorities (CCA), appointed under Section 17, licenses and regulates certifying authorities. The CCA operates the Root Certifying Authority of India (RCAI), set up under Section 18(b), which signs the public keys of licensed CAs. They in turn issue Digital Signature Certificates to individuals and organisations. The CCA issues certificates only to CAs, never directly to the public.

The CCA's list of licensed CAs named 23 on 29 September 2026: Safescrypt, IDRBT, (n)Code Solutions, e-Mudhra, CDAC, Capricorn, Protean, Vsign (Verasys), Indian Air Force, CSC, RISL (RajComp), Indian Army, IDSign, CDSL Ventures, Panta Sign, xtra Trust, Indian Navy, ProDigiSign, SignX, Care 4 Sign, IGCAR, Speed Sign and Assam Rifles. The CCA's website also shows which of them issue DSCs and eSign services to the public, so check it before you buy.

Two points often cause confusion:

• DSCs and website certificates are different trust systems. A DSC chains up to the RCAI root, which the CCA says Microsoft products carry. Whether a browser trusts a CA for websites is decided by the browser and operating system root programmes. The CCA additionally requires any licensed CA issuing SSL certificates to run a separate offline CA system audited in line with CA/Browser Forum requirements.
  
  
• Every CA's certificates of the same class carry the same assurance. Identity verification is uniform across India PKI, so a Class 3 DSC from one licensed CA is worth the same as one from another; only the price differs.
  
  

Revocation and short-lived certificates

A certificate sometimes has to die early: its key leaks, a device is lost, an employee leaves. There are two classic ways to tell the world:

• Certificate revocation lists (CRLs): the CA publishes a signed list of revoked serial numbers.
  
  
• OCSP: the client asks the CA about one certificate at the moment of use.
  
  

Neither worked well on the web. OCSP tells the CA which sites each visitor is opening, adds a network call to every new connection, and browsers usually carried on if the check failed. Let's Encrypt ended OCSP for this reason: it removed OCSP URLs from its certificates on 7 May 2025 and switched off its responders on 6 August 2025, relying on CRLs instead. It now offers 90-day certificates by default, a 45-day option, and a "shortlived" profile of 160 hours, just under a week.

The industry's real answer is to make certificates expire before revocation matters much. Under the CA/Browser Forum's Ballot SC-081, passed in April 2025, public TLS certificates are shrinking in stages to a 47-day maximum by March 2029, and the period for reusing domain-validation checks falls to 10 days. Our guide to how SSL/TLS works lists each step of that schedule.

What that means in practice

Take an illustrative institute with 12 public certificates: the main site, www, the student portal, an app API, the admin panel, a payment callback endpoint, a video delivery domain, and staging copies of several of these. At a 47-day maximum, each needs about eight renewals a year, close to a hundred in total. Nobody should be doing that by hand. Automate issuance with ACME, keep an inventory of every certificate and where it is installed, and alert on expiry for anything automation might miss, such as certificates uploaded manually to a CDN or load balancer.

PKI inside your own systems

A private PKI is worth considering once you have machines that need to prove their identity to each other: services calling services with mutual TLS, devices in exam centres, VPN users, internal dashboards or SSH access. A sound small setup looks like this:

1. Create an offline root once, keep its key in a hardware security module or encrypted offline storage, and use it only to sign intermediates.
   
   
2. Run an online intermediate for each purpose, such as one for services and one for devices, so a problem with one doesn't force you to replace everything.
   
   
3. Issue short-lived leaf certificates automatically, valid for hours or days, through an internal ACME server, a managed private CA or a service mesh.
   
   
4. Protect the CA keys as your most sensitive secrets; see our guide to encryption key management.
   
   
5. Distribute your root only to machines that need it. Never ask students to install your root certificate on their phones; that would let anyone holding your CA key intercept their traffic.
   
   
6. Write down how you will rotate an intermediate or revoke a device before you need to, and test it.
   
   

Shorter lifetimes also affect mobile apps that use SSL pinning: the more often certificates change, the more fragile any pinning that depends on them becomes.

Key takeaways

• PKI answers "whose key is this?" with certificates signed by authorities that devices already trust.
  
  
• Trust flows down a chain from an offline root, through intermediates, to the certificate for a site, person or device.
  
  
• Public CAs serve the open web under strict rules; private CAs identify your own machines.
  
  
• India's statutory PKI for DSCs runs from the RCAI root through 23 CCA-licensed CAs.
  
  
• Revocation has always been weak, so the industry is moving to short-lived certificates, which makes automation essential.
  
  

Frequently asked questions

What is PKI and how does it work?

PKI, or public key infrastructure, is the framework that binds public keys to identities. A certificate authority verifies who you are and signs a certificate containing your public key. Anyone who trusts that authority's root can check the chain of signatures and know the key is really yours. Browsers use it to verify websites, and India uses it for Digital Signature Certificates under the IT Act.

What is PKI certificate?

A PKI certificate, or digital certificate, is a signed electronic document in the X.509 format that binds a public key to a subject, such as a domain, person, organisation or device. It lists the issuer, validity dates and permitted uses, and carries the issuing authority's signature. Website TLS certificates, Indian DSCs, code-signing certificates and client certificates for mutual TLS are all PKI certificates.

What is PKI in cyber security?

In cyber security, PKI is the trust layer underneath encryption and authentication. It lets systems confirm they are talking to the genuine server, user or device before exchanging keys, which prevents impersonation and man-in-the-middle attacks. It supports HTTPS, VPNs, email security, signed software updates and device identity, and it only works if CA keys are protected and certificates are renewed and revoked properly.