The Everyday Developer Problem
Imagine you’re building a chat app with login and messaging features. It works fine locally, but the moment you put it on the internet, you hit questions like:
- How do I make sure messages can’t be read by random people sniffing traffic?
- How do I prevent someone from setting up a fake server pretending to be mine?
- How can two microservices in my system trust each other without hardcoding secrets everywhere?
These are not “security team only” questions. They land on every developer’s desk at some point. And the answer almost always circles back to Public Key Infrastructure, in short, PKI.
So let’s break down PKI from a developer’s lens: why it exists, how it actually works under the hood, and why ignoring it can burn you in production.
What Exactly Is PKI?
At its core, PKI is a system of trust built on cryptography. Think of it like the app store for digital identities:
- You trust apps on your iPhone because they’re signed by Apple.
- Similarly, browsers and systems trust websites, APIs, and devices because they’re vouched for by a trusted authority.
PKI is that system of authorities, rules, and cryptographic checks that allows developers to:
- Encrypt communication so outsiders can’t eavesdrop.
- Authenticate parties so you know you’re talking to the right server.
- Verify integrity so data can’t be tampered with mid-flight.
Without PKI, the internet would be like deploying microservices with no version control, chaos, collisions, and trust issues everywhere.
The Three Core Problems PKI Solves
1. Encryption: Keeping Secrets Secret
If you send a password or token in plain text, it’s like sending an email with your credentials in the subject line. PKI provides encryption (via TLS/SSL) so data looks like gibberish to outsiders.
2. Authentication: Knowing Who’s Who
Imagine an API gateway that accepts requests from multiple services. Without PKI, how does it know Service A isn’t just some script impersonating it? Certificates backed by PKI solve this problem.
3. Digital Trust: Scaling Beyond Your Laptop
Trust works on your local machine because you control everything. But in distributed systems like microservices, Kubernetes clusters, and IoT fleets, you need a scalable trust model. PKI gives you exactly that.
Real-World Examples Developers Already Use
You may not know it, but you’re already using PKI daily:
- HTTPS in browsers → Every padlock you see in Chrome/Firefox relies on PKI.
- API security → Many platforms require mutual TLS (mTLS) where both client and server present certificates.
- IoT devices → Smart home gadgets often use certificates to prove they’re genuine and not counterfeit.
- Kubernetes → Certificates secure the communication between nodes and the API server.
PKI is less “optional crypto” and more like DNS, invisible but absolutely necessary.
How PKI Works
Step 1: Key Pairs
At the foundation is asymmetric cryptography.
- Private key → Your secret. Never shared.
- Public key → Safe to share.
Example: Think of it like an SSH keypair:
- You keep your
id_rsa(private key) safe on your laptop. - You put your
id_rsa.pub(public key) on GitHub.
Anyone can encrypt a message with your public key, but only you (with the private key) can read it.
This unlocks three core operations:
- Encryption (lock with public key, unlock with private key).
- Digital signatures (sign with private key, verify with public key).
- Verification (prove data came from the owner of the private key).
Step 2: Certificates
Raw keys aren’t practical to exchange because anyone can claim:
“Hey, here’s my public key. Trust me, I’m Google.”
That’s where certificates come in.
- A certificate = public key + identity info (domain, org, expiry date).
- It’s digitally signed by a trusted party, so it can’t be forged.
Example:
When you visit https://example.com, the server doesn’t just send you a public key.
It sends an X.509 certificate that says:
Subject: example.com
Public Key: <...>
Issuer: Let's Encrypt
Expiry: Dec 2025
The signature by Let’s Encrypt proves this certificate really belongs to example.com.
An X.509 certificate is a digital ID card used in PKI to prove the identity of a server, device, or person. It contains a public key, identity info (like domain or organization), an issuer (CA), and a digital signature to ensure trust and integrity. It’s the standard behind HTTPS, mTLS, and secure communications.
Step 3: Certificate Authorities (CAs)
CAs are the trusted notaries of the digital world.
- They verify identity (e.g., that you own
example.com). - Then they issue a certificate, signing it with their own private key.
Example:
Think of Apple’s App Store: you trust an app because Apple vetted it.
Similarly, when Let’s Encrypt or DigiCert signs a cert, browsers trust it because they trust the CA itself.
Step 4: Validation
When a client (like a browser, API client, or IoT device) connects:
- The server presents its certificate.
- The client checks:
- Is the certificate signed by a trusted CA?
- Is it valid (not expired or revoked)?
- Does the certificate’s domain match the server’s domain?
- If all checks pass, a secure channel (TLS) is established.
Example:
- You open
https://api.myapp.com. - Browser checks certificate → issued by Let’s Encrypt, valid until Dec 2025, domain matches.
- ✅ Green lock icon shows up.
If validation fails:
- Certificate expired → 🚨 browser warning.
- Issuer not trusted → ⚠️ “Your connection is not private.”
Try It Yourself: Generating a Certificate
You don’t need to buy one just to experiment. Let's try generating a self-signed certificate locally:
OpenSSL is a toolkit for working with cryptography and PKI. It lets you generate keys, create certificate requests, sign certificates, and manage SSL/TLS connections, making it essential for securing websites, APIs, and local testing.
# Generate a private key
openssl genrsa -out myapp.key 2048
- Creates a private key (myapp.key).
- The 2048 means it’s a 2048-bit RSA key (secure enough for most use cases).
- This private key is the foundation; it’s the secret that must never leave your machine.
# Generate a certificate signing request (CSR)
openssl req -new -key myapp.key -out myapp.csr
- A CSR is like an application form for a certificate.
- It contains:
- Your public key (derived from the private key).
- Metadata like domain name, organization, and location.
- If you were requesting a certificate from Let’s Encrypt or DigiCert, this CSR is what you’d send them.
# Create a self-signed certificate
openssl x509 -req -days 365 -in myapp.csr -signkey myapp.key -out myapp.crt
- Instead of sending your CSR to a Certificate Authority (CA), you sign it yourself.
- The result: myapp.crt, which is a self-signed certificate that’s valid for 365 days.
- This cert proves ownership of the keypair… but since you signed it, browsers don’t inherently trust it.
Now let's configure a local dev server (e.g., Express, Nginx) with this cert and key. Open it in the browser, and you’ll see the infamous “Not Secure” warning because your browser doesn’t trust your self-signed CA.
Here's the step-by-step guide to get a local server running with your self-signed cert. For this example, you must have Nginx installed in your system:
- Copy your generated files into a folder Nginx can read, that is:
/etc/nginx/ssl/myapp.crt
/etc/nginx/ssl/myapp.key
- Open the default site config and edit the nginx config:
sudo nano /etc/nginx/sites-enabled/default
Replace it with:
server {
listen 443 ssl;
server_name localhost;
ssl_certificate /etc/nginx/ssl/myapp.crt;
ssl_certificate_key /etc/nginx/ssl/myapp.key;
location / {
root /var/www/html;
index index.html;
}
}
- Now, restart the ngnix:
sudo nginx -t # test the config
sudo systemctl restart nginx
- Now, test it in your browser:
https://localhost/
You'll see this warning:
That’s the magic of PKI: trust isn’t just about having a certificate, it’s about who issued it.
Self-signed certs are great for learning and local testing, but in production, they fall short:
- Browsers and clients won’t trust them by default.
- Every device would need to manually install your certificate, which doesn’t scale.
- They don’t provide third-party validation of identity.
That’s where Certificate Authorities (CAs) come in, which we'll deep dive into in the next blog.
Conclusion
Even if you don’t notice it, PKI is everywhere in the software you use and build. From chat apps to APIs to Kubernetes clusters, it quietly keeps communication private, identities verified, and systems trusting each other.
At its heart, PKI is just three things: keys, certificates, and authorities. Learn how they work, and you can avoid a lot of headaches in production.
Next up, we’ll dive into Certificate Authorities: why they matter, how they issue trust, and how they make the internet and your apps safer beyond just self-signed certificates.
Top comments (0)