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:
| Mode | Protects against eavesdropping | Protects against man in the middle |
|---|---|---|
| disable | No | No |
| allow | Maybe | No |
| prefer | Maybe | No |
| require | Yes | No |
| verify-ca | Yes | Depends on CA policy |
| verify-full | Yes | Yes |
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-fullfor most sensitive environments. It needs the server certificate's name to match the host you connect to.verify-cawhen your CA policy makes host names less meaningful, such as a private CA that only issues certificates to your own servers.requireonly 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
- Find every client and connection string. Many apps leave the mode unset.
- Install the CA certificate where each client can read it.
- Move clients to
verify-fullone service at a time, watching for certificate name errors. - 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.