Cloudflare is running Origin CA but they are not a public CA. The “Origin CA” allows CloudFlare to sign and revoke certificates for the connection between Cloudflare and the real origin host (usually not publicly known). These certificates do not have a trust chain to commonly used user agents’ trust store. That means that certificates signed by “Origin CA” are not trusted by e.g. Firefox, Chrome or Safari. That’s okay because the use case for these certificates is to secure a connection between Cloudflare the front end server (technically HTTP reverse proxy with TLS support) and the real host backend server.
For all sites served through Cloudflare, they support Universal SSL which seems to be currently backed by public COMODO CA. Inspecting the certificates of a couple of sites running via CloudFlare suggests that they are getting “Domain Control Validated” certificates from COMODO where CN record points to actual Cloudflare controlled reverse proxy (e.g. sni9922.cloudflaressl.com) and Subject Alternative Names lists actual domains that are served via CloudFlare. Each certificate is used for a handful of domains.
They obviously need SNI to figure out which certificate to give to any new connection but they should be able to acquire a real certificate for any domain they control (that is, every certificate could have a CN record pointing directly to actually hosted domain instead of something that looks like sni9922.cloudflaressl.com).
They are obviously able to get “Domain Control Validated” certificates for any host running via them because they control the DNS records (your DNS records must point to Cloudflare to use Cloudflare for your host) and any new HTTP (or HTTPS) connections go to their front end servers.
TL;DR: Cloudflare cannot provide a valid SSL/TLS certificate for domains not under its control. However, all clients of CloudFlare have to host their DNS records on Cloudflare and as a result, Cloudflare has domain control for all its clients.
Cloudflare and DDoS (few conversations that further describe the topic and specific steps to take)
read actually the official answers of the engineers
Well even though Cloudflare is great, I seriously doubt their DDoS protection, X people were Able to take down my site for around 20minutes. And recently it started showing 521 Errors(WebServerIsDown), but unproxied it and it all worked fine.
So think twice before using Cloudflare (check their trustpilot )
That’s why I put a few links above because people think it’s enough to put the domain on Cloudflare and it’s all automated.
CF protects only from certain DDoS levels - for everything else you need to know your site and edit all settings on CF in detail to ensure adequate protection.
If the attacker passes the JS challenge because it/he is a smart bot or simply a person
it can refresh your PHP thousands of times…
That’s why it’s useful to use rate-limiting on certain pages like login or some others that generate a lot of CPU and RAM, or just grant access from your country,
and dozens of other tricks and with that create a bottleneck through which only valid traffic will pass.
PHP (rate-limiting - against brute force) can also be limited on the server via the appropriate code
but it is certainly better to prevent it before it touches the origin…
or otherwise play around with page rules or FW on CF
In short you need to make it as difficult as possible for the attacker,
but for some attacks there is no defense if someone knows well where and what to do on your website.
Search engines Bing and Google also allow you to ping them with your new sitemap manually. To do that, you should visit in your browser the following URLs: