CONCEPT Cited by 1 source

Self-signed certificate anti-pattern (for managed services)¶

Definition¶

When a client cannot validate a managed-service endpoint's TLS certificate (because the client is missing a public-CA trust store), two tempting "fixes" circulate in forums:

Disable certificate verification in the client, so the TLS handshake skips chain validation entirely.
Issue a self-signed certificate on the client side, send the certificate + private key to the managed service, and ask it to use those instead.

Both are anti-patterns for any reasonable managed-service relationship (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field). The correct fix is almost always to bring the client's trust store up to date — see Root CA trust store and CA-bundled cert for tool trust.

Why "disable certificate verification" is wrong¶

Disabling verification means the client will complete the TLS handshake with any certificate the server (or a man-in-the-middle) presents. TLS's confidentiality guarantee (the traffic is encrypted end-to-end) is intact, but its authentication guarantee (you are actually talking to the server you think you're talking to) is gone.

PlanetScale Support's canonical framing:

Disabling certificate verification will make your connection susceptible to man-in-the-middle attacks. This is a cyberattack where an attacker secretly relays and possibly alters the communication between two parties. In order for your communication with our servers to be secure, you must not disable it! (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field)

The failure mode is: an attacker on the network path (compromised Wi-Fi, compromised middlebox, BGP hijack) presents their own certificate, the client accepts it because verification is disabled, the attacker relays to the real server, and the attacker now observes (and can edit) every query and credential in flight. Disabling verification is structurally equivalent to running plaintext.

Why "self-sign and send the private key to the service"¶

is wrong

Some users, misunderstanding how TLS works, generate their own CA + leaf certificate, and mail the whole bundle (including private key) to the managed service's support team, expecting the service to "install" it.

PlanetScale Support's canonical framing:

We also sometimes see users creating their own CA and SSL certificates and then sending us their certificates as well as the matching private key. You will never ever need to do that when using PlanetScale! It's an easy trap to fall into if you don't know enough about SSL/TLS and, from experience, it can get overwhelming and confusing quickly. (Source: sources/2026-04-21-planetscale-supports-notes-from-the-field)

The mental model is backwards on two counts:

The service is the CA-signed party, not the customer. The managed service already has a public CA-signed certificate (e.g. Let's Encrypt ISRG Root X1). The client verifies that chain; it has no role in picking which certificate the service uses.
Private keys never leave the party that owns them. A private key mailed to a support team is a compromised key by construction — anyone in the support team's inbox, mail relay, or file-storage chain can impersonate the customer. This is one of the most fundamental PKI hygiene violations.

The correct mental model¶

TLS to a managed service is one-way authentication by default: the service proves its identity to the client, the client does not prove its identity to the service (the client authenticates separately via username/password, token, etc.). If mutual TLS (mTLS) is in play, the service provides its CA metadata and the client generates its own key-pair; the private key still never leaves the client.

If the client cannot verify the service's certificate, the problem is always on the client side: missing trust store, stale trust store, legacy libssl, tool without public-CA bundle. The fix is to update the client's trust store (root CA trust store) or upload the service's CA root explicitly into the tool (CA-bundled cert for tool trust).

Adjacent failure modes¶

libssl too old — the version of OpenSSL the client links against doesn't support the server's cipher suite or certificate signature algorithm. Fix: upgrade libssl (or the distribution).
Library compiled without SSL support — some older Debian / Buster-era MySQL drivers were compiled without SSL support at all. Fix: use a newer driver or rebuild with SSL enabled.
Mixed trust-store paths — the driver looks at a different path than the one where the OS ships certificates. Fix: point the driver at the OS bundle explicitly via environment variable.

Why users fall into the trap¶

The anti-pattern persists because:

The UI of third-party tools (Retool, Looker Studio, generic DB clients) exposes a CA Cert / Client Key / Client Cert triple indiscriminately — the label doesn't make clear that CA Cert is for validating the server, not authenticating the client.
StackOverflow / forum answers that tell people to disable verification "temporarily" to make a demo work, without flagging the MITM exposure.
Legacy internal-to-an-org patterns (self-signed CA + mTLS everywhere within a cluster) leaking into managed-service contexts where the pattern does not apply.

Seen in¶

sources/2026-04-21-planetscale-supports-notes-from-the-field — canonical wiki disclosure with both anti-patterns named explicitly: "Disable SSL/TLS certificate verification" and "Issue and sign your own SSL certificate" in the "things you should NOT be doing" list. The MITM justification for why disabled verification is dangerous is provided verbatim; the private-key-leak framing for why self-signing
mailing is dangerous is implicit (the post frames it as "an easy trap to fall into if you don't know enough about SSL/TLS").