Intro#

Many managed database services, like the one from OVHcloud, offer TLS-secured connections to your database. But do you understand whether that actually makes you secure in your context, or whether you are still a good target for man-in-the-middle attacks? This article shares some insights from my own experience.

The issue#

sslmode=require: warnings and errors#

When you use, for example, OVHcloud, you can copy+paste the connection string from their UI and drop it into your application. The one from OVHcloud, again like many others, contains the parameter “sslmode=require”, but this is not enough to protect you against a man-in-the-middle attack. It only protects you from passive sniffing on your untrusted network. It is essential, but the job is still not done.

If you use that string in a stack that depends on node-postgres/pg ↗, it is likely you run into this warning:

In the next major version (pg-connection-string v3.0.0 and pg v9.0.0), these modes will adopt standard libpq semantics, which have weaker security guarantees.      

To prepare for this change:
- If you want the current behavior, explicitly use 'sslmode=verify-full'
- If you want libpq compatibility now, use 'uselibpqcompat=true&sslmode=require'

See https://www.postgresql.org/docs/current/libpq-ssl.html for libpq SSL mode definitions.

This warning was introduced by this commit:

and later released in

But the actual issue is the error that follows:

[14:48:23] ERROR: Error: cannot connect to Postgres. Details: self-signed certificate in certificate chain
    err: {
      "type": "Error",
      "message": "self-signed certificate in certificate chain",
      "stack":
          Error: self-signed certificate in certificate chain
              at C:\Users\somefolder\node_modules\pg-pool\index.js:45:11
              at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
              at async h (C:\Users\somefolder\.next\server\chunks\2624.js:308:5610)
              at async Object.i [as connect] (C:\Users\somefolder\.next\server\chunks\2624.js:308:5852)
              at async bG.init (C:\Users\somefolder\.next\server\chunks\2624.js:292:8722)
              at async bJ (C:\Users\somefolder\.next\server\chunks\2624.js:292:11911)
              at async r (C:\Users\somefolder\.next\server\chunks\9358.js:1:31438)
              at async generateRouteStaticParams (C:\Users\somefolder\node_modules\next\dist\build\static-paths\app.js:504:28)
              at async buildAppStaticPaths (C:\Users\somefolder\node_modules\next\dist\build\static-paths\app.js:579:25)
              at async C:\Users\somefolder\node_modules\next\dist\build\utils.js:685:79
      "code": "SELF_SIGNED_CERT_IN_CHAIN"
    }

Different meanings of sslmode=require#

And this has been known for 6 years:

It is the result of different definitions and implementations of how “require” should behave.

libpq ↗ defines that “require” means “I want my data to be encrypted, and I accept the overhead. I trust that the network will make sure I always connect to the server I want.”

But the implementation in “node-postgres” was different: require behaved more like verify-full. Therefore, it checks the certificate chain and without further adjustments, it fails for OVHcloud and others, as many of them use self-signed certificates. This behavior will change in the near future.

This PR will align node-postgres to libpq when it gets released:

How to deal with this now?#

A: quick option: disable CA validation via URI parameter#

If you use a node-postgres-based stack, you can add “&uselibpqcompat=true” to the URL and activate the libpq definition of “require”. So overall this becomes “?sslmode=require&uselibpqcompat=true”.

B: use “sslrootcert” parameter#

Both libpq and node-postgres support the “sslrootcert” parameter, so by using “?sslmode=verify-full&sslrootcert=ca.pem” you can enable full server verification. The caveat here is that, at least in the payload/node-postgres environment, this reloads the certificate every time the connection string is parsed. Personally, I think this is not a good solution, because repeatedly loading the same file is a waste of resources.

C: TLS/SSL settings by code#

I prefer using explicit configuration in my source code to define which CA should be trusted for which connection string, and how the validation should happen. It also prevents repeatedly loading the same file again and again.

    // if the config has a connectionString defined, parse IT into the config we use
    // this will override other default values with what is stored in connectionString
    if (config.connectionString) {
      config = Object.assign({}, config, parse(config.connectionString))
    }

So I removed them from the URI and set everything explicit in code:

db: postgresAdapter({
    schemaName: 'payload',
    pool: {
      connectionString: process.env.DATABASE_URL || '',
      ssl: {
        ca: fs.readFileSync(path.resolve(dirname, '../sekskant-ca.pem'), 'utf8'),
        rejectUnauthorized: true,
      },
    },
  }),

How is the CA organized at OVHcloud?#

Without understanding the signing process that is used, it is hard to trust it.

I could not find any detailed documentation explaining how OVHcloud creates certificates for database instances and what the CA architecture looks like. The only official statement I found is:

OVHcloud generates an SSL/TLS certificate for each DB instance. Once you establish an encrypted connection between your application and your database instance, your data flows will be encrypted. https://help.ovhcloud.com/csm/es-public-cloud-databases-faq?id=kb_article_view&sysparm_article=KB0048919 ↗

I did some experiments, and because of that I have good reason to believe that:

• There is one private shared CA, at least for PostgreSQL, used per cloud project.
• The first PostgreSQL instance creates the CA.

Here is the evidence:

The downloadable CA has the issuer ”… Project CA”. It was also the same certificate for two instances in the same cloud project, and a different certificate for a PostgreSQL instance I created in another cloud project. The validity period also matches the creation date of the first database. This structure makes sense, because instead of needing one CA certificate per server, you only need one per cloud project.

This is how you can inspect the downloaded certificate:

openssl x509 -in cert.ca -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            62:ac:f4:8d:6c:a1:ae:66:b6:72:9b:24:b0:b3:7e:9b:23:7a:9a:58
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: CN=1633a89e-39db-4e5e-b175-21ed1d815617 Project CA
        Validity
            Not Before: Apr  8 22:27:00 2026 GMT
            Not After : Apr  5 22:27:00 2036 GMT
        Subject: CN=1633a89e-39db-4e5e-b175-21ed1d815617 Project CA

If you want to inspect the TLS handshake with the server live, you can use: openssl s_client -starttls postgres -connect servername.database.cloud.ovh.net:20184 -showcerts

If you want to provide the downloaded CA certificate, use the “-CAfile .<filename>” parameter.

Wildcard in the TLS certificate#

In addition to the real database hostnames, I noticed the wildcard DNS:*.database.cloud.ovh.net in the server certificate. This means the certificate is not bound to one specific hostname, but is valid for all database hostnames at OVHcloud. When the CA would be a shared one for all OVHcloud customers, that could be an issue. But in this case, the setup appears acceptable, even though it is still less strict than a certificate issued only for the exact hostname.

Certificate handling of other providers#

All providers have more or less different approaches to CA handling.

• AWS RDS uses Amazon RDS CA certificates to sign DB server certificates and tells you to download the CA bundle for verification: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html ↗
• Azure Database for PostgreSQL currently documents chains anchored by public/trusted roots such as DigiCert Global Root G2 and Microsoft RSA Root CA 2017: https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/security-tls ↗
• Google Cloud SQL can use different CA hierarchies, including per-instance CA, shared CA, or customer-managed CA: https://cloud.google.com/sql/docs/postgres/manage-ssl-instance ↗
• Supabase tells you to download its CA certificate for verify-full: https://supabase.com/docs/guides/platform/ssl-enforcement ↗