Dedicated SSL Certificate with Custom Hostname Not Allowing secure forwarding

We have a “Dedicated SSL Certificate with Custom Hostname” enabled via Cloudflare and are trying to forward a domain like this: (with www and hosted on Pagely) to one like this: (without www and hosted on NationBuilder).

We have a CNAME in Cloudflare for donate and www.donate pointed to NationBuilder and a Cloudflare Page Rule matching set as a Forwarding URL with a 301 Permanent Redirect to

However, going to (with HTTP) doesn’t load the page and shows this error:

Invalid URL
The requested URL “[no URL]”, is invalid.
Reference #9.d12e0e6b.1544556712.15bb157

and going to (with HTTPS) doesn’t load the page and shows this error:

This site can’t provide a secure connection sent an invalid response.

(Forwarding with either HTTP or HTTPS works fine as long as www is not present.)

NationBuilder recommended checking with Cloudflare to ensure that we had a certificate for forwarding to Isn’t that what the “Dedicated SSL Certificate with Custom Hostname” should do? How can we set up our DNS to forward properly? is currently served by Akamai. This, after following a long name of CNAME aliases. You would need to set it to :orange: for a Page Rule to take effect.

Thanks, when I did that recently, we had reports of other pages going down though:

Could that have been related?

Our login page is still not loading for a client. Other pages seem okay but when trying to log in to WordPress admin they just get a screen that says “Error”. Could this be related to any Cloudflare DNS setting or caching issue?

Not likely a DNS or caching issue if you’ve left everything somewhat stock. Page Rules can interfere with login pages if the rule has an incorrect setting.

Can you post a screenshot of that error screen?

The error screen is just saying Error:

So that’s no help I guess.

But I did have a page rule enabled. I’ve disabled now but here are the settings that I had:

Since it’s just the one client, and the page loads for me, it’s more than likely it’s an issue at their end. Have them clear their browser’s cache or try a different browser. Or try on mobile over a cellular network.

The client (located in DC) says even after hard refreshing, switching browsers, and using an incognito window, the site doesn’t load. Although it does load when accessing it a via cellular network in that DC office. The IT person in the office rebooted their firewall but doesn’t see any indications that it’s causing the issue. This is the response he sees from the site:

Request URL:
Request Method: GET
Status Code: 403
Remote Address:
Referrer Policy: no-referrer-when-downgrade
Response Headers
content-encoding: gzip
content-type: text/html; charset=iso-8859-1
date: Thu, 13 Dec 2018 00:28:30 GMT
server: Pagely-ARES/1.3.20
status: 403
vary: Accept-Encoding
Request Headers
:method: GET
:path: /
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: max-age=0
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Here’s the Dedicated SSL Certificate with Custom Hostname we recently added by the way:

Not sure if that’s at fault or not.

Can you ask to clear their DNS cache? Or maybe they’re MITM’ing TLS? If Cloudflare was working, it would show server: Cloudflare.

1 Like the root domain is not on Cloudflare. If that was the case when they tested whatever generated that error message would be independent of Cloudflare.

That isn’t going through Cloudflare, so whatever DNS server the user is using (or their local machine) still has the old IP address cached. When they switch networks to cellular, different DNS server which succeeds so that tends to reinforce that theory.

1 Like

Thanks all, the issue is resolved.

Looks like there were two separate problems. The client wasn’t able to view the site because their IP address was being banned by a security plugin (iThemes Security Pro). So we’ve since white listed it and those pages are visible again for them.

And for the original problem: forwarding to, I enabled the “DNS and HTTP proxy (CDN)” orange cloud icons for both “donate” and “www.donate” CNAMES, which allowed our page rule to work and then enabled “Always Use HTTPS” to also forward

This topic was automatically closed after 30 days. New replies are no longer allowed.