Database monitors reject TLS-required URLs with provider CA chains

### 📑 I have found these related issues/pull requests I found a few related reports and feature requests, but I did not find an open PR that fixes this behavior for database monitor connection strings: - #2062 asks for PostgreSQL SSL certificate settings. This is related, but this bug is about the existing `sslmode=require` connection-string mode being treated as certificate-verifying TLS. - #2459 asks for MySQL/MariaDB SSL settings. This is related, but this bug is about common URI TLS modes such as `ssl=true`, `ssl-mode=REQUIRED`, and `sslmode=require` not mapping cleanly to the mysql2 connection options used by the monitor. - #4100 reported a similar PostgreSQL `self-signed certificate in certificate chain` symptom with a managed database, but it was closed as a help issue. - #5807 reported an RDS PostgreSQL monitor failing because the connection was not encrypted, but it used SQL Server-style query parameters rather than PostgreSQL `sslmode`. ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description Some managed database providers require TLS for PostgreSQL/MySQL connections, but they use a private or provider-specific CA. For a monitor whose job is just to check service availability, users commonly use a connection string mode that means "use TLS" without also requiring CA verification. For PostgreSQL, `sslmode=require` should establish an encrypted connection without requiring the provider CA to be trusted locally, unless a CA is explicitly supplied. For MySQL/MariaDB, common URI forms such as `ssl=true`, `ssl-mode=REQUIRED`, and `sslmode=require` should enable TLS for the monitor without failing on provider/private CA chains. Currently these monitor checks can fail with certificate-chain errors even though the database is reachable and the connection string asks only for TLS to be required. ### 👟 Reproduction steps PostgreSQL: 1. Create a PostgreSQL monitor. 2. Use a managed PostgreSQL database connection string that requires TLS and uses a private/provider CA, for example: `postgres://user:password@example-host:5432/defaultdb?sslmode=require` 3. Save the monitor and wait for a check. MySQL/MariaDB: 1. Create a MySQL/MariaDB monitor. 2. Use a managed MySQL-compatible database connection string that requires TLS and uses a private/provider CA, for example one of: - `mysql://user:password@example-host:3306/db?ssl=true` - `mysql://user:password@example-host:3306/db?ssl-mode=REQUIRED` - `mysql://user:password@example-host:3306/db?sslmode=require` 3. Save the monitor and wait for a check. ### 👀 Expected behavior The database monitor should connect with TLS and report the service as up when the database is reachable and the query succeeds. If a PostgreSQL CA is explicitly supplied with `sslrootcert`, certificate verification should still be preserved. ### 😓 Actual Behavior The monitor can fail with an error like: ```text self-signed certificate in certificate chain ``` For MySQL/MariaDB URI modes, the monitor also does not currently normalize the TLS-related URI flags into the `mysql2` `ssl` option used by the driver. ### 🐻 Uptime-Kuma Version 2.4.0 ### 💻 Operating System and Arch Docker on Linux amd64 and arm64 ### 🌐 Browser Chrome 137 ### 🖥️ Deployment Environment - **Runtime Environment**: - Docker: tested in Docker container builds for `linux/amd64` and `linux/arm64` - Node.js: 22.x inside the Uptime Kuma container - **Database**: - Uptime Kuma app database: SQLite embedded - Monitored databases: external managed PostgreSQL and MySQL-compatible services - **Uptime Kuma Setup**: - Database monitors using connection strings ### 📝 Relevant log output ```bash session self-signed certificate in certificate chain ```