DEV Community

Cover image for Digital Certificates: Anatomy, Lifecycle, and Best Practices
Divyanshu Soni
Divyanshu Soni

Posted on

Digital Certificates: Anatomy, Lifecycle, and Best Practices

#certificates #pki #architecture #devops

Picture this:

Broken production

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.

Digital Certificate Lifecycle

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
Enter fullscreen mode Exit fullscreen mode

Generate an RSA 2048-bit key:

openssl genrsa -out server.key 2048
Enter fullscreen mode Exit fullscreen mode

Generate an Ed25519 key:

openssl genpkey -algorithm ed25519 -out server.key
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

What happens:

  1. cert-manager creates a private key and CSR.
  2. It submits the CSR to the Let's Encrypt ACME server.
  3. It completes the ACME challenge to prove domain ownership.
  4. Let's Encrypt issues the certificate.
  5. cert-manager stores the certificate and key in the api-tls Secret.
  6. Your pods mount that Secret and use it for TLS.
  7. 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:

  1. Signature verification: Builds a chain to a trusted root CA.
  2. Validity period: Current time is within Not Before and Not After.
  3. Hostname matching: Hostname is listed in the certificate's SANs.
  4. Revocation checking: May query CRL or OCSP.
  5. 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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Services request certificates:

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

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)