Unable to connect to Cloud SQL (PostgreSQL) database from Django app in GAE

Google Cloud Database
1

Hi,

I teach a software development class where students progressively build a web application in Django, and eventually deploy it to Google App Engine. This is the second year we do this sequence of homeworks and, last year, we were able to successfully deploy the apps by essentially following these instructions: https://cloud.google.com/python/django/appengine

When updating the homework this year, we were able to complete all the steps but, when we got to the very end (after setting up the database and deploying the app), we keep getting the following error:

connection to server on socket "/cloudsql/rabble-borja:us-central1:rabble/.s.PGSQL.5432" failed: Connection refused
	Is the server running locally and accepting connections on that socket?

Furthermore, the Cloud SQL logs show the following:

Cloud SQL connection failed. Please see https://cloud.google.com/sql/docs/mysql/connect-app-engine-standard for additional details: config invalidated after TLS handshake failed, error = certificate had CN "", expected "rabble-borja:rabble"

(yes, the error message includes a reference to mySQL, even though it is definitely a PostgreSQL database)

Please note that the app works correctly when we run it locally and use Cloud SQL Auth Proxy to connect to the database. We’re able to initialize the database, upload a fixture with some test data, and run the app without any issues. So, the database itself is definitely running, has the correct data and user, etc. The issue seems to be specifically when the app deployed on GAE tries to connect to the database.

We’ve tried several things to debug this issue:

  • We’ve run through the instructions in https://cloud.google.com/python/django/appengine to the letter (to make sure it wasn’t an issue with some subtle step missing from the instructions we prepared for the students). We still get the exact same error.
  • I asked a TA to run through the instructions (both ours and the official ones) with their account, to make sure this wasn’t some configuration issue in my account specifically. They still get the same error.
  • We tried using a MySQL database and get the same error. We also tried deploying a PostgreSQL 15 database (the same one we used last year), and still get the same error.
  • There a few pieces of documentation that mention giving the Cloud SQL Client role to the app account in IAM. We’ve tried this and still get the same issue.
  • We’ve double-checked that the app and database are being deployed to the same region (us-central1).

Any suggestions on what could be going on?

1 Like
2

I’m experiencing exactly the same issue. I’ve been trying to fix it for hours and still haven’t found a solution :disappointed_face:

3

Your class is encountering connection failures between Django on App Engine Standard and Cloud SQL. These errors, including “Connection refused” at the socket and Cloud SQL logs showing “config invalidated after TLS handshake failed, error = certificate had CN ‘’, expected ‘rabble-borja:rabble’,” suggest a platform-level issue within Google Cloud, not a configuration problem in your coursework.

The core issue is a TLS handshake failure. While your Django app correctly targets the Unix socket path, the Google-managed proxy cannot establish a secure session. The Cloud SQL instance returns a certificate with an empty or incorrect Common Name, which the proxy rejects before any connection can proceed.

Since the connection works locally via Cloud SQL Auth Proxy, the credentials and socket paths are likely correct. Changes to settings.py, such as setting a port or adjusting the host, will not resolve the underlying certificate mismatch. The failure appears to originate from App Engine Standard’s internal proxy layer.

To maintain teaching continuity, use a temporary workaround: enable Public IP access on Cloud SQL, allow the necessary Authorized Networks, and configure Django to connect via the public IP. This bypasses the Unix socket and avoids the failing proxy.

For a longer-term fix, consider deploying to App Engine Flexible or Cloud Run. Both support the Cloud SQL Auth Proxy as a sidecar, offering a more transparent and reliable connection method that avoids internal socket-based proxying.

This issue should be reported to Google Cloud Support. The reproducibility, the certificate mismatch, and the fact that it breaks despite following official documentation indicate a likely regression. If your institution is part of Google Cloud’s education programs, escalate through that channel to ensure it is investigated.

4

Thanks! I have escalated this to Google Cloud Support through our university.

In the interim, we seem to have identified another workaround based on something someone suggested on Stack Overflow: by default, Cloud SQL instances are configured with a “Google managed CAS certificate authority”. Creating the Cloud SQL instance with a “Google managed internal certificate authority” seems to fix the issue. This has the drawback that the CA type cannot be changed after creating the Cloud SQL instance, but this is not a big deal on our end, since we can just ask students to pay close attention to that option when creating the Cloud SQL instance.

1 Like
5

That’s a good discovery and a great workaround. Thanks for sharing it.

You’re absolutely right: the TLS handshake issue likely stems from a mismatch in how App Engine’s internal proxy validates certificates issued by the default Google-managed CAS certificate authority. Switching to the Google-managed internal certificate authority appears to align the CN expectations between the App Engine proxy and Cloud SQL, allowing the handshake to succeed.

While the immutability of the CA type post-creation is a limitation, it’s manageable in a classroom setting, especially since you’re in control of the instructions. Adding a clear note to your assignment guide or setup instructions (for example, “Ensure you select ‘Google-managed internal CA’ during Cloud SQL instance creation”) should keep students on track.

Also, it may be worth updating your course’s Cloud SQL provisioning script or GCP template (if you use one) to explicitly include this CA selection to prevent any accidental misconfigurations.

6

Following up on this, I did escalate this to Google Cloud Support, and it appears that the default CA for Cloud SQL instances was recently changed from “Google managed internal certificate authority” to “Google managed CAS certificate authority” (which, as noted above, will cause connections from a Django app in GAE to fail).

They have reverted this change, and “Google managed internal certificate authority” has gone back to being the default. This ensures that someone following the official Django/GAE instructions won’t run into the issue originally described in this post.