RDS "No pg_hba.conf Entry ... No Encryption": SSL Fixes

The RDS PostgreSQL error FATAL: no pg_hba.conf entry for host ..., user ..., database ..., no encryption usually means your client tried a non-TLS connection while the database requires encryption. Fix the client first: use sslmode=require to establish TLS, then use sslmode=verify-full with the Amazon RDS certificate bundle for production identity verification. The counterintuitive part is that you cannot repair the message by editing pg_hba.conf on standard Amazon RDS: AWS manages that file. The useful controls are client TLS settings and rds.force_ssl, not a manual server-side allow-list line.

Jake runs a phone shop, and the booking application writes repair orders to an RDS PostgreSQL database. His dashboard opens, but a new order fails when the database driver rejects a connection. The log mentions a file he has never seen: pg_hba.conf.

Jake: "The log mentions pg_hba.conf. I have never seen that file."

Ethan: "Does the message actually say no encryption? If it does, fix the connection security before you touch database permissions."

That one distinction can save you from opening database ports, changing passwords, or rebooting a healthy server. The sections below explain what the error means, how every named client enables TLS, and when an RDS parameter-group change is genuinely necessary.

Read the full pg_hba.conf rejection instead of just the first line

You may search for no pg_hba.conf entry for host no encryption after seeing a long FATAL message. Read the entire line, especially the host, user, database, and last phrase. PostgreSQL is reporting a server-side connection rejection, but those last words help identify whether encryption is the immediate obstacle.

For example, FATAL: no pg_hba.conf entry for host "203.0.113.10", user "appuser", database "orders", no encryption says a client made a connection attempt that did not meet an encryption requirement. The IP is the address the database sees; it might be a NAT address or host address rather than your personal laptop address.

If the message is instead about password authentication, a missing database, or a network timeout, the recommended route changes. Your goal is to match the error category rather than treat every PostgreSQL failure as a missing HBA rule.

Jake: "It says host. Does my public IP need to be added to a server file?"

Ethan: "For a self-hosted database, maybe. For RDS, the service owns that file. Your next move is the SSL option on the connection."

Understand why RDS generates a pg_hba.conf error

When you connect to PostgreSQL, the server decides whether the client can authenticate under its host-based rules. The traditional configuration file is called pg_hba.conf, which stands for PostgreSQL host-based authentication. It associates a connection type, database, user, and client address with an authentication method.

Amazon RDS for PostgreSQL manages the host-based configuration for its DB instances. You receive managed database capabilities rather than operating-system administrator access to the underlying database host. That is why searching for an SSH path to edit this file leads you away from the supported resolution.

The error is also different from an AWS security group refusing traffic. A network block often prevents the PostgreSQL server from responding at all. Seeing a PostgreSQL FATAL message means you reached a PostgreSQL endpoint capable of rejecting your session. You might still need network work elsewhere, but first deal with what the server actually reported.

RDS accepts encrypted PostgreSQL connections, and rds.force_ssl determines whether its policy requires them. Your client might use encrypted transport already, or it might fall back to plaintext depending on its driver defaults and configuration. The database password is not an encryption setting; successful credential validation cannot make a plaintext transport meet a TLS requirement.

Find the rds.force_ssl default for your PostgreSQL major version

If your error started immediately after a PostgreSQL major-version upgrade, the major version matters. RDS for PostgreSQL 15 and later default rds.force_ssl to 1, meaning new connections must use SSL/TLS. RDS PostgreSQL 14 and earlier default it to 0. A custom parameter group can override the default, so never infer the effective value from version alone.

Find your DB instance in RDS → Databases, open its Configuration tab, note the engine version and associated DB parameter group, then inspect rds.force_ssl in Parameter groups. A default parameter group cannot be edited directly. If you plan to change it, create a custom group compatible with the instance’s PostgreSQL major-version family.

aws rds describe-db-instances \
  --db-instance-identifier my-postgres \
  --region us-east-1 \
  --query "DBInstances[0].{EngineVersion:EngineVersion,Groups:DBParameterGroups,Endpoint:Endpoint.Address}"

aws rds describe-db-parameters \
  --db-parameter-group-name my-postgres-params \
  --region us-east-1 \
  --query "Parameters[?ParameterName=='rds.force_ssl']"

The first command identifies the attached parameter group; replace the illustrative group name in the second command with the one actually attached. For an Aurora PostgreSQL cluster, inspect the applicable DB cluster parameter group as well; its configuration path is different from a standard RDS instance.

Get the RDS root certificate bundle and preserve the endpoint hostname

Once you enable TLS, the next useful distinction is encryption versus server authentication. A connection with sslmode=require requests encryption, but strong production verification also checks that the server certificate chains to a trusted authority and matches the intended hostname. For that, use sslmode=verify-full and the appropriate RDS certificate bundle.

For commercial AWS Regions, Amazon provides global-bundle.pem. You can download it from the RDS trust-store host. Region-specific bundles also exist if you prefer to carry a narrower set of roots. These files are public trust certificates, not your database password or private key.

curl -fsSLo global-bundle.pem \
  https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

# Inspect the downloaded PEM file path before configuring clients
ls -l global-bundle.pem

On Windows, use a browser or an appropriate PowerShell download command, then save the PEM file in a durable path readable by the application or desktop client. The root certificates in your trust store are used to verify the DB certificate. Keep the bundle updated for RDS certificate authority rotation rather than embedding an outdated individual DB server certificate.

With verify-full, connect using the real RDS endpoint shown in the RDS console. If you replace that hostname with an arbitrary IP address or unsupported custom alias, hostname verification can fail even though the network path works. This is a useful signal: certificate verification is protecting you against connecting to the wrong server.

Jake: "Should I share the PEM bundle with everyone on the team?"

Ethan: "The root bundle is public. Your database credentials are not. Put the bundle where the application can read it and keep secrets in your secret manager."

Choose the correct sslmode instead of relying on implicit defaults

You may see sslmode in a psql command, a JDBC URL, a desktop GUI, or a Python connection string. The names are similar, but different libraries can have their own default behaviors and option mappings. Specify your intended behavior explicitly so a deployment does not silently change when you switch libraries.

A PostgreSQL libpq client typically defaults to prefer, which attempts TLS first. If TLS fails and the client retries plaintext, RDS may return the no encryption message. Seeing that error does not establish that you manually set disable; a fallback or connection-string override is another possible explanation.

A secure troubleshooting progression is simple: first prove you can connect with require, then configure the CA bundle and reach verify-full. Keep the final setting strong. If verify-full fails, investigate the bundle, endpoint name and client driver rather than disabling certificate checks indefinitely.

Fix psql connections with require and verify-full

If psql says no pg_hba.conf entry for host ... no encryption, provide an explicit SSL mode in the connection string. The following host is a placeholder; copy your actual database endpoint from the RDS console. Port 5432 is PostgreSQL’s conventional port, but use your instance’s configured value if it differs.

psql "host=mydb.abcdefghijk.us-east-1.rds.amazonaws.com port=5432 dbname=orders user=appuser sslmode=require"

When the connection succeeds, move to full certificate verification using the downloaded bundle. Supply a real absolute path if your current directory is not stable. The hostname in host= should match the certificate’s expected RDS endpoint identity.

psql "host=mydb.abcdefghijk.us-east-1.rds.amazonaws.com port=5432 dbname=orders user=appuser sslmode=verify-full sslrootcert=/secure/certs/global-bundle.pem"

For a fast session-local environment-variable alternative, use PGSSLMODE and PGSSLROOTCERT. Watch for shell-specific syntax: Bash and PowerShell set environment variables differently. A command-line password argument is unnecessary and can expose secrets in history or process listings.

export PGSSLMODE=verify-full
export PGSSLROOTCERT=/secure/certs/global-bundle.pem
psql -h mydb.abcdefghijk.us-east-1.rds.amazonaws.com -U appuser -d orders

After you connect, psql commonly prints an SSL connection banner. For a database-side check, query pg_stat_ssl for your own backend process. That tests the active connection rather than trusting the configuration you think the client used.

SELECT ssl, version, cipher
FROM pg_stat_ssl
WHERE pid = pg_backend_pid();

Fix pgAdmin when the server registration keeps returning the FATAL error

In pgAdmin, the server registration stores connection details, including transport security. If your previously saved entry used a permissive mode or an old certificate path, reconnecting can repeat the same rejection even though your psql command now works.

1. Open pgAdmin and find the saved server registration in the Browser pane.
2. Open its Properties or connection-editing dialog and inspect the Connection tab: hostname, port, maintenance database and user.
3. Open the SSL-related tab and choose an SSL mode that requires encryption.
4. For production, choose certificate and hostname verification and provide the RDS root certificate bundle path.
5. Save the updated entry, disconnect old sessions, and connect again.
6. If it fails, compare the precise pgAdmin error with a psql invocation using the same host, user, database and SSL mode.

The SSL-related controls can differ by pgAdmin version. The important fields are the equivalent of sslmode and root CA certificate. For verify-full, the RDS endpoint name is essential; a friendly label you assign to the pgAdmin server can be anything, but the actual Host name/address field should be the correct hostname.

Jake: "pgAdmin still shows the server in the sidebar, so the connection is fine?"

Ethan: "That entry is saved connection information, not proof of an active secure session. The test is whether it can open the database with those settings."

Fix DBeaver PostgreSQL SSL settings without changing the database

DBeaver uses a PostgreSQL driver with SSL options that can be configured through its connection editor. If your DBeaver connection says no encryption, use the PostgreSQL connection configuration rather than editing the RDS instance network rules.

Open the connection editor, review the main host, port, database and user fields, then find the SSL section or driver properties. Enable SSL, select a mode that requires TLS, and configure the root certificate bundle for full verification. The exact control labels vary by DBeaver version and driver configuration.

If you use driver properties directly, specify the SSL mode supported by the PostgreSQL JDBC driver. For a hardened JDBC setup you may use a certificate root path together with sslmode=verify-full. Restarting the GUI application is rarely the central fix; correct the saved driver connection properties first.

For teams with multiple saved connections, label the environment clearly and record the actual endpoint and Region. Mixing a development certificate path with a production hostname can create a verification error that looks unrelated to the original HBA rejection.

Fix Python psycopg and psycopg2 connection code

Your Python application may build its PostgreSQL connection from a URL, keyword arguments, environment variables or a framework settings object. The first task is to discover which source wins. A deployment may read an old DATABASE_URL even while your local test script supplies stronger SSL settings.

import os
import psycopg

conn = psycopg.connect(
    host=os.environ["PGHOST"],
    dbname=os.environ["PGDATABASE"],
    user=os.environ["PGUSER"],
    password=os.environ["PGPASSWORD"],
    sslmode="verify-full",
    sslrootcert="/secure/certs/global-bundle.pem",
)
with conn.cursor() as cur:
    cur.execute("SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid()")
    print(cur.fetchone())
conn.close()

For psycopg2, the corresponding connect call also supports libpq-style SSL options. Keep the certificate file available in the production deployment and ensure the runtime user can read it. In containers, mount or copy the trust bundle into a stable path during image creation.

Frameworks such as Django and SQLAlchemy can pass SSL arguments down to their PostgreSQL drivers. Check the effective database engine and driver before copying an example: not every Python driver accepts every parameter in the same object shape. The key is to make the real driver use verified TLS.

Keep complete DSNs out of production logs, because those URLs often carry usernames and passwords. Log a sanitized host, database name, effective SSL mode, and request identifier instead. That gives you enough context to troubleshoot the connection without leaving credentials in monitoring output.

Fix Node.js pg connection pools and connection strings

In a Node.js application using node-postgres (the pg package), configure the pool or client for TLS explicitly. If you use a connection string and a separate ssl object, inspect how the library combines those settings. It is easy to believe you supplied a CA bundle while a URL parameter changes the effective configuration.

const fs = require("node:fs");
const { Pool } = require("pg");

const pool = new Pool({
  host: process.env.PGHOST,
  port: 5432,
  database: process.env.PGDATABASE,
  user: process.env.PGUSER,
  password: process.env.PGPASSWORD,
  ssl: {
    ca: fs.readFileSync("/secure/certs/global-bundle.pem", "utf8"),
    rejectUnauthorized: true
  }
});

async function checkDatabase() {
  const result = await pool.query(
    "SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid()"
  );
  console.log(result.rows[0]);
}

This example expects the real RDS hostname in PGHOST, allowing the TLS stack to validate its identity. Treat a short-lived switch to TLS without certificate verification as a diagnostic only; leaving rejectUnauthorized: false in production removes an important protection.

If the connection works locally but not in your deployment, compare the Node.js version, pg version, environment variables, certificate file existence and container image contents. A Node.js pool can also retain old connections, so test with a new process after updating the deployed configuration.

Fix Java JDBC and Spring application database URLs

For Java applications using the PostgreSQL JDBC driver, you can request SSL using URL parameters. A basic isolation test is a JDBC URL containing sslmode=require. For production verification, provide the RDS CA bundle or a correctly configured trust material path and use verify-full.

jdbc:postgresql://mydb.abcdefghijk.us-east-1.rds.amazonaws.com:5432/orders?sslmode=require

# Preferred verified connection with a usable certificate path:
jdbc:postgresql://mydb.abcdefghijk.us-east-1.rds.amazonaws.com:5432/orders?sslmode=verify-full&sslrootcert=/secure/certs/global-bundle.pem

For Spring Boot, place the JDBC URL in spring.datasource.url or in the environment variable that controls that property. Keep username and password outside the public application configuration. JDBC parameter encoding can matter when you put URLs in shell variables, YAML files or deployment manifests.

If your Java runtime uses a custom trust store, keep its certificate rotation lifecycle coordinated with RDS. Failure to update certificate trust may produce a handshake or verification error, which is not the same error as a plaintext connection being rejected. Read the nested exception message rather than changing rds.force_ssl automatically.

Change an RDS parameter group only when you have a policy reason

If you are actually changing the server’s SSL enforcement policy, use a custom DB parameter group. RDS default groups are managed and cannot be edited. Create a group with the correct PostgreSQL major-version family, set rds.force_ssl, attach it to the instance, and plan the required reboot or parameter-application event.

AWS has described rds.force_ssl in parameter listings and operational guides with varying apply-type discussions. For a newly attached custom group, a DB instance reboot is the safe operational expectation before relying on its values. Inspect the instance’s parameter-group apply status instead of assuming an “immediate” association changed a running database’s TLS policy.

aws rds create-db-parameter-group \
  --db-parameter-group-name app-postgres15-secure \
  --db-parameter-group-family postgres15 \
  --description "Application PostgreSQL TLS settings"

aws rds modify-db-parameter-group \
  --db-parameter-group-name app-postgres15-secure \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot"

aws rds modify-db-instance \
  --db-instance-identifier my-postgres \
  --db-parameter-group-name app-postgres15-secure \
  --apply-immediately

The example uses the PostgreSQL 15 family as an illustration, not a universal setting. Substitute the family matching your engine major version. Always examine other parameters in the new group so you do not unexpectedly lose custom settings that were in the previous group.

A reboot interrupts connectivity, so select an appropriate maintenance window or coordinated change time. Take a backup or confirm an available automated recovery point, and test every application that uses the database. After the change, inspect the DB parameter group status and rerun a verified TLS connection.

Know when a reboot really matters and when it does not

If your immediate problem is a client connection attempting plaintext, updating the client usually needs no RDS reboot. Reconfigure the connection string, reload the application process or rebuild the connection pool as appropriate. That is the cheapest corrective action and avoids interrupting unrelated database sessions.

A new DB parameter group association may require a reboot before parameters become effective. The console shows whether a group is in sync or pending application. For AWS CLI inspection, retrieve the DBParameterGroups portion of describe-db-instances and inspect the apply status, along with relevant RDS events.

Jake: "Will a reboot clear the HBA error?"

Ethan: "Rebooting does not change a client that keeps asking for an unencrypted connection. Make the driver speak TLS first."

Once you have enabled server-side TLS enforcement, connect using verify-full and examine pg_stat_ssl. This confirms both the client requirement and the active session’s encryption state. If you are preparing a version upgrade, upgrade client compatibility before changing server defaults.

Check SSL on existing connections before changing production

A successful encrypted connection from your laptop does not prove that all application services use TLS. Your web server, background worker, administrative scripts, BI tools and scheduled jobs may each have different drivers or connection settings. Inventory those consumers before you enforce stronger policies on a busy database.

SELECT a.datname, a.usename, a.client_addr, s.ssl, s.version, s.cipher
FROM pg_stat_activity AS a
JOIN pg_stat_ssl AS s ON s.pid = a.pid
WHERE a.backend_type = 'client backend';

This query describes connections present at the time of the query. It cannot show clients that are disconnected or scheduled to connect only once per day. For the rollout, pair an active-session sample with application configuration review and a controlled connection test per service.

If you see ssl = false for a client on an instance that currently allows plaintext, record the application owner and fix its settings before enforcing TLS. Once all known clients use verified TLS, a force-SSL policy becomes much less disruptive.

Separate TLS failures from VPC, security group and DNS problems

A PostgreSQL FATAL response generally means you got far enough to talk to a database server. A TCP timeout or connection refusal is more likely to involve network reachability, endpoint choice or a listener problem. These distinctions help you avoid broad security-group changes when the client needs only an SSL configuration.

Verify that your application runs in a network path allowed to reach the RDS instance’s endpoint and port. For private RDS instances, a laptop may need a VPN, bastion connection or an appropriate secure network path. Being able to resolve the endpoint hostname does not guarantee that you can route to the instance.

For a connection failing at the TLS stage, try to preserve the exact endpoint name through proxies and tunnels when you configure verify-full. Tunneling or overriding the host field can alter hostname verification behavior. Document the actual host presented to the TLS layer rather than switching security checks off.

If a security group lacks the inbound rule your application needs, add the narrowest practical source and port instead of opening PostgreSQL to every IP address. Database access is a separate control from transport encryption; you normally need both a reachable path and valid encrypted authentication.

Investigate connection strings hidden in environment variables

One reason the error can survive a “successful fix” is that the application never reads the setting you changed. A deployed service might construct its connection string from DATABASE_URL, while your local code sample uses individual PGHOST and PGSSLMODE variables. The environment variable precedence is defined by your framework and deployment, not by your intention.

Check the effective configuration source without printing passwords. Verify the database endpoint, SSL mode, CA path, port and runtime environment. In Kubernetes, an old Secret or ConfigMap may be mounted into a pod until deployment restart. In a container image, a certificate file might not exist at the expected path even though it is present on your workstation.

If the application uses a pool, opening fresh connections after the change matters. An already running process can retain old pool configuration. Plan a controlled restart of the application service if its library reads the connection settings only during initialization.

Ethan: "Your code can be right and your deployed configuration can still be wrong. Find the connection settings the running program is actually using."

Diagnose certificate errors that appear after enforcing verify-full

Once you switch from require to verify-full, a new error may appear: the root certificate cannot be loaded, the chain is untrusted, or the hostname does not match. That is progress in the sense that the client now attempts stronger verification, but the failed handshake still deserves a real fix.

First inspect the certificate path. The runtime needs filesystem permission to read the PEM file, and the bundle must contain the relevant trusted RDS roots. Download the current bundle using the official trust-store endpoint rather than copying an obsolete certificate from an old blog post.

Next inspect the host string. Use the endpoint provided for the DB instance instead of a raw IP address when full hostname verification is expected. If your architecture uses RDS Proxy, treat its certificate trust requirements separately from a direct RDS instance connection.

Finally consider certificate rotation. A trust store that pins an old server certificate rather than trusting the current RDS root chain can fail when the server certificate changes. Verify trust-store content and rotate it through your deployment pipeline.

Handle password and database-name problems after TLS is working

After enabling TLS, you may move from an HBA/no-encryption error to password authentication failed. That does not mean encryption failed. It means the connection progressed far enough to perform authentication, and the username or credential needs attention.

Confirm the database user name, database name and selected AWS Region. Applications sometimes connect to a different instance after deployment because their environment name or secret identifier points to a staging database. Check the actual endpoint in the sanitized startup diagnostics.

If you rotate database credentials, update the secret or environment reference used by the application. Keep temporary passwords out of test scripts too. For IAM database authentication, use the authentication flow designed for that configuration rather than treating an authentication token as a permanent password.

A missing database name produces its own server error. Resist changing SSL mode again when the new error text has moved to another stage. Read the newest full message, and let it tell you which connection layer to investigate next.

Understand the Azure and self-hosted PostgreSQL differences

You may encounter the same general no pg_hba.conf entry wording outside Amazon RDS. PostgreSQL itself uses host-based authentication rules, so the message is not an AWS-specific invention. What differs is who controls those rules and how the provider enforces TLS.

For a self-hosted PostgreSQL server, an administrator can edit pg_hba.conf, add an appropriate hostssl rule, set authentication requirements, and reload the PostgreSQL configuration. That route can be valid there but is not available as a direct file edit on standard RDS.

On Azure Database for PostgreSQL, examine the managed service’s TLS requirements and connection settings rather than assuming you can edit pg_hba.conf. Firewall and network access are managed through Azure-specific controls. The fastest first test remains a PostgreSQL client configured to use the service’s required TLS mode.

Across providers, a message that explicitly says no encryption points you toward the TLS negotiation path. The provider-specific management interface determines whether server policy can be changed; the client should still be configured for encrypted, validated transport.

Run a safe incident triage for psql, GUI tools and services

When your order-processing system fails during a live business day, prioritize evidence and reversible fixes. A controlled diagnosis keeps you from turning an encryption-policy mismatch into downtime for every database consumer.

1. Copy the complete FATAL message, including the trailing no encryption or SSL off phrase.
2. Find the real RDS endpoint, Region and engine version in the RDS console.
3. Inspect the attached DB parameter group for the effective rds.force_ssl policy.
4. Try psql using sslmode=require from the same network where your application runs.
5. Download the RDS CA bundle and repeat with verify-full using the proper endpoint hostname.
6. Apply the same TLS settings to pgAdmin, DBeaver, or the application driver.
7. Confirm the active connection with pg_stat_ssl, then retest the original business operation.
8. If one client still fails, compare its effective environment, TLS options and certificate path with the working psql test.

This sequence starts with client-side corrections and postpones database changes unless you have evidence of a parameter-group problem. It also distinguishes a configuration success from a business success: a connection test proves transport, while placing a test order proves your application actually uses that corrected connection.

Jake: "I will use a repair-order ID as the end-to-end test."

Ethan: "Good. A green connection test is only half the job. Make sure the booking path you care about uses that connection, not an old pool on another service."

Work through an illustrative PostgreSQL upgrade failure

Imagine Jake’s team upgrades its database from RDS PostgreSQL 14 to PostgreSQL 15. The previous deployment had been using an old client configuration that did not require TLS. The new engine’s default rds.force_ssl=1 means that a nonencrypted attempt is rejected.

His booking service receives 120 orders during a shift. If 30 attempts encounter a broken database connection and each staff member spends two minutes handling an interrupted order manually, that is 60 minutes of staff time. These figures are a hypothetical business calculation, not AWS pricing or evidence from an actual customer.

Instead of lowering the server’s SSL enforcement, the team first runs psql with sslmode=require. It then configures verify-full with the current RDS bundle and updates the same settings in the application’s database pool. The team checks the live session in pg_stat_ssl before placing a representative test order.

Notice what the team did not need: manually edit pg_hba.conf, open port 5432 to the world, rotate every password, or increase instance size. None of those actions establishes an encrypted PostgreSQL session.

Make the fix durable before the next engine or certificate rotation

Once you have restored service, document the intended SSL mode for each database client and store the RDS root certificate bundle in the relevant deployment process. Explicit TLS configuration is easier to review than an implicit driver default, especially when teams use several programming languages.

Add a connection check that reports the effective SSL mode without exposing passwords. During application upgrades, test against the target PostgreSQL major version and the current certificate bundle. Include desktop administration tools in the same checklist as the production application.

Treat certificate trust as a maintained dependency. Your application may continue working for months and then fail after an RDS certificate event if it trusts a narrow, obsolete certificate. By trusting current RDS root authorities and testing rotation readiness, you reduce that risk.

If you enforce SSL through a parameter group, track that setting with infrastructure management and verify its application after engine upgrades. Keep rollback procedures appropriate to your change plan; moving backward to plaintext should not become your routine rollback strategy.

Know what support needs when none of the clients connect

If the same TLS connection fails from multiple clients after you have supplied an appropriate mode and RDS CA bundle, gather evidence before opening a support case. A precise failure description helps separate client library behavior, certificate trust and managed database settings.

Include the DB instance identifier, Region, PostgreSQL engine version, parameter-group name, observed rds.force_ssl value, the precise error text, and the time of the failure. Include sanitized connection parameters and the client/driver version, but never paste a password or private secret into a case.

Note whether the error occurs with require, verify-ca, or verify-full, and whether psql behaves differently from the application driver. This distinction is often more useful than a generic “database unavailable” report.

Support cannot make an insecure client satisfy a TLS-only policy without changing the client or the policy. Your application’s driver configuration and certificate deployment remain under your control, so preserve the reproducible test commands as part of the case.

Find the last-mile error when your secure connection still fails

You've updated the SSL mode, but the next deploy still reports the same message. Resist the temptation to change the database server policy again. First find out whether the process that failed actually loaded your new configuration. A desktop client may save a setting in the profile you edited, while a production worker might be using a different database URL, a different user, or a connection pool created before the change.

Check the real process environment through the deployment system you use, with secrets redacted. If the service is launched through a container orchestrator, inspect the active task or pod definition rather than only the latest source repository. If the function is serverless, inspect its configured environment variables and any secret references. The settings used by the running version matter more than the settings in your working tree.

Your next controlled test should happen from the same network and compute environment as the failing application. A successful psql connection on your laptop proves that a laptop client can reach the database; it does not prove that an application container has the right certificate file, egress path or environment variables. Install the test client only in a temporary diagnostic environment if you do not want it in your production image.

If you're connecting through an SSH tunnel or port forward, full hostname verification deserves special attention. The TLS library verifies the hostname it receives in its connection options, and a tunnel often makes the TCP destination look like localhost. Preserve the real RDS hostname as the TLS verification target while directing transport through the tunnel using client-specific features. When that separation is not supported, document the exception and choose an appropriate secure connection design rather than permanently turning verification off.

When a CA bundle is updated, restart only the processes that need to reload it, according to your application's operational model. Some clients read a certificate every time they create a new TLS session, while others initialize a pool or trust store once. A rollout that changes the mounted certificate without replacing application processes can therefore leave old behavior in service.

Another easily missed case is a connection string assembled from several layers. A deployment template may define PGSSLMODE=verify-full, but application code may also append sslmode=disable to a full URL. Or a library may parse a query option that takes precedence over a separate SSL object. Record the final effective nonsecret options immediately before connection initialization so you know which setting actually won.

For Windows administrators using pgAdmin or DBeaver, a path such as C:\certs\global-bundle.pem must refer to a file on the machine running that program. If pgAdmin runs in a remote server or container, the file needs to exist there, not merely on the administrator's laptop. Likewise, a certificate file inside a Docker image must be available to the user account running Node.js, Python, or Java.

If several services connect with different SSL modes, migrate them deliberately. Start with a report-only inventory: service name, deployed version, database endpoint, library, intended certificate bundle and whether the actual session reports SSL. Fix the lower-risk clients first and watch for certificate verification failures. After the final critical service has been updated, confirm server-side SSL enforcement and schedule any needed parameter-group work separately.

Look for one consistent observation across the attempts. If every application works with require but fails with verify-full, focus on certificate validation and hostname identity. If only one application still reports no encryption, focus on that driver's effective settings. If none of them reaches a PostgreSQL FATAL line, investigate DNS and network connectivity before changing transport configuration. Each result narrows the problem and prevents unnecessary changes.

Jake's team can run this comparison without exposing customer data: one test connection per service, a sanitized log of the TLS mode, and a query of the live SSL session.

Ethan: "The fix is not finished when the settings file looks right. It is finished when the running client opens the kind of connection the database requires."

Quick answers to the PostgreSQL no-encryption questions readers actually ask

If your exact search query is below, use the short answer as a pointer, then return to the client-specific section for the commands and settings you need.

What does no pg_hba.conf entry for host no encryption mean?

Your PostgreSQL connection attempted transport without TLS and was rejected under the server policy. On RDS, configure the client for TLS, then verify its certificate rather than trying to edit pg_hba.conf.

How do I fix pgAdmin no pg_hba.conf entry for host?

Edit the server connection, enable SSL, and choose a TLS mode such as require. For production, use verify-full and the current RDS root CA bundle. Match the host field to the RDS endpoint.

How do I fix psql no pg_hba.conf entry for host?

Connect using sslmode=require to isolate encryption, then use sslmode=verify-full with sslrootcert pointing to the downloaded RDS bundle. Verify the active connection using pg_stat_ssl.

Why does PostgreSQL say FATAL no pg_hba.conf entry for host?

The server rejected the connection under host-based authentication or transport rules. The final phrase and other errors distinguish TLS policy from different access or authentication problems.

What does SQLSTATE 28000 no pg_hba.conf entry for host mean?

SQLSTATE 28000 identifies an invalid authorization specification. Read the detailed server error to determine whether the rejected connection is unencrypted or fails another host authorization condition.

Why does RDS PostgreSQL 15 require SSL by default?

For RDS PostgreSQL version 15 and later, the default rds.force_ssl setting is 1. Earlier major versions through 14 default to 0, unless a custom parameter group changes the policy.

Can I edit pg_hba.conf on Amazon RDS PostgreSQL?

No. RDS manages the server configuration and does not provide direct editing of pg_hba.conf. Use supported parameter groups, secure network settings and client TLS configuration.

What sslmode should I use for Amazon RDS PostgreSQL?

Use verify-full with the RDS root certificate bundle and the actual RDS endpoint for production. Require can be a useful initial TLS-only connection test but does not provide equivalent identity verification.

Where can I download the RDS PostgreSQL CA certificate?

Use the RDS trust-store downloads, such as the commercial-Region global-bundle.pem hosted at truststore.pki.rds.amazonaws.com, or a region-specific bundle.

Why does DBeaver show no encryption when connecting to RDS?

Its effective PostgreSQL driver connection may not require TLS or may be configured incorrectly. Enable SSL and configure its SSL mode and trusted root certificate.

How do I add SSL to Python psycopg for Amazon RDS?

Pass sslmode=verify-full and sslrootcert=/path/global-bundle.pem to the psycopg connection, with the real RDS host. Ensure the deployed runtime can read the certificate file.

How do I fix no encryption in Node.js pg?

Configure a secure TLS ssl object with the RDS CA certificate and certificate verification enabled. Inspect database URLs or environment settings that may override the pool options.

How do I configure Spring Boot PostgreSQL JDBC SSL?

Set spring.datasource.url to a PostgreSQL JDBC URL with sslmode=verify-full and sslrootcert pointing to a trusted RDS bundle path, while keeping credentials securely configured.

Does changing rds.force_ssl require rebooting RDS?

If you attach a new custom DB parameter group, plan a reboot before relying on its values, and inspect parameter-group apply status. A client-only SSL configuration change does not require an RDS reboot.

Why does verify-full fail after sslmode=require works?

Verify-full checks the certificate trust chain and hostname. Fix the CA bundle path, trusted roots or hostname rather than disabling certificate verification.

Is the pg_hba.conf error the same on Azure and self-hosted PostgreSQL?

The PostgreSQL error language is similar, but management differs. Self-hosted administrators can edit pg_hba.conf; RDS and Azure managed services require supported provider controls and secure client settings.

Keep your encrypted database connections working

If you have been staring at no pg_hba.conf entry ... no encryption while your app cannot take orders, the fastest repair is usually on the client side. Get one verified psql connection working, then carry those exact TLS assumptions into the real driver or GUI configuration. If your environment has several services, finish by checking that each one uses the fixed connection settings.

Jake can get back to booking phone repairs when his app has a tested encrypted path to the database. If your case behaves differently, record the full error and connection method before making the next change; the next clue is usually specific enough to follow.

Revision note. Written October 9, 2026, with the PostgreSQL 15 force-SSL default and the RDS root bundle in hand. Better safe than sorry: the server is asking for encryption, and that is the right ask.