Encryption, TLS, Certificates, And PKI

Purpose

Developers do not need to become cryptographers, but they do need to understand the difference between encryption, hashing, signing, certificates, TLS, and public key infrastructure.

The most important rule: do not invent cryptography. Use proven protocols, platform libraries, and reviewed configurations.

Core Concepts

Encryption In Transit

Use TLS for network communication:

• Browser to web app/API.
• Service to service where practical.
• Database connections where supported.
• Admin tools and remote access.

Good practices:

• Use modern TLS versions.
• Disable weak protocols and ciphers.
• Automate certificate renewal.
• Monitor certificate expiry.
• Avoid self-signed certificates in production unless the trust model is explicit and managed.

Encryption At Rest

Encryption at rest protects stored data if disks, snapshots, backups, or storage systems are exposed.

Use it for:

• Databases.
• File storage.
• Backups.
• Logs containing sensitive data.
• Developer machines where needed.

Remember: encryption at rest does not fix broken authorization. If the application is allowed to read all data and an attacker controls the application, the encryption layer may not save you.

Passwords

Never store passwords with plain hashing like SHA-256.

Use password-specific hashing algorithms such as:

• Argon2.
• bcrypt.
• PBKDF2.

Good practices:

• Use unique salts.
• Use strong work factors.
• Prefer managed identity providers where possible.
• Support MFA for high-risk accounts.

Digital Certificates

A certificate says: this public key belongs to this identity, according to a trusted certificate authority.

Common developer tasks:

• Configure HTTPS certificates.
• Renew certificates before expiry.
• Install trusted root/intermediate certificates in internal environments.
• Configure client certificates for mutual TLS where needed.
• Debug certificate chain errors.

Common failures:

• Expired certificate.
• Certificate name does not match host.
• Missing intermediate certificate.
• Private key not protected.
• Self-signed certificate not trusted by client.
• Wrong certificate installed in load balancer or ingress.

Key Management

Keys are more important than algorithms in daily operations. A strong algorithm with leaked keys is a locked door with the key taped to it.

Good practices:

• Store keys in a key vault or secrets manager.
• Rotate keys.
• Limit who can read/export keys.
• Separate keys by environment.
• Log key access.
• Avoid storing private keys in repos, scripts, or plain config files.

Signing And Integrity

Signing helps prove that data or software has not been changed and came from a trusted source.

Use cases:

• JWT signing.
• Package/artifact signing.
• Container image signing.
• Document signing.
• Webhook signature verification.
• Build provenance.

For webhooks, do not only trust the source IP. Verify signatures when supported.

Team Reference Guide

Guidelines For Teams

• Use standard libraries and managed services for crypto.
• Do not create custom encryption schemes.
• Protect keys and certificates as sensitive assets.
• Monitor certificate expiry.
• Verify signatures for external callbacks/webhooks.
• Use TLS consistently.

Reflection Questions

• Which certificate expiry would hurt us most?
• Where are secrets or keys currently too easy to access?
• Which webhook or integration should verify signatures?
• Which sensitive data should not exist in logs at all?

Further Study

• OWASP Cryptographic Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
• OWASP Transport Layer Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
• NIST Cryptographic Standards and Guidelines: https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/
• Let's Encrypt documentation: https://letsencrypt.org/docs/