旧版TLS1.0客户端无法连接自定义域名下的Google App Engine

What's Going On Here? #

The root issue is that the GFE servers behind ghs.googlehosted.com (the default target for Google-managed SSL certificates on custom domains) disable TLS 1.0 and TLS 1.1 by default. Meanwhile, the GFE servers for appspot-preview.l.google.com still support these older protocols—which explains why your tests against the appspot domain work perfectly, but custom domain connections fail for legacy clients.

Solutions to Try (Ranked by Practicality) #

1. Temporary Quick Fix: Repoint Your Custom Domain to appspot-preview.l.google.com #

This gets legacy clients connected immediately, though it’s not a permanent long-term solution:

• Log into your domain registrar’s DNS management panel
• Locate the CNAME record for api.my-project.com (currently pointing to ghs.googlehosted.com)
• Update the target to appspot-preview.l.google.com
• Wait for DNS propagation (usually 5-30 minutes, up to 24 hours in rare cases)
• Retest your TLS 1.0 client—handshake should now complete successfully

⚠️ Note: appspot-preview.l.google.com is intended for preview environments, so Google may modify or deprecate it later. Use this only as a short-term workaround while you implement a more stable fix.

2. Long-Term Stable Fix: Deploy a Google Cloud Load Balancer #

This is the officially supported method to take full control of your TLS protocol settings:

1. Create an HTTPS Load Balancer in the Google Cloud Console
2. Set up the backend: Use a Serverless Network Endpoint Group (NEG) to connect directly to your App Engine application
3. Configure SSL: Attach your Google-managed SSL certificate (or a custom one) that covers api.my-project.com
4. Adjust SSL Policy: In the load balancer settings, select an SSL policy that allows TLS 1.0 and TLS 1.1. You can use the pre-built COMPATIBLE policy, or create a custom policy explicitly enabling these older protocols
5. Update DNS: Change your custom domain’s CNAME record to point to the load balancer’s frontend hostname (e.g., 123.45.67.89.lb.googleusercontent.com)

This approach keeps your setup aligned with Google’s recommended architecture while giving you full control over TLS compatibility.

3. Best Future-Proof Option: Push Clients to Upgrade TLS Versions #

TLS 1.0 and 1.1 are widely recognized as insecure—they lack modern security features and are being phased out across the industry. If feasible, reach out to users of the legacy TLS 1.0 clients and encourage them to upgrade software that supports TLS 1.2 or newer. This is the most secure and sustainable solution long-term.

How to Verify Your Fix #

After making changes, run this OpenSSL command to confirm TLS 1.0 connections work:

openssl s_client -connect api.my-project.com:443 -tls1

A successful handshake (with certificate details returned) means your fix is working as intended.

内容的提问来源于stack exchange，提问作者Abhijit Kalamkar