TL;DR - The "SSL is used with disabled verification" message in phpMyAdmin means your connection is encrypted — data is scrambled in transit. What is turned off is identity verification, which checks the server's SSL certificate to confirm you are talking to the right host. - This is the default behavior in phpMyAdmin, MySQL Workbench, DBeaver, TablePlus, and nearly every other database tool. It is not a bug or a misconfiguration. - The reason: managed database providers (DigitalOcean, AWS RDS, PlanetScale, Azure) issue certificates with internal hostnames that often do not match the public hostname you connect through. Enforcing verification would break a large percentage of legitimate connections. - The practical risk is low. Exploiting disabled verification requires a man-in-the-middle position between two data center endpoints — not a realistic attack vector for most deployments. - If you need full verification (PCI-DSS, HIPAA, or you control both endpoints), set $cfg['Servers'][$i]['ssl_verify'] = true and provide the CA certificate. But understand that this will fail if the certificate's CN/SAN does not match your connection hostname. - DBEverywhere connects to your databases over SSL automatically. No certificate configuration required on your end.

Table of Contents

• "SSL Is Used with Disabled Verification" in phpMyAdmin — What It Means and Whether You Should Worry
• What SSL Verification Actually Means
• Where This Warning Comes From in phpMyAdmin
• Why Verification Is Disabled by Default
• SSL Off vs. SSL On (No Verify) vs. SSL On (With Verify)
• Is Disabled Verification a Real Security Risk?
• When You Should Enable Full Verification
• How to Enable SSL Verification in phpMyAdmin
• How Other Database Tools Handle This
• FAQ
• Conclusion

"SSL Is Used with Disabled Verification" in phpMyAdmin — What It Means and Whether You Should Worry

You open phpMyAdmin, connect to your database, and see the message: "SSL is used with disabled verification." It sounds alarming. SSL and "disabled" in the same sentence triggers the kind of concern that makes you close the tab and start searching for answers. If you have landed here because of the phpMyAdmin SSL verification disabled warning, the short answer is: your connection is encrypted and your data is protected in transit. But there is a nuance worth understanding, because SSL has two distinct jobs and only one of them is turned off.

This article explains what the warning means technically, why it exists, whether it poses a real risk, and how to enable full verification if your environment requires it.

What SSL Verification Actually Means

SSL (technically TLS — MySQL still uses the term SSL in its configuration, but the underlying protocol is TLS 1.2 or 1.3) does two separate things when establishing a connection:

1. Encryption. This is the part most people think of. Encryption scrambles all data traveling between the client (phpMyAdmin) and the server (your MySQL database) so that anyone intercepting the traffic sees ciphertext, not plaintext. When phpMyAdmin says "SSL is used," this part is on and working. Your queries, results, and credentials are encrypted with a cipher suite like TLS_AES_256_GCM_SHA384.

2. Identity verification. This is the part that is disabled. Verification checks the server's SSL certificate to confirm two things: (a) the certificate was signed by a trusted Certificate Authority, and (b) the hostname in the certificate matches the hostname you are connecting to. This is how HTTPS works in your browser — when you visit https://github.com, your browser checks that GitHub's certificate is signed by a recognized CA and that the certificate is issued to github.com. If either check fails, you get a warning.

When phpMyAdmin says "disabled verification," it means it is skipping step 2. It is encrypting the connection but not checking the server's certificate. The data is protected from eavesdropping, but phpMyAdmin is not cryptographically confirming the identity of the database server.

This distinction matters because the two properties protect against different threats. Encryption protects against passive eavesdropping — someone sniffing network traffic. Verification protects against active impersonation — someone inserting themselves between you and the real server (a man-in-the-middle attack). Disabled verification means the encryption is intact but the MITM protection is absent.

Where This Warning Comes From in phpMyAdmin

The message is generated by phpMyAdmin's connection handler when it detects a specific combination of configuration values. In config.inc.php, two settings control SSL behavior:

$cfg['Servers'][$i]['ssl'] = true;        // encryption ON
$cfg['Servers'][$i]['ssl_verify'] = false; // certificate verification OFF

When ssl is true and ssl_verify is false, phpMyAdmin establishes an encrypted connection but does not validate the server's certificate. It then surfaces the "SSL is used with disabled verification" message on the connection status page so you know what mode the connection is operating in.

This is phpMyAdmin being transparent, not flagging a critical vulnerability. The developers added this message specifically so that administrators could see their connection's security posture at a glance. The fact that it is visible is a feature — many other tools operate in the same mode silently.

If you see this message and did not explicitly configure SSL in config.inc.php, it likely means the hosting environment, Docker image, or managed service you are using has enabled SSL by default with verification disabled. This is the standard configuration for the official phpMyAdmin Docker image and most deployment guides.

Why Verification Is Disabled by Default

This is not an oversight. There is a concrete technical reason why virtually every database tool ships with certificate verification turned off, and it has to do with how managed database providers issue certificates.

Managed databases use internal hostnames in their certificates. When you create a MySQL database on DigitalOcean, AWS RDS, PlanetScale, or Azure Database for MySQL, the provider generates an SSL certificate for that instance. The Common Name (CN) or Subject Alternative Name (SAN) in that certificate typically contains an internal hostname — something like private-db-abc123.db.ondigitalocean.com or myinstance.abc123.us-east-1.rds.amazonaws.com.

You often connect through a different hostname. Depending on your network configuration, you might connect through a load balancer, a proxy, a private IP, a VPC peering endpoint, or a hostname that does not match what is in the certificate. For example, you might connect to 10.0.0.5 or db.mycompany.internal, but the certificate says private-db-abc123.db.ondigitalocean.com. The hostnames do not match.

Verification enforces hostname matching. When ssl_verify is true, the client checks that the hostname it connected to matches the CN or SAN in the certificate. If the names do not match, the connection is refused — even though it is the correct server, the correct database, and the encryption is working fine. The connection fails with a certificate error.

If verification were enforced by default, a large percentage of managed database connections would break. According to Percona's 2024 State of Open Source Databases survey, over 73% of cloud MySQL instances use encrypted connections. A significant portion of those connect through intermediary hostnames or IP addresses that would not pass certificate hostname verification. Enforcing verification by default would generate a wave of "cannot connect to database" errors for users who have done nothing wrong.

This is why phpMyAdmin, MySQL Workbench, DBeaver, TablePlus, DataGrip, and Adminer all default to the same behavior: SSL on, verification off. It is the pragmatic choice that provides encryption without breaking connectivity.

SSL Off vs. SSL On (No Verify) vs. SSL On (With Verify)

Here is what each configuration protects against:

The middle column — SSL on with verification off — is where most database connections operate today. It is a meaningful upgrade over no SSL: all data is encrypted, credentials cannot be captured by passive network sniffing, and the connection uses modern cipher suites (TLS 1.2 or 1.3 with AES-256-GCM on MySQL 8.0+).

The gap between the middle and right columns is specifically the MITM protection. To exploit that gap, an attacker would need to be positioned on the network path between your client and the database server, intercepting and re-encrypting traffic in real time. That is a significantly harder attack than passive sniffing.

Is Disabled Verification a Real Security Risk?

The honest answer: it is a theoretical risk that is very low in practice for most database deployments.

What the attack looks like. Exploiting disabled certificate verification requires a man-in-the-middle (MITM) attack. The attacker positions themselves between phpMyAdmin and the MySQL server, intercepts the TLS handshake, presents their own certificate, and establishes a separate encrypted connection to the real database. Because verification is off, phpMyAdmin accepts the attacker's certificate without checking who issued it.

Why it is difficult in practice. This requires the attacker to be on the network path between the two endpoints. In a typical deployment, both phpMyAdmin and the database are in the same data center or connected over a VPC. The network path is controlled infrastructure — not a coffee shop Wi-Fi network. Inserting a MITM requires physical access to networking equipment or a compromised router. According to Verizon's 2024 Data Breach Investigations Report, network-level MITM attacks account for less than 1% of confirmed data breaches, while credential theft and application-layer attacks dominate.

What this is NOT. Disabled verification is not the same as disabled encryption. Your connection is still encrypted with TLS. An attacker passively sniffing network traffic between your server and the database cannot read the data. The "SSL is used" part of the message is the important part — the connection is not plaintext.

Context from the MySQL documentation. The MySQL reference manual on encrypted connections documents that MySQL clients default to --ssl-mode=PREFERRED, which enables encryption when available but does not verify the server's certificate. This is the MySQL project's own default. The VERIFY_CA and VERIFY_IDENTITY modes exist for stricter environments, but they are opt-in.

For the majority of database connections — developer tools connecting to managed databases, internal services connecting within a VPC, staging and production environments in cloud infrastructure — the practical risk of a MITM attack exploiting disabled verification is very low.

When You Should Enable Full Verification

Despite the low practical risk for most deployments, there are situations where full certificate verification is appropriate or required:

Compliance mandates. PCI-DSS Requirement 4.1 mandates strong cryptography for cardholder data in transit and specifically calls out certificate validation. If your database holds payment card data, auditors may require ssl_verify = true. Similarly, HIPAA's Technical Safeguard 164.312(e)(1) and SOC 2 Type II audits may flag connections without full verification.

Connections over untrusted networks. If your phpMyAdmin instance connects to the database over the public internet rather than a private network or VPC, the network path is less controlled. This increases the (still low) MITM risk enough that verification becomes a reasonable precaution.

You control both endpoints. If you manage the MySQL server yourself (not a managed provider), you control the certificates. You can ensure the CN/SAN in the certificate matches the hostname you connect to. In this case, there is no hostname mismatch problem and no reason not to enable verification.

Zero-trust environments. If your security model assumes that the internal network is compromised (a principle increasingly adopted after incidents like the SolarWinds supply chain attack), then you want every connection authenticated at the transport layer. Full TLS verification is part of that posture.

How to Enable SSL Verification in phpMyAdmin

If your environment supports it, enabling verification requires two changes in config.inc.php:

$cfg['Servers'][$i]['ssl'] = true;
$cfg['Servers'][$i]['ssl_verify'] = true;
$cfg['Servers'][$i]['ssl_ca'] = '/path/to/ca-certificate.crt';

The ssl_ca parameter must point to the Certificate Authority certificate that signed your MySQL server's SSL certificate. For managed providers:

• DigitalOcean: Download the CA certificate from the database cluster's control panel under "Connection Details."
• AWS RDS: Download the combined CA bundle from AWS's trust store.
• Google Cloud SQL: Export the server CA from the Cloud Console or use the Cloud SQL Auth Proxy which handles verification automatically.
• PlanetScale: Uses publicly trusted CAs — the system CA bundle on most Linux distributions will work.

Before enabling, verify that the certificate's CN or SAN matches the hostname in your phpMyAdmin configuration. You can check this with OpenSSL:

openssl s_client -connect your-db-host:3306 -starttls mysql 2>/dev/null | \
  openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

If the output shows a hostname that differs from what you use in $cfg['Servers'][$i]['host'], verification will fail with a certificate error. You would need to either update the host to match the certificate's SAN, or keep verification disabled.

This is the core tradeoff: full verification is stronger security, but it requires alignment between the certificate's identity and your connection configuration. For managed databases where you do not control the certificate, that alignment is not always achievable.

How Other Database Tools Handle This

phpMyAdmin is not an outlier. The same default behavior — encrypt the connection but skip certificate verification — is standard across the database tool ecosystem:

• MySQL Workbench defaults to Use SSL: If Available which does not verify the server certificate. The Require and Verify CA option exists but must be explicitly selected and configured with a CA path.
• DBeaver connects with SSL when the server supports it but does not verify certificates by default. The "Verify server certificate" checkbox in the SSL tab is unchecked by default.
• TablePlus uses SSL by default for remote connections without certificate verification. Full verification requires manually providing a CA cert in the connection settings.
• DataGrip (JetBrains) uses the JDBC MySQL driver which defaults to sslMode=PREFERRED — encryption on, verification off.
• Adminer does not verify SSL certificates by default when connecting to MySQL with SSL enabled.
• MySQL CLI defaults to --ssl-mode=PREFERRED since MySQL 5.7.11, which encrypts without verifying.

The phpMyAdmin documentation on SSL configuration explicitly documents this behavior and the rationale. The MySQL project's own documentation on ssl-mode describes the hierarchy from DISABLED through PREFERRED to VERIFY_IDENTITY, making it clear that verification is an opt-in escalation.

FAQ

Does "SSL is used with disabled verification" mean my connection is not encrypted?

No. The connection is encrypted. The "SSL is used" part confirms that TLS is active and all data traveling between phpMyAdmin and your MySQL server is encrypted with a modern cipher suite. What is disabled is the certificate verification step — phpMyAdmin is not checking whether the server's certificate was issued by a trusted CA or whether the hostname matches. Your data is still protected from anyone sniffing network traffic.

Can someone intercept my database credentials with verification disabled?

Not through passive network sniffing — the TLS encryption prevents that. The only scenario where credentials could be intercepted is an active man-in-the-middle attack, where an attacker is positioned on the network path and intercepts the TLS handshake. This requires access to the network infrastructure between your server and the database, which is a high-difficulty attack in data center and cloud environments.

Should I switch to ssl_verify = true for my production phpMyAdmin instance?

It depends on your setup. If you connect to a managed database (DigitalOcean, AWS RDS, etc.) and you have the CA certificate available, and the certificate's hostname matches your connection hostname, then yes — enabling verification adds MITM protection with no downside. If the hostnames do not match (common with managed databases accessed through proxies or private IPs), enabling verification will break the connection. Test in a non-production environment first.

Is this warning specific to phpMyAdmin or does it affect all MySQL clients?

It affects all MySQL clients. The MySQL protocol's default SSL mode (PREFERRED) does exactly the same thing — encrypt without verifying. phpMyAdmin surfaces the warning explicitly, which is actually better transparency than most tools provide. MySQL Workbench, DBeaver, and the MySQL CLI all operate in the same mode by default without displaying a message about it.

How is this different from the browser "Not Secure" warning on HTTP sites?

The browser's "Not Secure" warning on HTTP sites means there is no encryption at all — traffic is plaintext. The phpMyAdmin message means encryption is active but the server's identity was not verified via its certificate. These are fundamentally different security postures. An HTTP connection is vulnerable to passive eavesdropping by anyone on the network. A TLS connection without verification is only vulnerable to an active MITM attacker who can intercept and re-encrypt traffic in real time — a much harder and rarer attack.

Conclusion

The "SSL is used with disabled verification" warning in phpMyAdmin tells you two things: your connection is encrypted, and the server's certificate was not checked. For the vast majority of database connections — particularly to managed providers like DigitalOcean, AWS RDS, and PlanetScale — this is the expected and practical configuration. It is the same default that MySQL Workbench, DBeaver, TablePlus, the MySQL CLI, and Adminer all use.

The phpMyAdmin SSL verification disabled setting is not a vulnerability. It is a pragmatic default that keeps connections encrypted without breaking connectivity to the millions of managed databases whose certificates do not match the hostname clients use to reach them. The alternative — enforcing verification universally — would generate connection failures for a significant share of legitimate database connections while protecting against a narrow attack vector that requires data center-level network access.

If your compliance requirements or threat model call for full certificate verification, enable it: set ssl_verify = true, provide the CA certificate, and confirm the hostname matches. The steps are straightforward if your certificate infrastructure supports it.

If you want encrypted database access without managing phpMyAdmin configuration, SSL certificates, or server infrastructure, DBEverywhere connects to your databases over TLS automatically. You access phpMyAdmin or Adminer in your browser, and the connection between the service and your database is always encrypted. Free tier includes 5 sessions per month; the paid tier ($5/mo) adds unlimited sessions, saved connections, and SSH tunnel support for databases on private networks.

Try DBEverywhere free ->