WordPress installation via script, management via WP Workbench fails with RDS SSL Connection (Error 1045)

Virtualmin
1

| SYSTEM INFORMATION

OS type and version: Ubuntu 22.04.5 LTS
Webmin version: 2.303
Virtualmin version: 7.30.8 Pro
Webserver version: Apache/2.4.52 (Ubuntu)
Related packages: WebApps-> Wordpress + WP Workbench

Hi everyone,

I’m running into an issue deploying a WordPress site with an Amazon RDS database that has SSL enforced. I’ve already configured RDS with SSL in Virtualmin Pro, and a manual connection works fine when I add the necessary SSL parameters in my wp-config.php (i.e., define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL)). However, when I use WP Workbench to deploy WordPress, I hit a snag:

Partial installation error
wp config create failed : Error: Database connection error (1045) Access denied for user ‘domain’@‘ipaddress’ (using password: YES)

To clarify:

  • Manual Configuration: By manually editing wp-config.php to include the required SSL flag (and adding any other SSL-related parameters like certificate paths if necessary), and the parameters for the external RDS endpoint, my site (and virtualmin) connects to RDS without issues.
  • WP Workbench Issue: WP Workbench, which relies on running wp config create to generate the configuration, seems to “forget” about the SSL connection details. The connection test fails with error 1045—even though the same credentials work fine when I hard-code the parameters in the config.

I suspect that the WP Workbench (or the underlying WP-CLI commands) isn’t including MYSQLI_CLIENT_SSL (or the SSL certificate parameters) automatically in the configuration it generates. I haven’t found any mention of this in the docs (or at least I haven’t looked hard enough), and I’m wondering if this is a known issue or if there’s a recommended workaround.

Has anyone encountered this mismatch between manual config and WP Workbench when using an RDS instance with SSL enforced?

Any insights on one or more of the following would be very helpful:

  • A method to have WP Workbench (or wp-cli) include the necessary SSL parameters automatically during the configuration creation.
  • A recommended workflow or patch—perhaps running a manual config creation step before WP Workbench continues.
  • Confirmation if this is a known issue with Virtualmin Pro’s ‘Web Apps’ handling of WordPress installations under these conditions.

I appreciate any help or pointers in resolving this issue.

Thanks in advance,

– keijo

2

That’s definitely unexpected, since WP Workbench just uses WP-CLI, which in turn relies on the WordPress configuration itself.

Have you checked the database logs? If the connection is being denied, there should be something logged with more details.

Also, if you log in as the domain user and run ./wp-cli.phar db check or bin/wp db check, does that work—if not—what error does it return?

3

Hi Ilia, thank you so much for picking the glove here.

‘vdomain’ is the domain admin for that specific domain.
‘internalip’ is the non-elastic IP within the AWS network that is allowed to connect to the RDS.

vdomain@server:~/public_html$ ./wp-cli.phar db check 

mysqlcheck: Got error: 1045: Access denied for user 'vdomain'@'internalip' (using password: YES) when trying to connect

Of note: ‘vdomain’ user, password, the RDS endpoint and database were manually set in the ‘wp-config.php’, since I had to manually edit (rename wp-config-sample.php to wp-config.php and manually add all of the above, plus the SSL define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL) directive after the DB options) when the wordpress install script failed to make them, so the recommended manual steps worked fine and I got to the site’s dashboard.

Funny thing is, for Virtualmin to reach here I had to also install the MariaDB package, or else it wouldn’t let the install scripts ‘see’ the configured RDS in Webmin (the post-setup wizard also changed the existing ‘root’ password, which made me thing of a smooth setup).

The server itself is under a 1:1 NAT to its ‘public’ IP. I can access the server’s virtualmin interface, and got to successfully complete the manual install ‘wizard’ using the domain name, but still WP Workbench doesn’t ‘see’ it complete and running fine.

These are crucial to me, since I’m planning to migrate 10 wordpress domains into it, and even convinced my Boss that this was the right approach, so, heh, I needz this :slight_smile:
K.-

(edits: formatting)

4

What!? That can’t be. There’s no way Virtualmin installed successfully without Mariadb also being installed.

5

Hi Joe and all,

To give some context on my journey so far…

My goal was (still is) to deploy Virtualmin Pro on an Ubuntu 22.04 EC2 instance (without an elastic IP, behind a commercial NAT/firewall) as a lean web server dedicated to hosting WordPress “parked” domains (for our core chatbot app). I only needed the jailing web/PHP/WordPress environment and the one-click WP Workbench updates—not full DNS, mail, and local database services.

Following company policy, I have an Amazon MariaDB RDS endpoint in place and thus chose not to use a local database on the initial Virtualmin Post-Install wizard. The wizard accepted “none” for local databases, and Webmin even confirmed connectivity to the external Amazon RDS over SSL (after some compliance hardening).

However, when creating the test domain, the WordPress install script complained that it couldn’t connect to any database and did nothing. Despite Webmin successfully connecting to the RDS and even pulling its schema. I wondered if it might be expecting a locally-installed engine.

So I tried a workaround:

  1. Installed MariaDB locally using apt install mariadb.
  2. Re-ran the Post-Install wizard—this time letting Virtualmin set up a database and change the root password. It ended up changing the Amazon RDS root password, but that was more than fine.
  3. The Virtualmin test domain then got a proper database (vdomain) and it was read perfectly.

Now, when I attempted another run of the WordPress install script, it made progress but eventually threw an error:

Partial installation error  
`wp config create` failed : Error: Database connection error (1045) 
Access denied for user 'vdomainadmin'@'localipaddress' (using password: YES)
Installation can be continued manually at https://example.com/

I then manually edited wp-config-sample.php (renaming it to wp-config.php) to include the correct database credentials and the required SSL directives. With these manual tweaks, I finished the manual WordPress install and I can access the WordPress dashboard without issues—even though WP Workbench still shows the same error message. (for reference, the WordPress install script first installed version 6.7.1 and then the dashboard upgraded to 6.8.2.)

So, it appears that Virtualmin won’t fully “see” the external RDS unless a local MariaDB package is installed, even though Webmin can otherwise connect just fine via SSL. This divergence between the automated configuration (using WP-CLI via WP Workbench) and the manual steps remains a point of curiosity.

Any insights on why Virtualmin might be requiring a local DB package to properly pass along the complete SSL parameters or reconcile the credentials between WP Workbench and the external RDS would be invaluable. I’m curious if anyone else has configured a similar setup and found a workaround. But above all, how can I let WP Workbench ‘know’ the DB resides in Amazon RDS and it’s all OK?

Thanks for your time, patience and expertise!
K.-

6

Can you elaborate on this particular step?

7

My current server hosting the Wordpress sites is a multisite (Wordpress Network) setup with around 10 sites. My aim with Virtualmin is to simply host those sites each in its own virtual domain, jailed from each other, and ditch Multisite while WP Workbench provides for plugin updates. I don’t need the extra features provided by Virtualmin, but the Pro license is really handy because of WP Workbench, as far as I can tell (I own my own Virtualmin Pro server as well, for my blogs and sites).

So far, in the ‘Company’ Virtualmin I made a single domain and installed Wordpress (manually, after the script complained it needed me to continue manually at the 1045), this still persists, regardless of the site being installed OK and WP Workench seeing all the plugins, and all.

So, that’s what I’d like to see where it can be resolved so it doesn’t show.

K.-

8

By jailed do you mean using “Manage Virtual Server ⇾ Edit Owner Limits ⇾ Enable Jailkit for domain” feature?

By the way, the upcoming WP Workbench with new Manager support will let you manage multiple WordPress instances across one or more systems.

9

I wasn’t thinking on that, precisely, since nobody but me and the team have management on these domains; some customers didn’t even want to bother back then, they just wanted a frontend up and running, so we gave them ‘placeholder’ sites with our chatbot embedded in, inside a “Multisite”. That’s what we’re migrating, now.

When I said ‘jailed’ I meant “virtual sites each in its own sandbox” and not actually referring to that Virtualmin feature, so Jailkit may come in really handy, but later. All my focus is on WP Workbench, which has proven its worth so far with our first migrated site (we’re also using WP Migrate DB Pro) from WP Network/Multisite. After sorting some obstacles with outdated plugins/php sorcery we could make it work in its own Virtualmin domain.

Request remains, how can I solve the part which WP Workbench still complains about the 1045 error and unfinished install? Is it a leftover? Because other than that, I’ve managed plugins, themes, and a lot other things from the WP Workbench sections and find it “most excellent” (plays air guitar).

Thanks!
K.-

10

I looked into it further, and there’s definitely a bug in the Virtualmin WordPress installer when remote database is used. Apply this patch and try the installation again:

webmin patch https://github.com/virtualmin/virtualmin-gpl/commit/8f87808

By the way, you don’t need any custom SSL-related configurations in WordPress config.

Also, add the remote database on the “System Settings ⇾ Database Servers” page and verify that your virtual server is actually using the remote database on the “Edit Databases → MariaDB Server Host” page. Also, check that “Edit Databases → Remote Hosts” includes your system’s hostname. Otherwise, the remote database server user won’t have enough rights to accept the connection.

11

I will unroll this patch, because after looking into it further, it doesn’t address the real issue, which is the database server’s reverse lookup of your system. You need to make sure any hostname allowed for the database user can be reverse resolved to your actual system.

I missed that too—you shouldn’t use the IP address; you should use the proper system hostname!

12

I will stay still until you tell me to jump, again, and ask what direction if instructions unclear. I didn’t do that webmin patch since yesterday has been Thursday Mayhem in preparation to Read-Only Friday, so we’re still paused here.

The @'ip-address' is automatically completed by the SQL server when seeing where the user is connecting from and we have internal routing of non-RFC1918 addresses.

The webmin part for the RDS is working without issues, the Wordpress installation writes to the external DB without any bumps as well, and the WP Migrate plugin (withing ‘new’ Wordpress) worked as expected, also connecting to RDS; we managed to do the migration of the first site from Multisite to its Virtualmin without too much hassle (some tweaking here and there, but it’s live now, even the SSL certs got delivered).

So, we’ll wait on this one and hope it gets addressed/resolved when it needs to; in the mean time I’ll proceed migrating the other sites.

Thanks!

PD: the plugin did change the wordpress admin user/password in the new DB to the one of the old site, so some DB mangling with WP Workbench would be very welcome, like being able to ‘rename’ the admin username, since it can’t be done from there, now.

K.-