Forem: Divyanshu Soni

The Silent Database Conflict

Divyanshu Soni — Thu, 08 Jan 2026 17:18:28 +0000

Why "correct" credentials still fail, how TCP port ownership lies to you, and how a single filesystem path exposed the real bug

When Authentication Errors Aren't About Authentication

Few bugs are as cognitively expensive as the ones that invalidate your mental model.

You provision a PostgreSQL container.
You verify credentials.
You confirm the database is reachable.
And yet - your application fails with an authentication error.

At that point, developers tend to loop on the wrong axis: passwords, users, roles, and SSL flags. But sometimes the failure has nothing to do with authentication logic at all. Sometimes, you're authenticating against the wrong database instance entirely. Yes, "so naive", but that's what I bumped into while working on a project locally.

This post walks through a real-world Windows-specific failure mode where PostgreSQL port collisions silently reroute traffic, producing perfectly valid-but deeply misleading-errors.

The Symptom: A Healthy App That Claims the Database Is Unhealthy

The application was a Node.js API using PostgreSQL, Redis, and ClamAV, all orchestrated via Docker Compose. On startup, the service performed a health check and returned:

{
  "success": false,
  "data": {
    "database": "unhealthy"
  }
}

The underlying error was explicit:

FATAL: password authentication failed for user "postgres"

PostgreSQL error code 28P01.

At face value, this is a solved problem. Credentials mismatch. Fix the password.

Except - everything was already correct.

Environment Overview: Nothing Obviously Wrong

The system architecture was conventional:

Node.js API running on the host
PostgreSQL and Redis running in Docker
PostgreSQL is exposed on the default port

services:
  postgres:
    image: postgres:16-alpine
    container_name: fileguard-db
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: fileguard
    ports:
      - "5432:5432"

The application configuration matched exactly:

DB_HOST=localhost
DB_PORT=5432
DB_NAME=fileguard
DB_USER=postgres
DB_PASSWORD=postgres

No typos. No mismatches. No race conditions.

And crucially - connecting inside the container worked:

docker exec fileguard-db \
  psql -U postgres -d fileguard -c "SELECT 1"

The database was alive, accepting credentials, and behaving correctly.

So why was the application failing?

The Breakthrough: Reading Beyond the Error Code

The mistake wasn't technical; it was perceptual.

I was fixated on the error code, not the error context.

Here's the full error payload:

FATAL: password authentication failed
file: "d:\\pginstaller_13.auto\\postgres.windows-x64\\src\\backend\\libpq\\auth.c"
routine: "auth_failed"

That path matters.

Docker containers do not emit Windows filesystem paths.
Linux PostgreSQL builds do not reference d:\pginstaller_13.auto.

This error was not coming from the containerized PostgreSQL at all.

It was coming from a native PostgreSQL installation on Windows.

Root Cause: TCP Port Ownership and the Illusion of "localhost"

At some point in the past, PostgreSQL 13 had been installed directly on the host machine. It was configured as a Windows service and set to start automatically at boot.

That local instance was still running.

And it was already bound to port 5432.

On Windows, TCP port binding is exclusive. The first process to claim the port owns it. Docker does not "win" the port just because a container declares it.

So the actual topology looked like this:

Node.js → localhost:5432
        → Windows PostgreSQL (native install)
        → auth failure (different password)

Docker PostgreSQL
        → running correctly
        → never receives traffic

Docker was healthy. PostgreSQL was healthy. The application was healthy.

The routing was wrong.

Why This Is So Deceptive

This class of bug is hard to spot because:

localhost:5432 appears valid everywhere
PostgreSQL returns a legitimate authentication error
Docker reports the container as "running"
Credentials are correct—for the wrong database

Nothing crashes. Nothing times out. Everything fails cleanly.

That's the worst kind of failure.

Fixing the Problem (Properly)

Option 1: I had the choice to remap the Host Port

Avoid default ports for containerized services on developer machines.

ports:
  - "5433:5432"

Then update the application config:

DB_PORT=5433

This guarantees that traffic reaches the intended PostgreSQL instance and prevents future collisions.

Option 2: Disable or Remove the Native PostgreSQL Service

If the local installation is no longer needed:

net stop postgresql-x64-13
Set-Service postgresql-x64-13 -StartupType Disabled

Or uninstall it entirely.

This is effective, but brittle; future installations can reintroduce the conflict.

Diagnostic Techniques You Should Internalize

1. Treat File Paths as Execution Proof

PostgreSQL error paths reveal the build and environment:

Path Pattern	Source
`C:\Program Files\PostgreSQL\...`	Native Windows
`/usr/share/postgresql/...`	Linux / Docker

This is often more reliable than logs or container status.

2. Validate the Database in Isolation

Always verify the database from inside its runtime:

docker exec <container> psql -U <user> -d <db>

If this works, your database is not the problem.

3. Inspect Port Ownership Explicitly

Powershell:

Get-NetTCPConnection -LocalPort 5432

Then map the owning PID back to the process.

Ports don't lie. Assumptions do.

4. Assume You Have Multiple PostgreSQLs (Because You Probably Do)

Powershell:

Get-Service | Where-Object { $_.DisplayName -like "*PostgreSQL*" }

On Windows, forgotten services are common and silent.

The WSL Trap: When `localhost` Lies Again

WSL adds another abstraction layer.

Key facts:

WSL2 runs in a lightweight VM
It has a separate network namespace
localhost in WSL ≠ localhost in Windows

This leads to situations where:

Browser access works
PowerShell access works
curl from WSL fails

This is not an application issue. It's a networking boundary.

Sanity check:
If it works in the browser but not in WSL, stop debugging your app.

Mitigation:
Use host.docker.internal or the Windows host IP when accessing services from WSL.

Lessons Worth Remembering from the above incident:

Authentication errors can be routing errors.
Ports define reality, not configuration files.
Windows silently preserves old infrastructure.
Docker health ≠ network reachability.
File paths in stack traces are diagnostic signals, not noise.

Closing Thought

This bug wasn't complex. It wasn't advanced. It wasn't novel.

It was invisible.

And invisibility is what makes engineers waste hours debugging systems that are actually working perfectly, just not the ones they think they're talking to.

Next time PostgreSQL tells you authentication failed and you're sure the password is correct, pause and ask a more dangerous question or some uncomfortable question to yourself, for example:

"Which PostgreSQL am I actually connected to?"

That question saves time. And sanity.

Understanding SSH: A Beginner's Guide

Divyanshu Soni — Tue, 02 Dec 2025 05:06:32 +0000

When you hear people in tech talk about SSH, they're usually referring to a way of securely connecting to another computer over the internet or a network. The full form of SSH is Secure Shell.

At first, that might sound abstract, so let's start with a simple picture.

Imagine you have a computer at home, and another one sitting in a data center somewhere far away. You want to log into that remote computer and run commands, just as if you were sitting in front of it. That's exactly what SSH allows you to do, but in a safe and encrypted way.

What Exactly Is SSH?

SSH stands for Secure Shell. It's a cryptographic network protocol that lets you:

Log into remote computers securely
Execute commands on machines you can't physically touch
Transfer files without anyone snooping
Create encrypted tunnels for other network traffic

When you hear "I'll SSH into the server," someone is saying they're about to securely connect to a remote machine and control it through the command line.

Why SSH Was Invented

Before SSH existed, system administrators used tools like:

Protocol	Problem
Telnet	Sent everything in plain text: passwords, commands, everything
rlogin	No encryption, trusted hosts based on IP (easily spoofed)
FTP	Passwords transmitted in clear text

Here's how bad it was: Anyone on the same network could run a packet sniffer and see:

USER: admin
PASS: supersecret123

Literally readable. No encryption. Nothing.

In 90s, a Finnish researcher created SSH after his university network was attacked. The attacker had sniffed passwords right off the wire.

SSH was born from a real security incident and not theoretical paranoia.

The analogy: Telnet was like shouting your bank PIN across a crowded room. SSH is like whispering it through an encrypted radio; only you and your bank can decode.

SSH Protocol Versions

There are two versions of SSH:

Version	Status	Notes
SSH-1	Deprecated	Has known vulnerabilities. Never use it.
SSH-2	Current Standard	Complete protocol redesign. What everyone uses today.

SSH-2 isn't just an update, but it's a complete rewrite with:

Better key exchange algorithms
Improved integrity checking
Support for multiple authentication methods in one session

Always ensure your systems use SSH-2. Most modern systems do by default, but legacy systems might not.

How SSH Actually Works

Let's demystify what happens when you type ssh user@server.com and press Enter.

Phase 1: TCP Connection

SSH runs over TCP, typically on port 22. Your client initiates a standard TCP handshake:

Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK

Connection established. Now the SSH protocol begins.

Phase 2: Protocol Version Exchange

Both sides announce their SSH version:

Client: SSH-2.0-OpenSSH_8.9
Server: SSH-2.0-OpenSSH_8.4

They agree to use SSH-2. If either only supports SSH-1, modern clients will (and should) refuse to connect.

Phase 3: Key Exchange (The Magic)

This is where cryptographic wizardry happens. The goal: create a shared secret key that no eavesdropper can know.

The most common algorithm is Elliptic Curve Diffie-Hellman (ECDH):

########### Key Exchange (Simplified version) ###########           

1. Client and Server agree on mathematical parameters         

2. Client generates: private value (a), public value (A)      
     Server generates: private value (b), public value (B)      

3. They exchange public values (A and B)                      
     [Attacker can see A and B - doesn't help them]             

4. Client computes: shared_secret = B^a                       
     Server computes: shared_secret = A^b                       
     [Both arrive at the SAME secret!]                          

5. This shared secret derives the session encryption keys

The crux here is: The shared secret is never transmitted. An attacker watching every packet still can't compute it.

Phase 4: Server Authentication (Host Keys)

Here's something many beginners miss: before you authenticate to the server, the server authenticates to you.

When you connect to a server for the first time, you see:

The authenticity of host 'server.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf1234567890...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is critical. The server is proving its identity using its host key.

If you type yes, the fingerprint is saved to ~/.ssh/known_hosts
Future connections verify the server's key matches
If it doesn't match, SSH screams at you, like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

This protects against man-in-the-middle attacks. If an attacker intercepts your connection and presents their own server, the fingerprint won't match.

Pro tip: On first connection, verify the fingerprint through an out-of-band channel (ask your hosting provider, check their documentation, etc.)

Phase 5: User Authentication

Now you prove who you are. SSH supports several methods:

Method 1: Password Authentication

ssh user@server.com
# Prompts for password

Simple, but not recommended for several reasons:

Passwords can be brute-forced
Vulnerable to keyloggers
You have to type it every time (no automation)

Method 2: Public Key Authentication (Preferred)

This uses asymmetric cryptography, which is a key pair:

Key	Location	Purpose
Private Key	Your computer (`~/.ssh/id_ed25519`)	Never leaves your machine. Proves your identity.
Public Key	Server (`~/.ssh/authorized_keys`)	Can be shared freely. Verifies signatures from your private key.

How it works:

The private key never leaves your machine. The server only sees proof that you have it.

Method 3: Certificate-Based Authentication

Used in enterprise environments. A Certificate Authority (CA) signs user keys, and servers trust the CA rather than individual keys.

Phase 6: Encrypted Session

After authentication, everything is encrypted using symmetric encryption (AES-256, ChaCha20, etc.).

Why switch from asymmetric to symmetric? Speed. Symmetric encryption is ~1000x faster.

Every packet also includes a MAC (Message Authentication Code): a cryptographic checksum that detects tampering.

SSH Key Types

When generating keys, you'll need to choose an algorithm:

Algorithm	Key Size	Status	Recommendation
RSA	2048-4096 bits	Still secure	Use 4096 bits if you must use RSA
DSA	1024 bits	Deprecated	Never use
ECDSA	256/384/521 bits	Secure	Good, but some concerns about NIST curves
Ed25519	256 bits	Highly recommended	Fast, secure, small keys

This command creates a new SSH key pair using the Ed25519 algorithm.

ssh-keygen -t ed25519 -C "your_email@example.com"

Ed25519 advantages:

Faster than RSA
Smaller keys (easier to manage)
No concerns about weak random number generators
Designed to be resistant to side-channel attacks

Commands Every Developer Must Know

Generating SSH Keys

# Generate an Ed25519 key (recommended)
ssh-keygen -t ed25519 -C "your_email@example.com"


# Generate an RSA key (if Ed25519 isn't supported)
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

You'll be asked for:

File location - Press Enter for default (~/.ssh/id_ed25519)
Passphrase - Encrypts your private key. Use one!

Here,

-t: type - Specifies the type of key to generate → here it's ed25519.

-C: comment - Adds a comment/label to the key → usually your email to identify the key later.

Copying Your Public Key to a Server

# The easy way
ssh-copy-id user@server.com

# Manual way (if ssh-copy-id isn't available)
cat ~/.ssh/id_ed25519.pub | ssh user@server.com "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Basic Connection

# Standard connection
ssh user@server.com

# Specify a different port
ssh -p 2222 user@server.com

# Use a specific key
ssh -i ~/.ssh/my_special_key user@server.com

# Connect with verbose output (debugging)
ssh -v user@server.com      # Basic
ssh -vv user@server.com     # More detail
ssh -vvv user@server.com    # Maximum verbosity

SSH Escape Sequences

While in an SSH session, press ~ after a newline for special commands:

Sequence	Action
`~.`	Disconnect (kill frozen session)
`~^Z`	Background SSH
`~#`	List forwarded connections
`~?`	Show all escape sequences
`~~`	Send literal `~`

Life saver: When a session freezes, press Enter then ~. to force disconnect.

SSH Security Best Practices

1. Use Key-Based Authentication Only

# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

sshd_config is the main configuration file for the SSH server daemon (sshd).

2. Disable Root Login

# /etc/ssh/sshd_config
PermitRootLogin no

3. Change the Default Port (Security Through Obscurity)

# /etc/ssh/sshd_config
Port 2222

This doesn't make you "secure," but it reduces automated attack noise significantly.

4. Limit User Access

# /etc/ssh/sshd_config
AllowUsers alice bob
# or
AllowGroups sshusers

5. Use Strong Key Types

# /etc/ssh/sshd_config
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

6. Enable Two-Factor Authentication

Use tools like google-authenticator-libpam to require TOTP codes.

7. Set Up Fail2Ban

Automatically ban IPs with too many failed attempts:

sudo apt install fail2ban

8. Keep SSH Updated

# Check version
ssh -V

# Update
sudo apt update && sudo apt upgrade openssh-server

9. Audit Your authorized_keys

Regularly review who has access:

cat ~/.ssh/authorized_keys

Remove keys from former employees, old devices, etc.

10. Use a Passphrase on Your Private Key

If someone steals your key file, the passphrase is your last defense.

Troubleshooting Common SSH Problems

"Permission denied (publickey)"

Causes:

Key not added to authorized_keys
Wrong permissions on ~/.ssh or key files
Wrong key being used

Fix permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Debug:

ssh -vvv user@server.com 2>&1 | grep -i "offering\|trying"

"Connection refused"

Causes:

SSH server not running
Firewall blocking port 22
Wrong port

Check:

# Is SSH running on the server?
sudo systemctl status sshd

# Is the port open?
sudo netstat -tlnp | grep 22

"Host key verification failed"

Cause: Server's host key changed (or you're being attacked).

If legitimate (server rebuilt, etc.):

ssh-keygen -R server.com

Connection Timeout

Try:

# Keep connection alive
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@server.com

Or in ~/.ssh/config:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

SSH in the Real World: Common Scenarios

Scenario 1: Git over SSH

Most developers use SSH for Git:

# Clone using SSH
git clone git@github.com:username/repo.git

# Test your GitHub SSH connection
ssh -T git@github.com

Scenario 2: Deploying Applications

# Deploy script using SSH
ssh deploy@prod "cd /var/www/app && git pull && npm install && pm2 restart all"

Scenario 3: Database Access

# Tunnel to access remote PostgreSQL
ssh -L 5432:localhost:5432 user@dbserver.com

# Now connect locally
psql -h localhost -U dbuser -d mydb

Scenario 4: Accessing Cloud Instances

# AWS EC2
ssh -i ~/.ssh/aws-key.pem ec2-user@ec2-xx-xx-xx-xx.compute.amazonaws.com

# Google Cloud
gcloud compute ssh instance-name

# Azure
ssh azureuser@vm-public-ip

SSH Quick Reference

Connections

• ssh user@host - basic

• ssh -p 2222 user@host - custom port

• ssh -i key user@host - specific key

• ssh -J jump user@host - jump host

Key Management

• ssh-keygen -t ed25519 - generate key

• ssh-copy-id user@host - copy key

• ssh-add ~/.ssh/key - add key

• ssh-add -l - list keys

Escape Sequences (run after pressing Enter)

• ~. - disconnect

• ~^Z - background

• ~# - list forwards

Debugging

• ssh -v user@host - verbose

• ssh -vvv user@host - max verbose

Important Files

• ~/.ssh/config - client config

• ~/.ssh/known_hosts - server fingerprints

• ~/.ssh/authorized_keys - allowed public keys

• /etc/ssh/sshd_config - server config

Permissions

• chmod 700 ~/.ssh

• chmod 600 ~/.ssh/id_ed25519 - private key

• chmod 644 ~/.ssh/id_ed25519.pub - public key

• chmod 600 ~/.ssh/authorized_keys

Conclusion

SSH is one of those technologies that seems simple on the surface: ssh user@server, done. But underneath lies decades of cryptographic engineering designed to keep your connections secure.

What you should remember:

SSH encrypts everything - your credentials never travel in plain text.
Key-based auth beats passwords - always use Ed25519 keys.
Host verification matters - that fingerprint warning exists for a reason.
The config file is your friend - stop typing long commands.
Security is ongoing - audit keys, update software, limit access.

Whether you're managing cloud infrastructure, deploying applications, or just pushing code to GitHub, SSH is the secure foundation that makes it all possible.

Digital Certificates: Anatomy, Lifecycle, and Best Practices

Divyanshu Soni — Mon, 24 Nov 2025 11:39:03 +0000

Picture this:

You've built a rock-solid PKI infrastructure. Your root CA is locked down offline. Your intermediate CAs are issuing certificates smoothly. Everything looks perfect.

Then production breaks:

Your API gateway goes down at 3 AM because someone forgot to renew a certificate.
Microservices can't authenticate each other because the SANs don't match internal DNS names.
Your mobile app stops working because the certificate chain is incomplete.

Here's the uncomfortable truth: Having a PKI infrastructure isn't the same as understanding what actually makes it work. You can set up the fanciest Certificate Authority in the world, but if you don't understand certificates themselves, you're building on quicksand.

When developers first learn about PKI, they often focus on the big picture: Certificate Authorities, trust chains, and cryptographic algorithms. Important stuff, sure. However, the real complexity lies in the certificates themselves, where production incidents actually occur.

This is where theory meets practice:

What information does a certificate actually contain?
How do you generate, sign, deploy, and renew certificates without causing downtime?
What happens when certificates expire or get compromised?

Understanding certificates means understanding how trust actually works in production systems.

What Actually Is a Digital Certificate?

At its core, a digital certificate is a digitally signed document that binds an identity to a public key. Think of it as a passport for the digital world.

Identity binding:

The certificate contains information about who or what it represents (a website, server, person, device, or service).
This identity is tied to a public key that others can use to encrypt data to you or verify your signatures.

Cryptographic proof:

The certificate holder keeps the corresponding private key secret.
When they need to prove identity, they perform a cryptographic operation that only someone with the private key could do.

Authority stamp:

The certificate is signed by a Certificate Authority (CA).
This signature proves the certificate hasn't been tampered with and that the CA verified the identity.

Why Certificates Matter for Developers

You interact with certificates constantly:

Every https:// connection verifies the website's certificate.
Microservices authenticate each other using mutual TLS (mTLS).
Load balancers and API gateways use certificates to encrypt traffic.
IoT devices present certificates to prove they're legitimate.

Without properly configured certificates, your entire security model falls apart.

The Anatomy of an X.509 Certificate

Digital certificates follow the X.509 standard. Let's break down what's inside.

- Version and Serial Number

Version: Modern certificates are always v3 because that's the version that supports extensions.

Serial Number: A unique identifier assigned by the CA. Think of it like a passport number. When you need to revoke a certificate, you reference it by serial number.

- Issuer

The Issuer field identifies the CA that signed the certificate. It contains fields like Common Name (CN), Organization (O), and Country (C).

When a client receives a certificate, it checks if the issuer is in its trust store. If not, the connection fails.

- Subject

The Subject field identifies the entity the certificate represents.

Historically, the Common Name (CN) was used for domain names. But here's the thing - modern browsers and TLS implementations ignore the Common Name for hostname verification. They rely entirely on the Subject Alternative Name (SAN) extension instead. I've seen this trip up even experienced developers.

- Validity Period

Every certificate has a start date (Not Before) and an end date (Not After).

Why you care: Expired certificates cause immediate failures. Browsers show scary warnings. API connections break.

Modern policy changes: The CA/Browser Forum has been reducing maximum certificate lifetimes:

Current limit: 398 days (about 13 months).
Scheduled: 200 days (2026), 100 days (2027), 47 days (2029).

You simply can't expect humans to manually renew certificates every 47 days across hundreds of services.

- Public Key and Algorithm

Common algorithms:

RSA: Traditional choice. 2048 bits minimum, 4096 for higher security.
ECDSA: Modern, more efficient. Common curves: P-256, P-384.
Ed25519: Newer, fast, and secure. Check compatibility though.

Best practice: For new systems, prefer ECDSA P-256 or Ed25519. For legacy compatibility, RSA 2048 minimum.

- Signature

The CA's signature over all certificate data. This proves the certificate was issued by that CA and hasn't been tampered with.

- Extensions: Where the Real Power Lives

Subject Alternative Name (SAN): Lists all identities the certificate is valid for: domain names, IP addresses, URIs, etc.

This matters a lot: Modern TLS implementations require SANs. If you're securing api.example.com and www.example.com, both must be in the SAN field.

Example SANs:

DNS:api.example.com
DNS:service-a.default.svc.cluster.local
IP:192.168.1.100

Key Usage (KU): Defines the cryptographic operations the certificate's key can perform:

digitalSignature: signing data
keyEncipherment: encrypting keys
keyAgreement: key exchange protocols

Extended Key Usage (EKU): Specifies purposes the certificate can be used for:

serverAuth: TLS server authentication (HTTPS servers)
clientAuth: TLS client authentication (mutual TLS)
codeSigning: signing code or binaries
emailProtection: S/MIME email

Common mistake I see all the time: Using a web server certificate (serverAuth only) for a microservice that needs to act as both client and server. The TLS handshake fails when the service tries to authenticate as a client. Your certificates need both serverAuth and clientAuth for mTLS.

Basic Constraints: Defines whether the certificate is a CA certificate or a subscriber certificate.

CA:TRUE → Can issue other certificates
CA:FALSE → End-entity certificate, can't sign others

Security critical: If you accidentally issue a subscriber certificate with CA:TRUE, you've created a massive security hole. That certificate can now issue arbitrary trusted certificates.

CRL Distribution Points and OCSP URI: Tell clients where to check if the certificate has been revoked.

Operational reality: Revocation checking is historically unreliable. Many clients fail open. This is why short-lived certificates are becoming preferred - they reduce the window of exposure.

Certificate Types: When to Use Each

TLS/SSL Server Certificates

Purpose: Enable HTTPS for websites and secure APIs.

Key characteristics:

Extended Key Usage: serverAuth
SANs contain domain names
Issued by public CAs (for public services) or private CAs (for internal)

Common challenges:

Expired certificates taking sites offline
SAN mismatches causing browser warnings
Missing intermediate certificates

Automation is critical: Use ACME with certbot, cert-manager, or cloud certificate services.

Client Certificates (for Mutual TLS)

Purpose: Authenticate clients to servers in microservices and zero-trust architectures.

Key characteristics:

Extended Key Usage: clientAuth (often combined with serverAuth)
Usually issued by internal private CAs

Best practice: Use short-lived certificates (hours or days) and automate rotation completely.

Code Signing Certificates

Purpose: Sign software, binaries, container images.

Key characteristics:

Extended Key Usage: codeSigning
Private keys must be extremely well protected (usually in HSMs)
Longer validity periods (signed artifacts may be used for years)

Best practice: Store code signing keys in HSMs. Never in source code repos.

IoT and Device Certificates

Purpose: Provide identity to devices, sensors, edge hardware.

Key characteristics:

Often use lightweight algorithms (ECDSA) for constrained devices
Longer validity periods (devices may be offline for extended periods)
Provisioned during manufacturing or device onboarding

Common challenges:

Securely provisioning certificates into millions of devices at scale
Revoking certificates for offline or rarely connected devices
Limited CPU and memory requiring lightweight crypto

S/MIME Certificates (Email)

Purpose: Sign and encrypt email messages.

Key characteristics:

Extended Key Usage: emailProtection
Subject contains email address
Often stored on smart cards or hardware tokens

Honestly, the user experience in most email clients is... not great. But when you need secure email, this is how it's done.

The Certificate Lifecycle

Here is the complete lifecycle of a Digital Certificate, from key generation and CSR creation to issuance to renewal.

Stage 1: Key Generation

Everything starts with a key pair: a private key and a public key. The private key must be kept secret. The public key will be embedded in the certificate.

Who generates the key: The subscriber (the entity that will use the certificate) generates the key pair. For high-security use cases, keys are generated inside an HSM and never leave it.

Generate an ECDSA P-256 key:

openssl ecparam -genkey -name prime256v1 -noout -out server.key

Generate an RSA 2048-bit key:

openssl genrsa -out server.key 2048

Generate an Ed25519 key:

openssl genpkey -algorithm ed25519 -out server.key

Security critical: The private key must be protected. If it leaks, attackers can impersonate the certificate holder. Store keys in HSMs, Kubernetes Secrets with RBAC, or cloud key management services. Never commit keys to source control.

Stage 2: Certificate Signing Request (CSR)

The CSR contains your public key, identity information, and requested extensions. You send it to a CA.

Create a CSR with SANs:

openssl req -new -key server.key -out server.csr \
  -subj "/CN=api.example.com/O=MyCompany/C=US" \
  -addext "subjectAltName=DNS:api.example.com,DNS:www.example.com"

Note: If you're using ACME or cert-manager, CSR creation is automated.

Stage 3: Certificate Issuance

The CA performs validation:

For public TLS certificates:

Domain Validation (DV): CA checks you control the domain via file or DNS challenge.
Organization Validation (OV): CA verifies your organization is legitimate.
Extended Validation (EV): Most rigorous, requiring legal verification.

For private/internal certificates:

Validation is defined by your internal policies.

Stage 4: Certificate Deployment

Example: Deploy to Nginx

server {
  listen 443 ssl;
  server_name api.example.com;

  ssl_certificate /etc/ssl/certs/api.pem;
  ssl_certificate_key /etc/ssl/private/api.key;
  ssl_protocols TLSv1.2 TLSv1.3;

  # Enable OCSP stapling
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/ssl/certs/ca-bundle.pem;
}

Kubernetes deployment with cert-manager:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-cert
  namespace: default
spec:
  secretName: api-tls
  duration: 24h
  renewBefore: 6h
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com
    - www.example.com

cert-manager handles everything: key generation, CSR, issuance, storage, and automatic renewal.

What happens:

cert-manager creates a private key and CSR.
It submits the CSR to the Let's Encrypt ACME server.
It completes the ACME challenge to prove domain ownership.
Let's Encrypt issues the certificate.
cert-manager stores the certificate and key in the api-tls Secret.
Your pods mount that Secret and use it for TLS.
Six hours before expiry, cert-manager automatically renews.

Result: Zero manual intervention. No downtime from expired certificates. This is how it should be.

Stage 5: Validation at Runtime

When a client connects, it checks:

Signature verification: Builds a chain to a trusted root CA.
Validity period: Current time is within Not Before and Not After.
Hostname matching: Hostname is listed in the certificate's SANs.
Revocation checking: May query CRL or OCSP.
Key Usage: Certificate is authorized for the operation.

If any check fails, connection is rejected.

Common failures:

Missing intermediate certificate
SAN mismatch
Expired certificate

Stage 6: Renewal and Rotation

Key concepts:

Renewal: New certificate, often same key pair.
Rotation: New key pair and new certificate. More secure.

Best practices:

Automate renewal with certbot, cert-manager, or cloud services.
Renew when 70-80% through lifetime.
Monitor expiry dates with alerts at 30, 14, 7, 2 days.

Example: cert-manager automatic renewal

duration: 24h
renewBefore: 6h

Certificates valid 24 hours, renewed 6 hours before expiry. Zero manual intervention.

Stage 7: Revocation

Sometimes you need to revoke before expiry:

Private key compromised
Certificate issued incorrectly
Service decommissioned

Revocation mechanisms:

CRL: CA publishes list of revoked serial numbers. Clients download periodically.

OCSP: Real-time query to check if certificate is revoked.

OCSP Stapling: Server fetches OCSP response and includes it in TLS handshake. Better privacy and performance.

Modern best practice: Use short-lived certificates. If certificates expire in 24 hours, revocation becomes less critical.

Stage 8: Monitoring

What to monitor:

Expiry dates: Alert at 30, 14, 7, 2 days. Use Prometheus with ssl_exporter or similar.

Certificate Transparency logs: Subscribe to CT monitors (like crt.sh) to detect unexpected certificates for your domains.

TLS handshake health: Monitor success rates. Failures often indicate certificate problems.

Example Prometheus alert:

alert: CertificateExpiryWarning
expr: ssl_cert_not_after - time() < 86400 * 14  # 14 days
for: 1h
labels:
  severity: warning
annotations:
  summary: "Certificate {{ $labels.instance }} expires in less than 14 days"

Modern Certificate Policies

Shrinking Certificate Lifetimes

The CA/Browser Forum has been progressively reducing maximums:

Pre-2015: 5 years or more
2020: 398 days
Upcoming: 200 days (2026), 100 days (2027), 47 days (2029)

What this means:

Manual certificate management is already painful at 398 days.
At 47 days, it's impossible at scale.
You must automate key generation, issuance, deployment, and renewal.

Don't wait. Automate now.

Practical Tooling Patterns

Pattern 1: Public Websites - Let's Encrypt + ACME

# Install certbot
sudo apt-get install certbot python3-certbot-nginx

# Request a certificate
sudo certbot certonly --nginx -d api.example.com -d www.example.com

# Automatic renewal is set up

Tip: Use staging environment for testing to avoid rate limits.

Pattern 2: Kubernetes - cert-manager

ClusterIssuer for Let's Encrypt:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Certificate resource:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-cert
spec:
  secretName: api-tls
  duration: 90d
  renewBefore: 30d
  dnsNames:
    - api.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

cert-manager creates the Secret, your pods reference it, and renewal happens automatically.

Pattern 3: Internal PKI - Short-Lived Certificates with Vault

Why short-lived?

Compromised key? Exposure window is tiny.
Less reliance on revocation.
Forces automation.

Vault PKI setup:

# Enable PKI
vault secrets enable pki

# Configure CA
vault write pki/root/generate/internal \
  common_name="Internal CA" \
  ttl=87600h

# Create role for service certificates
vault write pki/roles/service-cert \
  allowed_domains="*.svc.cluster.local" \
  allow_subdomains=true \
  max_ttl="24h"

Services request certificates:

vault write pki/issue/service-cert \
  common_name="service-a.default.svc.cluster.local" \
  ttl="24h"

cert-manager can also use Vault as an issuer for Kubernetes integration.

Pattern 4: IoT - Device Certificate Provisioning

Common approaches:

Manufacturing-time provisioning: Generate and inject during manufacturing into secure storage (TPM, secure enclave).

Just-in-time provisioning: Device ships with factory cert, requests final certificate on first connection.

Cloud-managed IoT: AWS IoT Core, Azure IoT Hub, Google Cloud IoT handle certificate lifecycle.

Best practices:

Use ECDSA for smaller certs and faster operations
Use hardware-backed key storage
Plan for offline revocation scenarios

Common Pitfalls

Pitfall 1: Expired Certificates Taking Down Production

Why: Renewals weren't automated. Monitoring wasn't set up. Renewal failed silently.

How to avoid:

Automate renewals
Monitor expiry dates, alert well in advance
Test renewal processes regularly

Pitfall 2: SAN Mismatches

What happens: Client connects to service-a.default.svc.cluster.local, but certificate only lists service-a. TLS fails.

How to avoid:

Always use SANs, not Common Name
List all possible names (short names, FQDNs, external names)
Test TLS connections from client perspective

Pitfall 3: Missing Intermediate Certificates

What happens: "ERR_CERT_AUTHORITY_INVALID" even though certificate is valid.

Why: Server only sends leaf certificate, not intermediates.

How to avoid:

Configure servers to send full chain (leaf + intermediates)
Verify with:

openssl s_client -connect api.example.com:443 -showcerts

Pitfall 4: Private Key Leaks

What happens: Keys committed to GitHub, baked into Docker images, stored unencrypted.

How to avoid:

Never store private keys in source control
Use secret management: Kubernetes Secrets, Vault, cloud KMS
Use HSMs for high-value certificates
Rotate keys regularly

Pitfall 5: Revocation Not Working

Why: Clients aren't checking revocation. OCSP stapling not configured.

How to avoid:

Enable OCSP stapling
Use short-lived certificates
For critical situations, take compromised service offline immediately

Pitfall 6: Manual Processes That Don't Scale

What happens: Manual management works for 5 certificates, breaks at 500.

How to avoid:

Automate from day one
Use cert-manager, ACME clients, Vault, cloud services
Short-lived certificates force automation (which is good)

Conclusion

Digital certificates are what make trust operational. They turn abstract concepts into working systems that secure your websites, authenticate your microservices, and sign your code.

But they only work when you understand them:

What's inside: X.509 structure, SANs, Key Usage, validity periods
How they're used: Different types for different purposes
The full lifecycle: Key generation through renewal and revocation
What policy changes mean: Shorter lifetimes forcing automation
How to automate: ACME, cert-manager, Vault, cloud services
What goes wrong: Expired certs, SAN mismatches, missing intermediates, leaked keys

Key takeaways:

Automate everything. Manual management doesn't scale.
Use SANs correctly. Modern TLS ignores Common Name.
Monitor proactively. Track expiry dates and TLS health.
Protect private keys. HSMs for high-value, secret management for services.
Prefer short-lived certificates for internal services.
Test in staging. Renewal, rotation, revocation - all of it.

Understanding certificates deeply isn't optional. It's the difference between infrastructure that looks good on paper and one that actually works in production.

Subscribers in PKI: Who Actually Uses the Certificates

Divyanshu Soni — Tue, 11 Nov 2025 06:58:14 +0000

Imagine this scenario:

You've just set up a Private CA for your organization following best practices. You've got your root CA secured offline, intermediate CAs issuing certificates, and your policies are locked down. Everything looks perfect on paper.

Then reality hits:

Your microservices can't talk to each other because certificate SANs don't match the internal DNS names.
A certificate expires at 2 AM on a Saturday, taking down your entire API gateway.
Your IoT devices can't authenticate because someone forgot to provision certificates during manufacturing.
An engineer leaves the company, but their client certificate still grants VPN access two months later.

Here's the thing: you can have the most sophisticated PKI setup in the world, but if you don't understand subscribers, you'll still face production incidents.

When most developers learn about PKI, they focus on Certificate Authorities, trust chains, and cryptographic algorithms. These are important, but they're just infrastructure. The real question is:

Who actually uses these certificates?
Where do they get deployed?
How do they prove identity in real systems?

That's where subscribers come in. They're not theoretical concepts, they're the real-world actors in your PKI system: the web server presenting a certificate when a browser connects, the microservice authenticating itself to another service, the IoT device proving its identity to your cloud backend, and the employee using a certificate to access your VPN.

Understanding subscribers means understanding how PKI actually works in production. It's the difference between having a certificate infrastructure and having one that actually secures your systems without breaking them.

What Exactly Is a Subscriber in PKI?

A subscriber is any entity (human, service, device, or application) that has been issued a digital certificate and actually uses it for cryptographic operations.

This could be:

A web server using a certificate to enable HTTPS connections.
A microservice presenting a client certificate for mutual TLS (mTLS).
An IoT device authenticating itself with an embedded certificate.
An employee using a certificate stored on a smart card to access company resources.

Here's the key part: the subscriber doesn't just have a certificate. They actively use it to prove their identity, encrypt communications, and sign data.

Think of it like this: if a Certificate Authority is like a passport office that issues passports, then subscribers are the people who actually use those passports when they travel. The passport (certificate) only becomes useful when someone presents it at border control (authentication).

How Subscribers Fit Into the PKI Ecosystem

The certificate binds identity to cryptography:

The subscriber gets a certificate that contains their identity information (like a domain name or service name) and a public key.
The subscriber keeps the corresponding private key secret and secure.
When the subscriber needs to prove who they are, they present the certificate and use the private key to perform cryptographic operations.

Subscribers interact with relying parties:

A relying party is anyone who needs to verify a subscriber's identity (like a browser verifying a website's certificate).
The relying party checks: Is this certificate signed by a CA I trust? Does the identity match? Is it still valid?

The trust chain connects everything:

The subscriber's certificate is signed by an intermediate CA, which is signed by a root CA.
The relying party trusts the root CA, so they can trust the entire chain down to the subscriber.

Roles in PKI: A Simple Breakdown

Role	What They Do
CA / Issuer	Issues and signs certificates; establishes the trust root.
Subscriber	Holds certificate + private key; uses the cert to prove identity or encrypt traffic.
Relying Party	Verifies the subscriber's certificate; decides whether to trust it based on CA rules.

Types of Subscribers: Who Actually Uses Certificates?

Not all subscribers are created equal. Different types have different needs, challenges, and configurations.

1. Servers, Applications, and Websites

Examples: Web servers, API endpoints, load balancers

What they need:

Domain names correctly listed in the certificate's SANs.
Certificate chains to a trusted CA.
Ability to renew certificates without causing downtime.

Common challenges:

Expired certificates taking entire sites offline.
Misconfigured domains causing browser warnings.
Downtime during certificate renewal.

2. Internal Services and Microservices

Examples: Kubernetes pods, service mesh sidecars, backend APIs

What they need:

Both client and server certificates for mutual TLS (mTLS).
Short-lived certificates (hours or days).
Service identities in SANs matching internal DNS.
Automated certificate rotation.

Common challenges:

SAN mismatches causing TLS handshake failures.
Manual renewal becoming impossible at scale.

This creates a zero-trust network where every service must prove its identity on every request.

3. Devices: IoT and Edge Computing

Examples: Smart sensors, cameras, industrial equipment

What they need:

Secure provisioning of keys and certificates during manufacturing.
Lightweight certificates for constrained devices.
Ability to work offline or with intermittent connectivity.

Common challenges:

Securely provisioning certificates into millions of devices.
Revoking certificates for offline devices.
Resource constraints requiring lightweight crypto (ECC over RSA).

4. Users and People

Examples: Employees using client certs for VPN, S/MIME for email, smart cards

What they need:

Identity proofing before certificate issuance.
Secure private key storage (smart cards, hardware tokens).
User-friendly enrollment and renewal processes.

Common challenges:

Lost or stolen credentials requiring fast revocation.
Difficult certificate installation for non-technical users.
Multi-device complexity.

Real-World Subscriber Use Cases

Use Case 1: Securing a Public Website with TLS

The scenario: You run https://shop.example.com and customers need to trust they're connecting to your real site.

How it works:

Customer connects to your web server.
Server presents its TLS certificate.
Browser validates: signed by trusted CA, correct domain in SAN, not expired.
If valid, encrypted connection established.

Why it matters: Without this, customers see "Your connection is not private" warnings and leave.

Use Case 2: Microservices with Mutual TLS (Zero Trust)

The scenario: Dozens of microservices in Kubernetes need to authenticate each other.

How it works:

Service A presents a client certificate to Service B.
Service B presents its server certificate to Service A.
Both verify each other's certificates against the internal CA.
Communication proceeds only if both are valid.

Tools that help: cert-manager (Kubernetes), service meshes (Istio, Linkerd)

Use Case 3: IoT Device Authentication

The scenario: Smart temperature sensors need to securely send data to your cloud backend.

How it works:

Device provisioned with certificate during manufacturing.
Device presents certificate when connecting to cloud.
Backend verifies certificate to confirm legitimate device.
Encrypted sensor data flows securely.

Why it matters: Prevents hackers from injecting false data.

Use Case 4: Employee VPN Access

The scenario: Employees access internal resources remotely using certificates instead of just passwords.

How it works:

VPN server requests client certificate.
Employee's device presents certificate.
VPN verifies certificate is signed by company CA and not revoked.
Access granted.

Why it matters: Much harder to phish than passwords alone.

The Certificate Lifecycle: From a Subscriber's Perspective

Understanding the complete lifecycle helps you manage subscribers effectively:

Key Generation → Subscriber creates a private/public key pair. Private key must stay secret.
Certificate Signing Request (CSR) → Subscriber creates CSR containing public key and identity info.
Issuance → CA validates identity and signs the certificate.
Deployment and Use → Subscriber installs cert + key and uses it for TLS, signing, or encryption.
Validation → Relying parties check: signed by trusted CA? Identity matches? Valid and not revoked?
Renewal and Rotation → Before expiry, subscriber gets a new certificate (automate this!).
Revocation → If compromised or decommissioned, CA revokes the certificate via CRL/OCSP.
Monitoring → Track expiry dates, handshake failures, and certificate usage.

Configuration Example: Kubernetes with cert-manager

Let's look at how subscribers work in Kubernetes using cert-manager.

Scenario: Microservice service-a needs a certificate for mTLS.

Step 1: Set Up an Issuer

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: internal-ca-issuer
  namespace: default
spec:
  ca:
    secretName: internal-ca-secret

Step 2: Request a Certificate

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: service-a-cert
spec:
  secretName: service-a-tls
  issuerRef:
    name: internal-ca-issuer
  commonName: service-a.default.svc.cluster.local
  dnsNames:
    - service-a.default.svc.cluster.local
  duration: 24h
  renewBefore: 6h
  privateKey:
    algorithm: ECDSA
    size: 256

What happens automatically:

cert-manager generates key pair and CSR.
Submits CSR to internal CA.
CA signs certificate.
cert-manager stores cert and key in Kubernetes Secret.
After 18 hours, automatically renews.

Result: No manual intervention. No outages from expired certificates.

Common Pitfalls and How to Avoid Them

Pitfall 1: Identity Mismatches (CN/SAN Errors)

Problem: Certificate SANs don't match the hostname clients connect to.

Solution:

Always use Subject Alternative Names (SANs).
List all possible names in the SANs.
Test handshakes in staging.

Pitfall 2: Forgotten Renewals

Problem: Certificates expire and services break.

Solution:

Use short-lived certificates.
Automate renewal (ACME, cert-manager).
Set up expiry alerts.

Pitfall 3: Revocation Issues

Problem: Revoked certificates still trusted because relying parties don't check.

Solution:

Configure CRL/OCSP checking.
Use short-lived certs to reduce revocation window.
Test revocation process.

Pitfall 4: Private Key Leaks

Problem: Keys stored insecurely, attackers can impersonate subscribers.

Solution:

Never store keys in source code or container images.
Use HSMs, TPMs, or Kubernetes Secrets with RBAC.
Rotate keys regularly.

Pitfall 5: Trust Misconfigurations

Problem: Relying parties don't have correct root CA installed.

Solution:

Standardize CA trust roots across environments.
Use configuration management tools.
Test validation in each environment.

Pitfall 6: Scaling Problems

Problem: Manual certificate management breaks down at scale.

Solution:

Automate everything from day one.
Use cert-manager, Vault, or cloud PKI services.
Enforce short-lived certificates.

Modern Trends in Subscriber Management

1. Zero Trust Architecture

Every service, device, and user must prove identity on every request.
mTLS becomes standard.
Tools: Istio, Linkerd, SPIFFE/SPIRE.

2. Passwordless Authentication

Replace passwords with certificates on hardware tokens.
Tools: WebAuthn, FIDO2, smart cards.

3. IoT Fleet Management

Managing certificates for millions of devices.
Tools: AWS IoT Core, Azure IoT Hub, Google Cloud IoT.

4. Managed PKI Services

Cloud-managed instead of running your own CA.
Examples: AWS Private CA, Azure Key Vault, Infisical PKI.

5. Code and Container Signing

Developers and CI/CD pipelines become subscribers.
Tools: Sigstore, Docker Content Trust.

Best Practices for Managing Subscribers

1. Automate the Entire Lifecycle

Don't rely on manual processes.
Tools: cert-manager, ACME, Infisical, Vault.

2. Use Short-Lived Certificates

Hours or days, not months or years.
Forces automation, reduces revocation complexity.

3. Always Use Subject Alternative Names (SANs)

Common Name (CN) is deprecated.
List all valid identities in SANs.

4. Protect Private Keys

Generate keys on the device that will use them.
Use HSMs or TPMs for high-value keys.
Never store in source code or public registries.

5. Monitor and Alert

Track certificate expiration dates.
Monitor TLS handshake failures.
Alert well before expiry.

6. Plan for Revocation

Publish CRLs or provide OCSP endpoints.
Test revocation process regularly.

7. Standardize CA Trust Across Environments

Distribute root CAs consistently.
Test validation in dev, staging, production.

8. Enforce Strong Cryptography

RSA: 2048-bit minimum.
ECC: 256-bit minimum.
Avoid MD5, SHA-1.

Conclusion

Subscribers are where PKI stops being theoretical and becomes practical. They're the servers proving their identity, the microservices authenticating each other, the IoT devices securing infrastructure, and the employees accessing VPNs.

Key takeaways:

Subscribers are the real actors in PKI - Every certificate exists to be used by a subscriber.
Different types have different needs – Servers, microservices, devices, and users each face unique challenges.
Automate the lifecycle – Manual processes don't scale. Use cert-manager, ACME, and PKI management platforms.
Protect private keys – If they leak, the entire infrastructure fails.
Monitor proactively – Track expiration, handshake failures, and revocation status.
Subscribers determine PKI success – Expired certificates, misconfigured SANs, and leaked keys all trace back to subscriber management.

Understanding subscribers isn't just theory. It's about keeping your systems secure, available, and trustworthy. Whether you're securing a public website, building a zero-trust microservices architecture, managing an IoT fleet, or enabling passwordless authentication, subscribers are at the heart of it all.

Now that you understand what subscribers are, how they work, and how to manage them effectively, you're equipped to build and maintain secure PKI systems that actually work in production.

Private Certificate Authorities: Building Trust Inside Your Organization

Divyanshu Soni — Thu, 25 Sep 2025 14:30:44 +0000

Suppose you’re building a system with multiple moving parts:

An API gateway at the front.
A bunch of microservices handling authentication, payments, notifications, and analytics.
A Kubernetes cluster managing deployments.
A team of developers, CI/CD pipelines, and staging environments.

Everything works fine until you realize:

How do I make sure only my services can talk to each other securely?
How do I rotate credentials across services without manually updating configs?
How do I prevent one compromised service from impersonating another?

Tokens in environment files can get leaked. Shared API keys are brittle. Static secrets don’t scale.

What you really need is a system of trust that proves who each service is and secures every connection. That's where Certificate Authorities (CAs) and, more importantly, Private CAs come in. So let's understand what Certificate Authorities are and, most importantly, how you can build a Private CA with one of the most amazing developer tools out there.

What are Certificate Authorities (CAs)

A Certificate Authority(CA) is a trusted organization that plays a crucial role in digital security. Its main job is to make sure that when you connect to a website, service, or system, you're really talking to the right one and not to an imposter.

Here's what a CA actually does:

1. Verifies identity

Before issuing a certificate, the CA checks who you are.
For example, if a company applies for api.mybank.com, the CA confirms that this company really owns that domain.
In higher levels of validation, CAs may even check business registrations, addresses, or legal documents.

2. Issues digital certificates

After verification, the CA gives you a digital certificate.
This certificate contains your public key plus identity details (like your domain name or company info).
It's cryptographically signed by the CA, which makes it trustworthy.

3. Maintains ongoing trust

A CA doesn't just hand out certificates and disappear.
It also manages them:
- Signs certificates so others can verify authenticity.
- Revokes certificates if they're compromised, expired, or misused.
- Publishes revocation lists or online status checks so browsers and systems know which certs to trust.

I know this is getting a bit too theoretical, so let’s use a real-world analogy to make Certificate Authorities easier to understand.

Think of a CA like a passport office for the internet:

You show proof of identity → the passport office checks it.
They issue you a passport → this acts like your certificate.
Other countries trust your passport because they trust the authority that issued it.

In the digital world:

Your "passport" is the certificate.
The CA's "stamp/signature" proves it's real.
Other servers, browsers, or users trust you because they trust the CA behind your certificate.

Types of Certificate Authorities

Now that you know what a CA is, let's talk about the types you'll encounter as a developer.

1. Public CAs:

These are the big names like Let’s Encrypt, DigiCert, and GlobalSign.
Their root certificates are baked into browsers, operating systems, and devices.
That's why when you open https://google.com, your browser trusts it instantly.
Perfect for public-facing websites and APIs.

2. Private CAs:

These are CAs you (or your company) run internally.
Their certificates aren't trusted by the entire world, only by the systems where you explicitly install the CA's root certificate.
Perfect for microservices, Kubernetes clusters, staging environments, and DevOps pipelines.

3. Root vs Intermediate CAs:

Root CA: The ultimate trust anchor. It's like the government's central passport office. Rarely used directly, kept offline for safety.
Intermediate CA: Think of it as a regional passport office that does the day-to-day work. It's signed by the root and issues certificates to services, servers, and developers.
Why? This separation keeps the root safe while still letting you issue certificates flexibly.

Why Do Private CAs Exist If We Already Have Public CAs?

Public CAs like Let’s Encrypt or DigiCert are perfect when you need global trust, for example, securing https://myapp.com so any browser in the world knows it's safe.

But inside your organization, you often don't need (or even want) that global trust.

Your services talk to each other using internal hostnames (for eg, payments.svc.cluster.local), which public CAs won't issue certificates for.
You may need hundreds of certificates for microservices, clusters, and pipelines, and paying a public CA for each would be expensive and unnecessary.
You want full control over certificate policies, lifetimes, and revocation, and not depend on an external company.
Security teams often follow a zero-trust model, where every internal request must be authenticated, something that's easier with your own CA.

Both have their place, but only a Private CA can give you scalable, flexible, and cost-effective trust for internal systems.

What a Private CA Looks Like in Practice

A Private CA is simply a Certificate Authority you control, but the way it's structured is very intentional. Here's the breakdown:

Root CA

The root certificate is your ultimate trust anchor.
It's generated once and kept extremely secure, usually offline or in a hardware security module (HSM).
You don't use it for day-to-day work; its main job is to sign intermediate CAs.

Think of it as the government's central authority. It exists, but you don't go there every time you need a passport.

Intermediate CA

The intermediate CA handles daily certificate issuance.
It's signed by the root CA, so anything it issues is trusted.
This way, even if your intermediate gets compromised, the root remains safe.

This is your regional passport office, which means it's where most of the action happens.

Trust Distribution

Finally, you install your root CA on every server, cluster, and developer machine that should trust it.
Once that's done, anything signed by your intermediate is automatically trusted everywhere inside your organization.

In other words: one trust anchor, many identities.

Setting Up a Private CA

Let's say you want to try this out on your local machine. Here's a simple demo using OpenSSL:

OpenSSL is a free software toolkit that helps secure the internet. It's what makes HTTPS work by encrypting data and managing certificates so information stays private and trusted.

# Step 1: Generate a root key
openssl genrsa -out rootCA.key 4096

# Step 2: Create a root certificate
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

# Step 3: Generate an intermediate key
openssl genrsa -out intermediate.key 4096

# Step 4: Create a certificate signing request (CSR) for the intermediate
openssl req -new -key intermediate.key -out intermediate.csr

# Step 5: Sign the intermediate with the root CA
openssl x509 -req -in intermediate.csr -CA rootCA.pem -CAkey rootCA.key \
  -CAcreateserial -out intermediate.pem -days 1825 -sha256

At the end you’ll have:

rootCA.pem → your trust anchor.
intermediate.pem → your working CA for issuing certificates.

From here, you can start issuing certificates for your internal services.

This manual setup works for testing, but in real systems, it quickly becomes unmanageable. Here's how:

Certificate renewal → If you forget to renew, your services will break the moment certs expire.
Revocation → If a service's key leaks, you need a fast way to revoke its certificate.
Scale → With dozens of microservices, you'll need hundreds of certificates rotating all the time.

This is why companies rarely manage their Private CA by hand. Instead, they use tools to automate everything. This is where Infisical comes into the picture. You may already know Infisical as a secret management platform, but it also works exceptionally well for managing internal PKI.

With Infisical, you can build an internal PKI: optionally create or import a root CA, chain one or more intermediate CAs, and enforce certification policies via templates. You can automate issuing certificates to Kubernetes through the Infisical PKI Issuer + cert-manager, and sync certificates out to external systems using Certificate Syncs. The model encourages keeping the root CA secure (e.g. offline or external), enforcing short TTLs, and leveraging RBAC and identity controls, giving you tools for safer, automated service identity and credential rotation (so long as you configure it correctly).

Best Practices for Running a Private CA

When you move beyond experimenting and actually run a Private CA in production, a few best practices go a long way:

Keep your root CA offline: Generate the root key once, store it securely (HSM or encrypted offline storage), and never use it for day-to-day signing.
Use intermediate CAs for daily operations: Always issue service and server certificates from intermediates. If compromised, you can revoke and replace the intermediate without touching the root.
Rotate certificates frequently: Favor short-lived certificates (days or weeks, not years). Automated renewal prevents outages due to expired certs.
Enforce strict issuance policies: Define what domains/hostnames are allowed (CN, SANs). Restrict key usages (serverAuth, clientAuth) so certificates can't be misused.
Plan for revocation: Publish a Certificate Revocation List (CRL) or use OCSP so that compromised certificates can be invalidated quickly.
Monitor and alert: Always have monitoring in place to alert you when certificates are close to expiry. Nothing breaks production faster than an expired cert.
Use RBAC and logging: Control who can issue/revoke certificates. Keep an audit trail of every action taken in your PKI.

Conclusion

Certificate Authorities form the trust backbone of the internet, but private CAs give organizations the flexibility to secure their own systems. By following best practices and experimenting with small hands-on projects, developers can gain a practical understanding of how PKI works. Once you see certificates in action, from issuance to trust to revocation, you’ll realize that building a secure foundation isn’t just for big companies. It's an essential skill for anyone designing modern distributed systems.

PKI 101: Why Public Key Infrastructure matters

Divyanshu Soni — Mon, 08 Sep 2025 06:16:17 +0000

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.

CSS Positioning

Divyanshu Soni — Wed, 23 Jun 2021 16:16:24 +0000

In this article, I'll discuss what is CSS position property, how you can use it to create a variety of styling solutions on the webpage. And of course with some use cases to practice.

Let's dive in!

Introduction : HTML Document Flow

The HTML elements in a webpage that are described higher in the HTML file will be rendered in the browser earlier than the elements that are described lower as the HTML documents are displayed on the webpage from top to bottom.

The order in which the elements are displayed on a page by default is called normal flow. According to MDN :

Elements on a webpage layout are in the normal flow, if you have not applied any CSS to change the way they behave. And, as we began to discover, you can change how elements behave either by adjusting their position in that normal flow, or removing them from it altogether.

Refer here

Changing the values of the position property will change the flow of the document, which is a process called positioning. Let's learn different types of positioning and understand how to work with them.

Absolute Positioning

This refers to positioning relative to the bounds of the parent element, out of the normal flow.

Syntax:

element {
  position: absolute;
}

If there is no parent element, then it is set relative to the bounds of the browser viewport. So, with absolute positioning, the browser window will act as a parent from whose borders the distance is set:

Let's consider an example, in the picture below four blocks are positioned in normal flow i.e. their position is set to static by default.

Now, let's change the positioning of the element 3 to absolute.

Codepen

What happened here?? Basically the absolute positioning pulls the element out of the normal flow and all the blocks other than the block 3 in the normal flow neatly follow each other and occupy their space on the webpage. Here block 3 rises to the absolute level and since it is not in the plane between the blocks 1, 2 and 4 they shift towards each other.

*So, it can be said that the absolute plane lies on the top of the static plane. Keep this feature in mind while working with Absolute positioning.
*

Relative Positioning

A relatively positioned element is set relative to its original position on the page. Here is the syntax:

element {
  position: relative;
}

To see it, let's consider the same four blocks, but this time, only block 3 will be position: relative, and the rest will remain in the normal flow.

As expected, block-3 moved up by the distance that was indicated, but pay attention to the empty space where the third element had been earlier.

What happened here?? The block-3 exists on the page materially (the display of other elements around this block is calculated based on the space it occupies), but it still rises to a higher plane as an absolutely positioned element would. That's why the block-3 overlapped with block-2 and block-4 stayed in the place and did not move up.

What's the use of it ?
This property of CSS allows you to move the elements on the page anywhere without breaking the layout of the site because the occupied space remains duly occupied.

Fixed Positioning

Fixed positioning locks the element on the page relative to the visible part of the browser's viewport and maintains that position during vertical scrolling. Here is the syntax:

element {
  position: fixed;
}

Let's see an example.

Codepen

Sticky Positioning

In terms of functionality, the element on which sticky positioning is applied, it is between fixed positioning and relative positioning. The element is positioned relatively until the page is scrolled to a certain point, after which the positioning will be fixed.

Here is the syntax.

element {
  position: sticky;
}

Let's see an example.

Codepen

Conclusion

Thanks to positioning, we can flexibly control the position of the elements on
the page. It is used to create a variety of styling solutions for page
interfaces smoothly.

That's all for now. Thank you for reading! Do share your comments here.

Follow me for more such blogs and express your thoughts about the article on Twitter.

Further Resources -

Top 14 VS Code Extensions to learn Web Development in a better way!!

Divyanshu Soni — Tue, 05 Jan 2021 18:54:04 +0000

Here are the Top 14 VS Code Extensions that I personally use and recommend to Developers who are just starting their journey in the Web Development.

Click on the Extension to get more information and working of a particular Extension.

HTML5 Snippets 4,535,923 installs

2.HTML Boilerplate 849,643 installs

3.Color Highlight2,233,163 installs

4.CSS Peek 1,513,705 installs

5.Debugger for Chrome7,033,864 installs

6.ES7 React/Redux/GraphQL/React-Native Snippets2,199,645 installs

7.ES Lint12,333,000 installs

8.Github Pull Requests and Issues1,262,205 installs

9.HTML CSS Support 4,745,626 installs

10.Intellisense for CSS class names in HTML 2,894,808 installs

11.Javascript (ES6) Code Snippets 4,619,178 installs

12.Live Server 9,068,898 installs

13.Prettier - Code Formatter 10,035,184 installs

14.Emoji Snippets 24,747 installs

15.Beautify 5,967,980 installs

Do not forget to mention your favourite Extension in the comment section and do let me know if you know any important and amazing Extension other than mentioned above.

Forem: Divyanshu Soni

The Silent Database Conflict

When Authentication Errors Aren't About Authentication

The Symptom: A Healthy App That Claims the Database Is Unhealthy

Environment Overview: Nothing Obviously Wrong

The Breakthrough: Reading Beyond the Error Code

Root Cause: TCP Port Ownership and the Illusion of "localhost"

Why This Is So Deceptive

Fixing the Problem (Properly)

Option 1: I had the choice to remap the Host Port

Option 2: Disable or Remove the Native PostgreSQL Service

Diagnostic Techniques You Should Internalize

1. Treat File Paths as Execution Proof

2. Validate the Database in Isolation

3. Inspect Port Ownership Explicitly

4. Assume You Have Multiple PostgreSQLs (Because You Probably Do)

The WSL Trap: When localhost Lies Again

Lessons Worth Remembering from the above incident:

Closing Thought

Understanding SSH: A Beginner's Guide

What Exactly Is SSH?

Why SSH Was Invented

SSH Protocol Versions

How SSH Actually Works

Phase 1: TCP Connection

Phase 2: Protocol Version Exchange

Phase 3: Key Exchange (The Magic)

Phase 4: Server Authentication (Host Keys)

Phase 5: User Authentication

Method 1: Password Authentication

Method 2: Public Key Authentication (Preferred)

Method 3: Certificate-Based Authentication

Phase 6: Encrypted Session

SSH Key Types

Commands Every Developer Must Know

Generating SSH Keys

Copying Your Public Key to a Server

Basic Connection

SSH Escape Sequences

SSH Security Best Practices

1. Use Key-Based Authentication Only

2. Disable Root Login

3. Change the Default Port (Security Through Obscurity)

4. Limit User Access

5. Use Strong Key Types

6. Enable Two-Factor Authentication

7. Set Up Fail2Ban

8. Keep SSH Updated

9. Audit Your authorized_keys

10. Use a Passphrase on Your Private Key

Troubleshooting Common SSH Problems

"Permission denied (publickey)"

"Connection refused"

"Host key verification failed"

Connection Timeout

SSH in the Real World: Common Scenarios

Scenario 1: Git over SSH

Scenario 2: Deploying Applications

Scenario 3: Database Access

Scenario 4: Accessing Cloud Instances

SSH Quick Reference

Conclusion

Digital Certificates: Anatomy, Lifecycle, and Best Practices

What Actually Is a Digital Certificate?

Why Certificates Matter for Developers

The Anatomy of an X.509 Certificate

- Version and Serial Number

- Issuer

- Subject

- Validity Period

- Public Key and Algorithm

- Signature

- Extensions: Where the Real Power Lives

Certificate Types: When to Use Each

TLS/SSL Server Certificates

Client Certificates (for Mutual TLS)

Code Signing Certificates

IoT and Device Certificates

S/MIME Certificates (Email)

The Certificate Lifecycle

The WSL Trap: When `localhost` Lies Again