Safeguard
Security Guides•

PostgreSQL sslmode: require versus verify-full explained

sslmode require encrypts traffic but does not stop a man in the middle. Compare all six PostgreSQL sslmode values and pick the right one.

Safeguard Security Team
3 min read

sslmode=require encrypts a PostgreSQL connection but does not check who is on the other end, so it does not stop a man in the middle. verify-full encrypts, validates the server certificate chain and checks the host name. For anything sensitive, use verify-full, or verify-ca with a private CA.

The six modes

The libpq documentation lists these:

ModeProtects against eavesdroppingProtects against man in the middle
disableNoNo
allowMaybeNo
preferMaybeNo
requireYesNo
verify-caYesDepends on CA policy
verify-fullYesYes

The default is weak

The default is prefer. The manual says it "makes no sense from a security point of view" and is kept for backward compatibility. It encrypts if the server supports it and carries on unencrypted if not, so an attacker who strips encryption wins quietly. If your connection strings do not name a mode, you are probably running prefer.

Why require is not enough

require is described as: always encrypt, do not verify the server's identity. The assumption behind it is that the network ensures you reach the server you wanted. An attacker who can redirect the client, for example through DNS poisoning or address hijacking, can still impersonate the server and read everything.

There is a quirk. If a root CA file exists at the default client location, require behaves like verify-ca. The manual discourages relying on that and recommends setting verify-ca or verify-full explicitly.

Choosing

  • verify-full for most sensitive environments. It needs the server certificate's name to match the host you connect to.
  • verify-ca when your CA policy makes host names less meaningful, such as a private CA that only issues certificates to your own servers.
  • require only where you accept the risk and cannot yet distribute a CA certificate. Treat it as a stepping stone.

Server side

Connection modes on the client are half the job. On the server, hostssl lines in pg_hba.conf accept TCP only with SSL, and a hostnossl reject line closes the gap. See how pg_hba.conf matching works.

Rolling it out

  1. Find every client and connection string. Many apps leave the mode unset.
  2. Install the CA certificate where each client can read it.
  3. Move clients to verify-full one service at a time, watching for certificate name errors.
  4. Then tighten the server to refuse non-SSL TCP.

Quick check

Is the default sslmode safe?

No. The default is prefer, which the PostgreSQL manual says makes no sense from a security point of view and keeps only for backward compatibility.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.