How to fix P1011: Error opening a TLS connection in Prisma

PrismaINTERMEDIATEMEDIUMUpdated May 28, 2026· 205 views

Prisma fails to open a secure TLS/SSL connection to your database, usually from misconfigured connection-string SSL parameters, certificate validation failures, or incompatible SSL settings.

Quick fix

Fixes P1011

# Check your connection string
echo $DATABASE_URL
  1. Check your database connection string for SSL parameters
  2. For SQL Server: Add trustServerCertificate parameter
  3. For PostgreSQL: Configure sslmode correctly
  4. For MySQL: Use Prisma's MySQL SSL parameters
prisma — error
# Check your connection string
echo $DATABASE_URL
P1011: Error opening a TLS connection

What this error means

The P1011 error occurs when Prisma cannot successfully establish a TLS (Transport Layer Security) connection to your database. This is Prisma's way of indicating that the SSL/TLS handshake failed during the connection attempt. This error commonly appears when there's a mismatch between the TLS settings specified in your connection string and what the database server expects or supports. It can also occur when certificate validation fails, such as when using self-signed certificates without proper configuration, or when the database requires specific TLS versions or cipher suites that aren't compatible with your Prisma setup. The exact parameters involved depend on your database provider. For SQL Server, the error often relates to the `trustServerCertificate` and `encrypt` parameters. For PostgreSQL, it typically involves `sslmode` settings and certificate path configurations. For MySQL, Prisma uses `sslaccept`, `sslcert`, `sslca`, and `sslidentity`. The specific underlying cause varies by provider and your security requirements.

Typical symptoms

  • Connection to database fails with "P1011: Error opening a TLS connection" message
  • Prisma migrations or introspection commands fail immediately
  • Application cannot start due to database connection failure
  • Error message includes "TLS settings didn't allow the connection"
  • Works without SSL/TLS but fails when encryption is enabled
  • Connection succeeds with other database clients but fails with Prisma

Common causes

  1. Self-signed or untrusted SSL certificates without trustServerCertificate=true (SQL Server)
  2. Missing or incorrect sslmode parameter in PostgreSQL connection string
  3. Certificate file path not specified or pointing to wrong location
  4. Database server requires certificate validation but no certificate provided
  5. Using outdated or incompatible SSL/TLS protocol versions
  6. AWS RDS using newer certificate authorities not recognized by Prisma
  7. SSH tunnel configuration interfering with direct TLS connection
  8. Mismatch between Prisma CLI and generated client certificate requirements
  9. Firewall or proxy blocking TLS handshake packets

How to fix "P1011: Error opening a TLS connection"

1Check your database connection string for SSL parameters

First, examine your DATABASE_URL in your .env file or environment variables:

bash
# Check your connection string
echo $DATABASE_URL

Look for SSL/TLS related parameters. Note that Prisma uses provider-specific parameter names:
- PostgreSQL: sslmode, sslcert, sslrootcert
- SQL Server: encrypt, trustServerCertificate
- MySQL: sslaccept, sslca, sslcert, sslidentity, sslpassword

A common mistake with MySQL is reusing PostgreSQL-style names like sslmode or ssl-ca/ssl-cert — Prisma's MySQL connector does not recognize these and will ignore or reject them. The absence or misconfiguration of these parameters is often the root cause.

2For SQL Server: Add trustServerCertificate parameter

If you're using SQL Server with a self-signed certificate or in a development environment, add trustServerCertificate=true:

env
# .env
DATABASE_URL="sqlserver://localhost:1433;database=mydb;trustServerCertificate=true;encrypt=true"

For Azure SQL Database with properly signed certificates:

env
DATABASE_URL="sqlserver://myserver.database.windows.net:1433;database=mydb;trustServerCertificate=false;encrypt=true"

Note: Only use trustServerCertificate=true when you trust the server or are in development. In production with proper certificates, use false.

3For PostgreSQL: Configure sslmode correctly

PostgreSQL requires explicit SSL mode configuration. Update your connection string with the appropriate sslmode:

env
# .env - For databases that support SSL but don't require it
DATABASE_URL="postgresql://user:password@localhost:5432/mydb?sslmode=prefer"

# For databases that require SSL (like many cloud providers)
DATABASE_URL="postgresql://user:password@localhost:5432/mydb?sslmode=require"

# For databases requiring certificate verification
DATABASE_URL="postgresql://user:password@localhost:5432/mydb?sslmode=verify-ca&sslrootcert=./ca-certificate.crt"

Available sslmode values (from least to most secure):
- disable: No SSL
- prefer: Try SSL, fall back to non-SSL
- require: Require SSL but don't verify certificates
- verify-ca: Require SSL and verify CA
- verify-full: Require SSL and verify hostname

Prefer verify-full (or at least verify-ca) in production so the certificate chain and hostname are validated.

4For MySQL: Use Prisma's MySQL SSL parameters

Prisma's MySQL connector uses a different parameter set than PostgreSQL. To enable verified TLS, point sslca at your CA certificate and request a strict acceptance level:

env
# .env - Require a valid, CA-verified certificate (recommended)
DATABASE_URL="mysql://user:password@host:3306/mydb?sslaccept=strict&sslca=./ca-cert.pem"

For mutual TLS where the server requires a client certificate, also provide sslcert and the client key/identity:

env
DATABASE_URL="mysql://user:password@host:3306/mydb?sslaccept=strict&sslca=./ca-cert.pem&sslcert=./client-cert.pem&sslidentity=./client-identity.p12&sslpassword=changeit"

Key MySQL parameters:
- sslaccept: strict (verify the certificate, recommended) or accept_invalid_certs (no verification — see the security warning below)
- sslca: path to the trusted CA certificate
- sslcert: path to the client certificate (for mutual TLS)
- sslidentity / sslpassword: PKCS#12 client identity file and its password

There is no sslmode, ssl-ca, or ssl-cert for the Prisma MySQL connector — use the names above.

5Download and configure database certificates

For cloud database providers that require certificate verification, download the certificate bundle:

AWS RDS/Aurora:

bash
# Download RDS certificate bundle
curl -o rds-ca-bundle.pem https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

# Update connection string
DATABASE_URL="postgresql://user:password@mydb.xyz.rds.amazonaws.com:5432/dbname?sslmode=verify-full&sslrootcert=./rds-ca-bundle.pem"

Google Cloud SQL:

bash
# Download server-ca.pem from the Cloud SQL instance via the Console or:
#   gcloud sql ssl server-ca-certs list --instance=INSTANCE_NAME
# Then reference it in your connection string
DATABASE_URL="postgresql://user:password@host:5432/db?sslmode=verify-ca&sslrootcert=./server-ca.pem"

Use an absolute path (or one resolved relative to the process working directory) rather than a literal ~, which is not expanded inside connection-string parameters. Ensure the certificate file is accessible to your application at runtime.

6Test connection with Prisma CLI

After updating your connection string, test the connection:

bash
# Test database connection (read-only introspection)
npx prisma db pull

# Or run a migration to verify in a development database
npx prisma migrate dev --name test_connection

If the CLI command succeeds, your TLS configuration is correct. If you still see P1011, review the error details for specific TLS failure reasons. (db pull --force overwrites your schema.prisma, so omit --force unless you intend to regenerate it.)

7Upgrade Prisma to the latest version

Some P1011 errors have been resolved in newer Prisma versions. Check your version and upgrade if needed:

bash
# Check current version
npx prisma --version

# Update Prisma dependencies
npm install @prisma/client@latest prisma@latest

# Regenerate Prisma Client
npx prisma generate

After upgrading, test your connection again. Some certificate authority and TLS protocol compatibility issues have been fixed in recent releases.

Advanced notes

Development vs Production SSL Configuration

In development, you might be tempted to disable SSL verification entirely. While trustServerCertificate=true (SQL Server), sslmode=disable (PostgreSQL), or sslaccept=accept_invalid_certs (MySQL) will let you connect, never commit these settings to production configuration — they remove the protection TLS is meant to provide. Use environment-specific connection strings instead, and validate certificates in production.

SSH Tunnels and TLS

If you're connecting through an SSH tunnel, the TLS connection happens inside the tunnel. Some users report P1011 errors when Prisma attempts direct TLS while the tunnel already provides encryption. In these cases you may relax the in-tunnel SSL mode (for example PostgreSQL sslmode=prefer), but be aware this trades away end-to-end certificate validation between the tunnel endpoint and the database. Prefer keeping verification on where the database supports it.

Certificate Authority Updates

AWS RDS periodically updates certificate authorities. If you're using an older RDS CA certificate (like rds-ca-2019, which has been superseded) and AWS has rotated to newer CAs, you may encounter P1011 errors. Always use the latest certificate bundle from your provider.

Prisma CLI vs Generated Client

There's a known difference between how the Prisma CLI and the generated client handle certificates:
- Prisma CLI: Can use sslcert=/sslrootcert= parameters or rely on the OS trust store for the certificate.
- Generated client with adapters (like @prisma/adapter-pg): Must use the sslrootcert= parameter explicitly.

If you see different behavior between npx prisma migrate and your application runtime, check that both are using compatible SSL parameters.

Security Warning

Never use sslaccept=accept_invalid_certs (MySQL), trustServerCertificate=true (SQL Server), or sslmode=require/disable (PostgreSQL) as a permanent fix in production. These options skip certificate validation and leave the connection vulnerable to man-in-the-middle attacks. Use them only briefly in development to diagnose an issue, then switch to validated configuration (sslaccept=strict with sslca, trustServerCertificate=false, or sslmode=verify-full) with the correct CA certificate.

Frequently asked questions

What does "P1011" mean?
The P1011 error occurs when Prisma cannot successfully establish a TLS (Transport Layer Security) connection to your database. This is Prisma's way of indicating that the SSL/TLS handshake failed during the connection attempt. This error commonly appears when there's a mismatch between the TLS settings specified in your connection string and what the database server expects or supports.
How do I fix "P1011"?
Prisma fails to open a secure TLS/SSL connection to your database, usually from misconfigured connection-string SSL parameters, certificate validation failures, or incompatible SSL settings.
What causes "P1011"?
Self-signed or untrusted SSL certificates without trustServerCertificate=true (SQL Server) Missing or incorrect sslmode parameter in PostgreSQL connection string Certificate file path not specified or pointing to wrong location
Is the "P1011" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading