A certificate was loaded. Java said nothing. The server just closed the door.

I was performance testing a REST API that required mutual TLS (mTLS) authentication. The setup looked correct — .pfx certificate loaded, passphrase configured, KeyManagerFactory wired up, simulation compiled cleanly.

Then I hit run. Every single request failed. No useful error message. Just:

j.i.IOException: Premature close

This is the story of what went wrong, why Java stayed silent about it, and exactly how to fix it.

First, What Is mTLS?

Before diving into the bug, it helps to understand the difference between standard TLS and mutual TLS.

In standard HTTPS (one-way TLS), only the server proves its identity. The browser or client receives the server's certificate, verifies it against trusted certificate authorities, and proceeds. The server never checks who the client is.

In mutual TLS (mTLS), both sides prove their identity to each other:

Client  ──── presents its certificate ────►  Server

Client  ◄─── presents its certificate ────  Server

           Both verify before proceeding

mTLS is common in internal microservice communication, financial APIs, B2B integrations, and anywhere the server needs cryptographic proof of which client is calling — not just that a valid TLS connection exists.

The Setup: Loading a PFX Certificate in Gatling

A .pfx (also called PKCS#12) file bundles a private key and certificate chain into a single password-protected file. To use it in Gatling, the standard approach is:

val sslContext: SSLContext = {
  val keyStore = KeyStore.getInstance("PKCS12")
  val pfxStream = getClass.getResourceAsStream("/certs/client.pfx")
  keyStore.load(pfxStream, "your-passphrase".toCharArray)

  val kmf = KeyManagerFactory.getInstance(
    KeyManagerFactory.getDefaultAlgorithm
  )
  kmf.init(keyStore, "your-passphrase".toCharArray)

  val ctx = SSLContext.getInstance("TLS")
  ctx.init(kmf.getKeyManagers, null, null)
  ctx
}

This compiled. The simulation ran. And every request returned:

j.i.IOException: Premature close

Diagnosing "Premature Close"

"Premature close" means the TCP connection was abruptly shut down by the remote end before a complete HTTP response was received. It is not a TLS error. It is not a certificate error. It is the aftermath of something going wrong at a lower level that Java never surfaced clearly.

To investigate, I enabled TLS debug logging:

-Djavax.net.debug=ssl:handshake

In the output, I could see:

1. Client Hello sent ✅

2. Server Hello received ✅

3. Server sent CertificateRequest ✅

4. Client sent empty certificate — no certificate at all ❌

5. Server closed the connection 🛑

Step 4 was the smoking gun. Java received the server's CertificateRequest and responded with nothing.

The Real Root Cause: Extended Key Usage

Every X.509 certificate contains an Extended Key Usages (EKU) extension. This field is an array that declares what the certificate is permitted to be used for. The two most relevant values are:

You can inspect a certificate's EKU with:

openssl pkcs12 -in cert.pfx -nokeys -passin pass:yourpassphrase | \\
  openssl x509 -noout -text | grep -A2 "Extended Key Usage"

When I ran this, the output was:

X509v3 Extended Key Usage:
    TLS Web Server Authentication

There it was. The certificate had serverAuth, not clientAuth.

Java's default `X509KeyManager` — the class responsible for choosing which certificate to send during a TLS handshake — filters candidates by their Extended Key Usage. When the server issues a CertificateRequest, Java evaluates every alias in the keystore and asks: "Is this certificate valid for client authentication?"

My certificate said: "I am a server certificate."

Java's response: silently skip it. Send nothing.

No warning. No exception. No log line saying, "no suitable certificate found." Just silence — and then a broken connection on the other end.

Why KeyManagerFactory Alone Isn't Enough

When you initialize a KeyManagerFactory and call getKeyManagers(), you get back a default X509KeyManager implementation. This implementation has a method called chooseClientAlias that is called during the TLS handshake to select which certificate alias to present.

Here is what the default implementation does internally:

1. Gets the list of acceptable CAs from the server's CertificateRequest

2. Iterates through every alias in the keystore

3. For each alias, checks if the certificate chain is signed by an acceptable CA

4. Checks the Extended Key Usage — filters out any cert without clientAuth

5. Returns the first matching alias, or null if none match

Step 4 is where everything failed. The certificate was loaded correctly. The passphrase was correct. The keystore had exactly one alias. But the EKU check returned null, Java sent an empty certificate message, and the server closed the connection.

The Fix: A Custom X509KeyManager

The correct long-term fix is to request a new certificate from your certificate authority with clientAuth in the Extended Key Usage. If you control the PKI, do that.

But in many real-world scenarios — third-party integrations, legacy systems, certificates issued by external organizations — you cannot simply request a new cert. You need to work with what you have.

The solution is to wrap the default X509KeyManager in a custom implementation that overrides chooseClientAlias to bypass the EKU check entirely:

import java.net.Socket
import java.security.Principal
import java.security.cert.X509Certificate
import javax.net.ssl.{X509KeyManager, KeyManagerFactory, SSLContext}

// Step 1: Define the alias of your certificate in the keystore
private val keyAlias = "cert.pfx certificate"

// Step 2: Create a custom KeyManager that forces the alias
class ForcedAliasKeyManager(
    delegate: X509KeyManager,
    alias: String
) extends X509KeyManager {

  // THE KEY OVERRIDE: When server asks for a client cert,
  // always return our alias — bypassing the EKU check
  override def chooseClientAlias(
      keyType: Array[String],
      issuers: Array[Principal],
      socket: Socket): String = alias

  // Delegate everything else to the default implementation
  override def getClientAliases(
      keyType: String,
      issuers: Array[Principal]): Array[String] =
    delegate.getClientAliases(keyType, issuers)

  override def getPrivateKey(alias: String) =
    delegate.getPrivateKey(alias)

  override def getCertificateChain(alias: String) =
    delegate.getCertificateChain(alias)

  // Server-side methods — not used in client context
  override def chooseServerAlias(
      keyType: String,
      issuers: Array[Principal],
      socket: Socket): String =
    delegate.chooseServerAlias(keyType, issuers, socket)

  override def getServerAliases(
      keyType: String,
      issuers: Array[Principal]): Array[String] =
    delegate.getServerAliases(keyType, issuers)
}

// Step 3: Wire it into the SSLContext
val sslContext: SSLContext = {
  val keyStore = KeyStore.getInstance("PKCS12")
  val pfxStream = getClass.getResourceAsStream("/certs/client.pfx")
  keyStore.load(pfxStream, "your-passphrase".toCharArray)

  val kmf = KeyManagerFactory.getInstance(
    KeyManagerFactory.getDefaultAlgorithm
  )
  kmf.init(keyStore, "your-passphrase".toCharArray)

  // Wrap the default key manager with our forced alias version
  val defaultKM = kmf.getKeyManagers.head.asInstanceOf[X509KeyManager]
  val forcedKM = new ForcedAliasKeyManager(defaultKM, keyAlias)

  val ctx = SSLContext.getInstance("TLS")
  ctx.init(Array(forcedKM), null, null)
  ctx
}

Why This Works

The chooseClientAlias method is the single decision point in the TLS handshake where Java selects which certificate to present. By overriding it to unconditionally return our alias, we short-circuit the entire EKU filtering logic.

Java no longer asks "is this certificate valid for client auth?" — it just uses the one we tell it to.

All other methods — getPrivateKey, getCertificateChain— are delegated to the original key manager, which handles them correctly using the keystore we loaded.

The complete TLS handshake now looks like:

Server → CertificateRequest

Java's default KeyManager:
  checks EKU → serverAuth → no clientAuth → returns null → sends empty cert

Our ForcedAliasKeyManager:
  ignores EKU → returns alias → sends certificate ✓

Server receives cert → verifies chain → handshake completes ✓
Requests succeed ✓

Finding the Alias Name

One detail worth noting: the alias name in the keystore matters. To find the exact alias of your certificate:

keytool -list -v -keystore cert.pfx -storetype PKCS12 -storepass yourpassphrase

Look for the Alias name field in the output. That string is what you pass to ForcedAliasKeyManager.

Summary

Key Takeaways

1. "Premature close" in mTLS is almost never what it looks like. The connection wasn't terminated randomly — the server closed it because Java sent no certificate.

2. Java's X509KeyManager fails silently. There is no exception or log when it finds no suitable certificate. Enable `-Djavax.net.debug=ssl:handshake` to see the actual handshake.

3. EKU is enforced by the client, not the server. The server asked for a certificate. Java refused to send one based on the EKU field. The server never even got to evaluate the certificate's validity.

4. A custom KeyManager is a legitimate escape hatch. When you cannot control certificate issuance, overriding `chooseClientAlias` is a clean, contained workaround with minimal surface area.

5. Always inspect your certificate before debugging the code. One `openssl` command would have found this in minutes.

If this helped you, follow me for more performance engineering and backend debugging deep-dives.