We have a “Dedicated SSL Certificate with Custom Hostname” enabled via Cloudflare and are trying to forward a domain like this: https://www.donate.example.com (with www and hosted on Pagely) to one like this: https://donate.example.com (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 https://www.donate.example.com set as a Forwarding URL with a 301 Permanent Redirect to https://donate.example.com.
However, going to http://www.donate.promundoglobal.org (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 https://www.donate.promundoglobal.org (with HTTPS) doesn’t load the page and shows this error:
This site can’t provide a secure connection www.donate.promundoglobal.org sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
(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 www.donate.example.com to donate.example.com. Isn’t that what the “Dedicated SSL Certificate with Custom Hostname” should do? How can we set up our DNS to forward properly?
www.donate.promundoglobal.org is currently served by Akamai. This, after following a long name of CNAME aliases. You would need to set it to for a Page Rule to take effect.
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.
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: https://www.promundoglobal.org/
Request Method: GET
Status Code: 403
Remote Address: 18.220.250.87:443
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
:authority: www.promundoglobal.org
: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
promundoglobal.org 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.
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 https://www.donate.promundoglobal.org to donate.promundoglobal.org, 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 http://www.donate.promundoglobal.org.