Cloudflare to Cloudflare CNAME Records

[zachdeibert]

I just set up a CNAME record in Cloudflare pointing to readthedocs.io and it got an SSL certificate for the custom domain so this seems to no longer be a problem.

[ericholscher]

Yea, I believe we have fixed this issue. The only remaining issue is users who are proxying to us via some other hosting provider.

The current issue:

• User points docs.example.com to their hosting provider
• docs.example.com is then proxied to readthedocs.io
• We create a CF domain record for docs.example.com, which doesn't validate because it isn't pointing at CF
• We remove the docs.example.com domain from CF as invalid
• The proxy from docs.example.com to CF breaks, because CF doesn't know how to route docs.example.com without the domain object

I don't believe there is a way for us to fix this. Users that are proxying to us should probably point directly to our servers instead of CF (which is what the cf-to-cf subdomain was for). We could also have our application have some kind of proxied logic on the RTD Domain object, and then use that to not delete the CF records for these domains.

/cc @stsewd

[stsewd]

We don't delete the domains, but there is a PR to be able to mark them as inactive and delete them after that, so users don't block the original user to setup a custom domain.

Recently I setup a cloudflare domain and only needed to disable the orange cloud.

[davidfischer]

@zachdeibert Did you use Cloudflare strictly for DNS (the gray cloud in their UI) or were you proxying the domain (the orange cloud)? Unless something has changed, the former should be fine and the latter is still a problem.

[zachdeibert]

When I created the record I had it set to proxy, but then once I clicked save it changed it to DNS only automatically

[davidfischer]

Interesting. I wonder if Cloudflare does that automatically or something.

[0xjjpa]

Jumping on this issue as I recently quoted this PR in a Cloudflare discussion forum. In short, I'm not sure whether RTD needs to configure something to make a subdomain on Cloudflare work properly, or Cloudflare needs to give users more control on how to handle custom subdomains that alias to services running on Cloudflare. Right now, no configuration really works for me:

1. If I use HTTPS and point my CNAME to readthedocs.io, I get the following (understandable) error:

2. If I use HTTPs and point my CNAME to cloudflare-to-cloudflare.readthedocs.io, my browser gets into a 404 loop of hello showing me some cached error page, but doing curl -IL https://docs.hoprnet.org returns the following:

jose_aguinaga@to-delete:~/tmp$ curl -IL https://docs.hoprnet.org
curl: (60) SSL: no alternative certificate subject name matches target host name 'docs.hoprnet.org'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above

So maybe this prompts a new question which is, what would be the proper way to configure RTD with SSL and Cloudflare?

[ericholscher]

@jjperezaguinaga Pointing to readthedocs.io and using HTTPS should definitely work. Is your domain "orange clouded" in that configuration? If it isn't, it should work. We're running that setup for thousands of domains without issue.

[zachdeibert]

@jjperezaguinaga

I had the same issue. I pointed my domain to readthedocs.io (not following the special Cloudflare instructions, which is why I created this PR to remove them), and after a few days (probably due to exponential retry timeout or something) it started working.

For reference, here is my working record:

In the time between my record setup and it starting to work, that is the same SSL error my browser was reporting (but if I put in a temporary security override in my browser it worked just fine and hit the RTD servers).

[davidfischer]

@zachdeibert

Based on your record, you're using DNS only. You should not follow the special Cloudflare instructions. Those special instructions are only for folks proxying their domain.

Edit: we probably need to update the docs to be more explicit. It doesn't help that this functionality has changed names a few times. It was the "orange cloud" but now it is proxying/DNS-only (which admittedly are clearer).

[zachdeibert]

@davidfischer
Yes, however Cloudflare no longer allows the proxying (probably since it's no different to proxy to the same edge server vs just updating the DNS record), and it now treats the readthedocs.io target differently than other CNAME targets so I believe there must have been some update to Cloudflare making this no longer necessary. However, the automatically-issued SSL certificates still work even though it isn't "proxied."

RTD7801.mp4

[davidfischer]

I believe there must have been some update to Cloudflare making this no longer necessary.

This is interesting. They must have changed it.

PS: thanks for the video. That's really helpful.

[davidfischer]

Sorry for my delay in approval. Cloudflare had changed something out from under me (for the better, to be fair) and I still thought we needed this. This is definitely an improvement. I tested this myself in Cloudflare and I see the same "managed externally" message in Cloudflare.