Tls

Why this post I started this mini‑project after seeing a common roadblock: PKIX path building failed when calling HTTPS services with OpenFeign. The goal was to create a tiny, runnable example that eliminates guesswork, shows how to configure client certificates and trust properly, and layers basic IAM policies on top. Reference: https://stackoverflow.com/questions/79835509/unable-to-configure-ssl-context-for-open-feign-client-getting-pkix-error What’s inside the example Two Spring Boot apps: Server: HTTPS on 8443, requires client certs (mTLS), and recognizes/authorizes callers with Spring Security’s X.509 support. Client: Spring Cloud OpenFeign calling the server via Apache HttpClient5 with a custom SSLContext. A one‑command cert toolchain (local CA → server/client certs → PKCS#12 keystores/truststores). An automated test script that runs a positive call (expected 200) and a negative call with an unauthorized client (expected 403). Project (ready to publish here): ...

Modern servers are expected to push hundreds of gigabits per second while keeping latency low and CPU use manageable. Two kernel-level innovations-socket sharding and kernel TLS (kTLS)-help make that possible. When paired with NIC TLS offload, the gains are even bigger. Socket Sharding Traditionally, only one process could accept() connections from a TCP socket. With Linux 4.5 (2016) and SO_REUSEPORT enhancements, multiple processes can share a listening socket. This “socket sharding” lets the kernel distribute connections efficiently across worker processes. ...

When implementing secure PostgreSQL connections, certificate creation forms the foundation of your PKI infrastructure. Whether you’re setting up a development environment or deploying enterprise-grade systems, understanding proper certificate creation practices is crucial. This guide explores certificate creation from the simple OpenSSL approach to enterprise-grade practices employed by major financial institutions like Credit Suisse/UBS and media companies like BBC. Related Reading: For implementing DN-based certificate authentication in PostgreSQL, see our DN Authentication guide. ...

Today, I’m diving into Distinguished Name (DN) authentication-a powerful feature that enables certificate-based authentication when the Common Name (CN) in your client certificate doesn’t match your PostgreSQL username. This approach is essential in enterprise environments where certificate naming conventions don’t align with database user naming requirements. Version Compatibility: The clientname=DN feature was introduced in PostgreSQL 14. If you’re using PostgreSQL 13 or earlier versions, this DN authentication method will not work and you’ll need to use traditional CN-based certificate authentication instead. ...

Mutual TLS (mTLS) for PostgreSQL provides strong, passwordless authentication and encryption. The most common cause of failed secure connections in real deployments is incorrect Subject Alternative Name (SAN) handling and trust configuration on the client side. This post explains how to set up SANs correctly, how hostname verification really works, and how to align PostgreSQL with enterprise PKI practices-using this repository’s cluster as a concrete example. Why SAN Matters More Than CN Modern TLS stacks validate the server’s identity against the SAN extension on the server certificate-not the Common Name (CN). When a PostgreSQL client connects to a host name (or IP), it will check: ...