SSL 526 Error out of nowhere

Hello all. I’d set up a website a few months ago that has been chugging along just fine until now. I’ve changed no settings since, but happened to log on today and noticed the website displays an SSL error. I’d set up the website in accordance with the instructions kindly provided by @sandro, with SSL/TLS mode set to Full (strict). The website loads normally with SSL/TLS mode set to Full but this is obviously not ideal.

Not sure if it’s related but the Google sites dashboard is showing the connected domain (vup.plumbing) has an invalid DNS. No settings have been changed in the Cloudflare dashboard.

I am a complete noob with website administration and would greatly appreciate someone helping me out with this probably simple problem.

The most likely cause is your origin’s SSL certificate has expired after the usual 3 months. You need to renew it.

Thank you for your reply. It’s almost exactly 3 months since it was put up so while that seems likely the certificate doesn’t seem to have expired?


Nevertheless, I removed the domain from connected domains in the Google dashboard and readded it which is supposed to renew the certificate according to this post.

That seems to have done something as now I’m getting an SSL Handshake 525 error even though my CNAME is set to ghs.googlehosted.com. Not sure if it just needs awhile to get the DNS sorted? Do I need to do anything in the Cloudflare dashboard after renewing the certificate or reconfiguring the connected domain?

That is the Cloudflare edge certificate which is updated automatically updated by Cloudflare. If you are getting a 526 error, then it means Cloudflare can’t validate the SSL certificate on your origin server. You need to check there.

If the error has now changed from 526 to 525, it means whatever you did on the origin server has broken the SSL there. You are best to pause Cloudflare, or set the DNS record to “DNS only”, so requests go direct to the host and you can see the error, fix the problem, then re-enabled Cloudflare.

Usually that record should be set to “DNS only” anyway.

2 Likes

Oh I see. Unfortunately Google sites does not have a robust dashboard so it’s hard to tell what’s going on. I did try disabling the proxy for the CNAME and A entries but may not have waited long enough.

After disabling the proxy I get “This site can’t be reached”

I’d left the proxy enabled overnight and this morning Google is saying the DNS was invalid. I’ll try leaving it for a few hours with the proxy disabled and reconnect the domain.

I appreciate your help with this.

Your A record for 192.0.2.1 I assume is for a redirect, so that should be “Proxied”, not “DNS only”.

2 Likes

Ahhh. I’d disabled both. It works now! Thank you so much!
Out of curiosity, why do you say to leave the proxy turned off for the CNAME entry? It seems to work with proxy enabled after the origin server recognizes the DNS - I’m assuming if you leave the proxy enabled that’s what breaks when the origin servers certificate is renewed?

For domains hosted on ghs.googlehosted.com usually “DNS only” is required to make it work. If “Proxied” works for you, you can try it. But if any problems, turn it off again.

The A 192.0.2.1 record must always be proxied so the request goes to Cloudflare for the redirect to take place.

2 Likes

When a CNAME is proxied, synthetic A and AAAA records of the Cloudflare proxy are published. This will cause any lookup of a CNAME record at that name to fail. During the setup of a custom domain on Google Sites, that will prevent Google from using the CNAME for validation. As long as Google is not continuously attempting to validate your custom name, the proxy can most likely be enabled safely.

With the proxy enabled, it is likely that certain settings interfered with your site’s certificate renewal. I have observed the Always Use HTTPS setting interfere with certificate renewal that uses an HTTP-01 ACME challenge. For that reason I leave it off and use my own rules to redirect to HTTPS. I carve out an exception to that redirect for the /.well-known/acme-challenge/ path.

I dont know if that approach works on Google Sites or not. I made a Google Site to use for testing those sort of things, but it has been a rather low priority project that is still only getting started.

1 Like

Interesting, thank you for your input. So I did have page rules set up for http://vup.plumbing and https://vup.plumbing to redirect to https://www.vup.plumbing. I did not have Always Use HTTPS enabled when the issue occurred (I did just enable it today). Do you think it’s worth setting up the rules as you have it in lieu of using the Always Use HTTPS?

I cannot answer that yet. My initial testing using Let’s Debug suggests that my current rules, which work as expected with my own servers, will need some minor adjustment to work with Google Sites.

Google appears to redirect the /.well-known/acme-challenge/ path to HTTPS, while one of my Cloudflare rules forces it to HTTP. This causes too many redirects and will need to be modified as an exception to the exception

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.