We may earn a referral fee at no additional cost to you when you shop through the links on this page.
Every time you log into phpMyAdmin over plain HTTP, your database root password crosses the network in cleartext, along with every query and every row you browse. This DevAnswers guide closes that hole properly: a free certificate, a forced redirect on Apache or Nginx, the difference between securing the interface and securing the database connection, and the hardening steps the phpMyAdmin project itself recommends.
Quick Answer: HTTPS for phpMyAdmin Is a Web-Server Job
There is no “enable HTTPS” switch inside phpMyAdmin, and that is by design: TLS terminates at Apache or Nginx, and phpMyAdmin simply rides the encrypted site. The project’s own security guidance is blunt: serve phpMyAdmin over HTTPS only, preferably with HSTS so browsers refuse protocol downgrades. On a typical Ubuntu VPS with a domain pointed at it, the whole job is:
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
Certbot obtains the certificate and offers to redirect all HTTP traffic to HTTPS; choose the redirect and https://devanswers.test/phpmyadmin (swap in your domain) is the only way in. On Nginx, the same flow uses python3-certbot-nginx and certbot --nginx. The sections below cover the manual redirect blocks for setups certbot does not auto-configure, and everything that comes after.
Why phpMyAdmin Must Never Run Over HTTP
phpMyAdmin is a database admin panel reachable from a browser, which makes it two things at once: extremely convenient, and one of the most scanned-for paths on the internet. Bots probe /phpmyadmin on every public IP around the clock. Serve it over HTTP and anyone positioned between you and the server (coffee-shop Wi-Fi, a compromised router, your ISP) can read your MySQL credentials and everything you touch in a session. HTTPS turns that channel into ciphertext, and it also unlocks phpMyAdmin’s cookie protections, which mark the session cookie secure; that interaction is exactly why half-configured setups hit the session-cookie error covered in the troubleshooting section.
Get a Free Certificate with Certbot
Certbot is the official Let’s Encrypt client, and it automates obtaining, installing, and renewing certificates. You want a domain name resolving to your server. Let’s Encrypt can now issue certificates for a bare IP address, but only as short-lived certs (valid about six days, so they must renew automatically) and validated over HTTP rather than DNS, which makes an ordinary domain certificate the simpler choice for phpMyAdmin. If the server only has an IP so far, a registrar such as Namecheap plus an A record fixes that in minutes. Install the certbot package with the plugin matching your web server, then run it:
sudo apt install certbot python3-certbot-apache
sudo certbot --apache
Or, on a LEMP stack:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx
Either plugin inspects your existing sites, provisions the certificate, and asks whether to redirect all HTTP traffic to HTTPS. Choose the redirect option: it edits the web-server config for you, and for standard single-site setups that is the entire job, renewals included. Our Let’s Encrypt on Nginx guide walks the whole flow in detail if you want it step by step.
Force HTTPS on Apache
If certbot did not add the redirect, or you manage the vhosts by hand, the Apache project’s own guidance is to use a Redirect directive in a dedicated port-80 VirtualHost rather than mod_rewrite:
<VirtualHost *:80>
ServerName devanswers.test
Redirect permanent / https://devanswers.test/
</VirtualHost>
Save and exit (press CTRL + X, press Y, then press ENTER)
Open your site’s existing config with sudo nano /etc/apache2/sites-available/devanswers.test.conf. If the file already contains a <VirtualHost *:80> block for your domain, put the Redirect permanent line inside that block rather than adding a second one; Apache serves the first matching port-80 vhost it finds, so an appended duplicate is silently ignored. If there is no port-80 vhost, add the whole block (with your domain) and save. If you created this as a brand-new file rather than editing an enabled site, activate it first with sudo a2ensite devanswers.test.conf; Apache ignores files in sites-available until they are enabled. Then validate and reload in one guarded line (the && means the reload only runs if the config test passes):
sudo apache2ctl configtest && sudo systemctl reload apache2
On Ubuntu and Debian, the packaged phpMyAdmin hangs off every site as the /phpmyadmin alias, so redirecting the site to HTTPS carries phpMyAdmin with it; nothing phpMyAdmin-specific to configure.
Force HTTPS on Nginx
The Nginx equivalent is a return 301 in the port-80 server block, which permanently redirects every request to its HTTPS twin. Open your site config with sudo nano /etc/nginx/sites-available/devanswers.test and shape the port-80 block like this:
server {
listen 80;
server_name devanswers.test;
return 301 https://devanswers.test$request_uri;
}
Save and exit (press CTRL + X, press Y, then press ENTER)
Then validate and reload, again guarded so a failed test stops the reload:
sudo nginx -t && sudo systemctl reload nginx
The $request_uri part preserves the path, so a bookmark to http://devanswers.test/phpmyadmin lands on the HTTPS version of the same page rather than the homepage.
Interface HTTPS vs Database-Connection SSL
One distinction saves a lot of confusion: everything above encrypts the browser-to-server leg. It says nothing about the second leg, phpMyAdmin to MySQL. When both run on the same box, that second leg never leaves localhost and needs no encryption. But when phpMyAdmin manages a remote database server, the phpMyAdmin docs recommend SSL for that connection too, configured in config.inc.php with the $cfg['Servers'][$i]['ssl'] family of options. Their documentation carries an important caveat: setting only the ssl flag encrypts the connection but does not authenticate it, so for real protection you also configure the ssl_ca, ssl_cert, and ssl_key options rather than stopping at the flag.
Hardening Beyond HTTPS
The phpMyAdmin installation docs include a short, sane hardening checklist. With HTTPS done, the highest-value items:
- Add HSTS so browsers refuse to downgrade to HTTP (certbot offers it; one header line otherwise).
- Serve phpMyAdmin on a non-standard path instead of
/phpmyadmin, which cuts the bot noise dramatically. - Restrict access by IP where your admin IPs are stable (Apache
Require ip, Nginxallow/deny). - Rate-limit brute force with fail2ban or a captcha on the login page.
- Prefer distribution packages and keep them updated; they integrate with your distro’s security updates.
Our companion guide to installing and securing phpMyAdmin on Apache implements several of these from scratch if you are building a fresh box.
Troubleshooting
- “Failed to set session cookie. Maybe you are using HTTP instead of HTTPS.” The classic symptom of this article’s subject: phpMyAdmin marks its session cookie secure, the browser is on plain HTTP (or a reverse proxy misreports the connection), so the cookie is never stored. Load the https:// URL; if you are already on HTTPS behind a proxy, see the next item. Full walkthrough: fixing the phpMyAdmin session cookie error.
- Behind a reverse proxy or port forward, phpMyAdmin misbehaves or redirects wrongly. Tell it its real public URL with
$cfg['PmaAbsoluteUri']inconfig.inc.php; the docs flag port-forwarding and complex reverse-proxy setups as exactly the case this directive exists for. Set it to the full external URL with a trailing slash. - Browser warns about the certificate. Certbot renews Let’s Encrypt certificates automatically, but a clock-skewed server (certificate validation depends on correct system time) or a firewalled renewal can leave an expired cert; run
sudo certbot renew --dry-runto test the renewal path. - Redirect loop after enabling the redirect behind Cloudflare. Set the Cloudflare SSL mode to Full (strict) so the origin connection is HTTPS too; the loop is Cloudflare talking HTTP to an origin that redirects to HTTPS.
Next Steps
phpMyAdmin now rides an encrypted, auto-renewing HTTPS setup with the project’s own hardening advice applied. The certificate renews itself; your only recurring job is keeping the package updated with the rest of the system (our Ubuntu update guide is that routine).
- If the login now greets you with an access-denied error instead, that is a MySQL-side issue: see fixing phpMyAdmin access denied for root.
- Building the stack fresh? Start from install and secure phpMyAdmin and this article becomes its TLS chapter.
Comments