Find the endpoint and database credentials for a provisioned MySQL service, then configure an application connection with the intended network and TLS checks.

Open the intended service

Sign in to the client area, open the intended MySQL service and choose Manage. Use that service’s module tabs for the sections below. Confirm the service and resource before making a change. Enable the corresponding client feature on the intended offering. If a section is missing or unavailable, review that service’s configuration rather than trying a different service.

Read the connection details

On the service overview, choose View connection details. Read the actual Host, Port and Username. Use Show only when you need to reveal the password, and keep copied credentials out of public screenshots or messages.

The administrator credential shown here is different from the Google service-account key. Never put a provider JSON key in your application’s database password field. For routine application access, arrange a separate database user with the permissions the application needs.

The instance can hold several application databases. The connection panel does not choose an application database for you; use the actual database name created for the application.

Allow the application source

For a direct public-IP connection, the application’s public outbound IPv4 address must be in Trusted Sources. This is usually the application server’s outgoing address, not the visitor’s address or your laptop’s address. Confirm it with the host managing the application network. Network allowance does not replace the database username and password.

Configure TLS deliberately

The copied MySQL example includes --ssl-mode=REQUIRED. That requires encryption, but does not verify the server certificate’s authority or identity. Do not describe an encrypted connection alone as an identity-verified connection.

Use the correct CA certificate and connection configuration for this instance’s actual server-CA mode. For Cloud SQL’s per-instance CA mode, verifying the unique instance CA verifies that instance’s identity. Shared CA mode also requires the appropriate hostname verification; the public IP displayed in the module is not automatically the certificate hostname. Do not assume your client’s built-in public trust store is sufficient, or disable verification to bypass a certificate error. See Google’s Cloud SQL certificate configuration.

In a compatible MySQL client, VERIFY_CA and VERIFY_IDENTITY add certificate checks beyond REQUIRED; use the mode and trusted CA supplied for the actual instance. MySQL explains these encrypted connection modes. The module does not provide a CA-download control in this interface.

Verify application access

From the intended application server, check that the connection reaches the correct host and port, uses the intended database and user, and negotiates the required TLS verification. A Running service badge or successful provider account test does not establish those application checks.

For a failure, distinguish network timeout, authentication, missing database and certificate verification errors. Keep the password and provider key out of shared screenshots.

See the PD Google Cloud MySQL Blesta guide for related setup, or explore PD Google Cloud MySQL.