HTTPS Certificate Management for Developers in 2026

March 27, 2026 · Security, HTTPS, DevOps

HTTPS certificate management is no longer a “set it and forget it” checkbox. In 2026, short-lived certificates, aggressive browser warnings, and automated renewals mean developers need a repeatable, testable process. This guide walks through modern TLS certificate workflows, the tooling you should automate, and the gotchas that still bite teams in production.

What developers actually manage (beyond “SSL”)

TLS certificates are part of a broader chain of trust. In practice, you’ll manage:

• Private keys (rotation, storage, access control)
• Certificate signing requests (CSRs) with correct SANs
• Certificates and intermediate bundles (full chain)
• Automated renewals with ACME clients
• Server configs (SNI, OCSP stapling, HSTS, TLS versions)

Most production outages come from mismatched SANs, expired certs, or broken chains. Automation reduces risk, but only if you validate it end-to-end.

Recommended baseline in 2026

• CA: Let’s Encrypt or other ACME-compatible CA
• Validation method: HTTP-01 (simple) or DNS-01 (wildcards)
• Key type: ECDSA P-256 for modern performance; RSA 2048 if legacy clients still matter
• Renewal window: 30 days before expiry (or earlier for short-lived certs)
• Monitoring: Daily check + alert on <14 days remaining

Step 1: Generate a key and CSR with correct SANs

Common Name (CN) is not enough. Always include SANs. Use a config file to avoid missing a domain.

openssl req -new -newkey rsa:2048 -nodes -keyout example.key \
  -out example.csr -subj "/C=US/ST=NY/L=NYC/O=Example/OU=Dev/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Quick SAN validation (regex)

For CI checks, you can parse SANs from the CSR output and validate with a simple regex. Use a tester to iterate quickly, then bake it into your pipeline. Try the Regex Tester to verify patterns for domain lists before deploying.

Step 2: Use ACME for automation (Certbot or acme.sh)

ACME is the standard for automated issuance and renewal. The two most common options:

• Certbot (official Let’s Encrypt client, works with most servers)
• acme.sh (pure shell, great for lightweight environments)

Example: Certbot with Nginx

sudo certbot --nginx -d example.com -d www.example.com \
  --agree-tos -m admin@example.com --redirect --non-interactive

Example: acme.sh with DNS-01 (wildcards)

acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'
acme.sh --install-cert -d example.com \
  --key-file /etc/ssl/private/example.key \
  --fullchain-file /etc/ssl/certs/example.fullchain.pem \
  --reloadcmd "systemctl reload nginx"

DNS-01 is required for wildcard certs. It also avoids HTTP routing problems in multi-tenant or serverless setups.

Step 3: Serve the full chain

Many production issues are caused by serving only the leaf certificate. Always serve the full chain (leaf + intermediate). In Nginx, use a fullchain file.

ssl_certificate     /etc/ssl/certs/example.fullchain.pem;
ssl_certificate_key /etc/ssl/private/example.key;

Step 4: Enable OCSP stapling and modern TLS

OCSP stapling improves performance and reduces privacy leakage. Also disable legacy protocols.

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 1.0.0.1 valid=300s;
resolver_timeout 5s;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Step 5: Set HSTS (carefully)

HTTP Strict Transport Security (HSTS) prevents protocol downgrade. Start with a short max-age, then increase once you’re confident.

add_header Strict-Transport-Security "max-age=86400; includeSubDomains" always;

After a stable period, consider 6–12 months (15768000–31536000 seconds). Only add preload once you fully understand the consequences.

Certificate rotation and key management

Rotate keys on schedule (not just certs). A safe default is every 6–12 months. For high-security environments, rotate every 90 days alongside certificate renewals. Make sure the key lives in a restricted path, and consider using an HSM or KMS for production keys.

Key storage checklist

• Permissions: 600 (root-only)
• Backups: encrypted at rest
• Audit: track access to private keys

Monitoring: detect expiry before it hurts

Monitor every public endpoint daily. Don’t rely on one global check—CDNs, edge services, and internal services can all diverge.

Example: Bash check with OpenSSL

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

Example: Node.js expiration check

import tls from "tls";

const host = "example.com";
const socket = tls.connect(443, host, { servername: host }, () => {
  const cert = socket.getPeerCertificate();
  console.log(cert.valid_to);
  socket.end();
});

Example: Python expiration check

import ssl, socket
from datetime import datetime

host = "example.com"
ctx = ssl.create_default_context()
with ctx.wrap_socket(socket.socket(), server_hostname=host) as s:
    s.connect((host, 443))
    cert = s.getpeercert()
    exp = datetime.strptime(cert["notAfter"], "%b %d %H:%M:%S %Y %Z")
    print(exp)

Common failure modes (and how to prevent them)

• Missing SANs: Always generate CSRs with SANs; validate in CI.
• Wrong chain: Serve fullchain.pem, not cert.pem.
• Expired certs: Add alerts for <14 days remaining.
• HTTP-01 challenges failing: Use DNS-01 when behind CDNs or proxies.
• HSTS lockouts: Start with 1 day, then raise gradually.

JSON config examples: make it easy to review

Certificate automation often uses JSON for configuration. Format and review configs before shipping. Use the JSON Formatter to validate CI configs and avoid trailing commas or malformed arrays that break deploys.

Base64, URLs, and cert data in tooling

Certificates are often embedded in environments or APIs as Base64. If you need to inspect or share pieces of a certificate payload, the Base64 Encoder/Decoder and URL Encoder/Decoder are useful for quick checks and debugging.

Recommended workflow (summary)

• Use ACME with DNS-01 for wildcard or complex routing
• Rotate keys every 6–12 months (or 90 days for high-security)
• Serve full chains and enable OCSP stapling
• Roll out HSTS gradually
• Monitor expiry daily and alert at 14 days

Developer-friendly checklist

• CSR includes every domain and subdomain
• Certificate chain validated with openssl s_client
• Auto-renewal scheduled and tested in staging
• Expiry monitoring with alerts
• Documented rollback procedure

FAQ

Below are answers to common questions developers search for when managing HTTPS certificates.