Mtls

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): ...

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: ...