Introduction

The exception javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify appears when Java shuts down a TLS connection and realizes the remote side closed the socket without sending the normal TLS shutdown alert. In a Spring Boot JDBC application, that usually means the problem sits in the database server, proxy, load balancer, or JDBC driver interaction rather than in Spring Boot itself. The first step is to determine whether the exception is merely noisy shutdown logging or an actual failed database operation.

What the Error Means

TLS connections are supposed to end with a close_notify alert from each side. Java's JSSE implementation tracks that state. If the peer simply drops the TCP connection, Java may complain when the socket is closed cleanly on the client side.

That leads to an important distinction:

• if your query succeeds and the exception appears only while closing the connection, the issue is often a shutdown-protocol mismatch or buggy peer behavior
• if the query itself fails, treat it as a real connectivity problem and inspect TLS versions, certificates, proxies, and driver configuration

In other words, the same message can be harmless noise in one system and a symptom of a broken TLS path in another.

Start by Verifying the JDBC Path

Use a minimal query with normal resource handling so you know the exception is not caused by application misuse.

1import java.sql.Connection;
2import java.sql.PreparedStatement;
3import java.sql.ResultSet;
4import javax.sql.DataSource;
5
6public class HealthCheck {
7    private final DataSource dataSource;
8
9    public HealthCheck(DataSource dataSource) {
10        this.dataSource = dataSource;
11    }
12
13    public int queryOne() throws Exception {
14        try (Connection connection = dataSource.getConnection();
15             PreparedStatement statement = connection.prepareStatement("select 1");
16             ResultSet rs = statement.executeQuery()) {
17            rs.next();
18            return rs.getInt(1);
19        }
20    }
21}

If this succeeds consistently but you still see the SSL exception during pool cleanup, focus on the network peer and driver rather than on the SQL logic.

Configure TLS Explicitly Instead of Relying on Defaults

A common cause of brittle TLS behavior is vague connection settings. Be explicit in the JDBC URL and trust-store configuration.

For PostgreSQL, a Spring Boot configuration might look like this:

1spring.datasource.url=jdbc:postgresql://db.example.com:5432/app?sslmode=verify-full
2spring.datasource.username=app
3spring.datasource.password=secret
4spring.datasource.hikari.maximumPoolSize=10
5spring.datasource.hikari.keepaliveTime=300000

For MySQL or MariaDB, the equivalent parameters differ, but the principle is the same: define a clear SSL mode and use a driver version that matches your server.

When you route traffic through a proxy, managed database endpoint, or TLS-terminating middlebox, confirm that it preserves correct TLS shutdown behavior. Java is often stricter than other clients about protocol correctness, so an intermediary that appears "good enough" elsewhere may still generate this warning in JDBC workloads.

Gather Evidence With TLS Debug Logging

Before changing random flags, capture one failing connection with JSSE debug logging:

java -Djavax.net.debug=ssl:handshake -jar app.jar

That output is noisy, but it tells you whether the handshake succeeded, which protocol version was negotiated, and whether the peer sent a proper close alert.

If the handshake is clean and only the shutdown is imperfect, the likely fixes are:

• upgrade the JDBC driver
• upgrade the JDK if you are on an old patch level
• check the database server or proxy TLS implementation
• reduce unnecessary connection churn so the pool does not constantly create and retire sockets

Connection Pools Matter

Spring Boot commonly uses HikariCP. In practice, many close-notify warnings appear during connection retirement rather than during active queries. Pool settings can reduce the frequency of that path.

For example, a reasonable keepalive helps prevent stale idle sockets from being rediscovered at an awkward moment:

1spring.datasource.hikari.minimumIdle=2
2spring.datasource.hikari.maximumPoolSize=10
3spring.datasource.hikari.keepaliveTime=300000
4spring.datasource.hikari.maxLifetime=1800000

This is not a cure for a misbehaving TLS peer, but it can make connection turnover more predictable and easier to diagnose.

What Not to Do

Do not "fix" this by disabling certificate validation or by downgrading to plaintext database traffic unless you have an isolated development environment and an explicit reason. That hides the symptom by removing security, not by correcting the protocol path.

Also avoid adding obscure JVM SSL properties unless you can explain what they change. JSSE has options related to close-notify behavior, but if the peer never sends the TLS shutdown alert, the durable fix is still on the server, proxy, or driver side.

Common Pitfalls

The most common mistake is blaming Spring Boot because the stack trace appears in Spring logs. Spring Boot usually just surfaces the JDBC exception; it does not implement the TLS protocol itself.

Another mistake is treating every appearance of this message as fatal. If the SQL work completed successfully, you may be looking at shutdown noise rather than a broken application path.

Teams also often debug only the application and forget the network boundary. Load balancers, proxies, database firewalls, and managed service endpoints can all terminate TLS in ways that trigger this warning.

Finally, do not ignore driver and JDK versions. TLS behavior and shutdown handling improve over time, so "update the driver and runtime first" is not hand-waving here. It is one of the highest-value checks.

Summary

• The exception means Java closed TLS inbound processing before the peer sent close_notify.
• In JDBC applications, the root cause is often the database peer, proxy, or driver interaction rather than Spring Boot itself.
• First determine whether the query failed or whether the warning appears only during connection shutdown.
• Configure TLS explicitly, capture JSSE debug logs, and check driver and JDK versions.
• Do not hide the issue by disabling SSL verification or downgrading security.