Cloudflare
See what Cloudflare's proxy hides from the outside: whether the trip from Cloudflare to the server is encrypted, and which server that is.
A site behind Cloudflare’s proxy (the orange cloud) answers from Cloudflare’s addresses, with Cloudflare’s certificate. From the outside every site looks the same: padlock, Cloudflare. What happens between Cloudflare and the server is set in the Cloudflare account, and connecting it lets CheckRoost read that.
What it does in CheckRoost
- The SSL/TLS mode of every zone. Flexible means visitors see a padlock while Cloudflare fetches every page from the server over plain http, so logins and form data cross the internet unencrypted. It fails the security score’s Encryption to the server item and takes 30% off the whole score. Full encrypts but accepts any certificate, and counts as half. Full (strict) passes.
- The real server behind each proxied name. The blocklist check otherwise measures Cloudflare’s reputation, because that is all a proxied name resolves to. With a zone connected it measures the server the zone’s own DNS record names, and follows it when the record changes.
- The minimum TLS version, as a security score item: 1.2 or newer passes, and 1.0 or 1.1 — Cloudflare’s default — counts half, with the setting to change.
- Fixes that say where to fix it. The score judges what a visitor actually gets: the HSTS header the site sends, and whether plain http redirects to https. Where those come from — the server, a plugin such as XT Essentials, or Cloudflare — does not matter, so Cloudflare’s own switches being off is never a finding on its own. When something is missing on a site behind Cloudflare, the suggested fix is the Cloudflare setting that supplies it.
- Always Use HTTPS, the minimum TLS version and HSTS for each zone, on the Cloudflare integration page.
- A Cloudflare SSL column on the Domains page, matched by name, so every monitor in a zone is covered.
Leaving it disconnected is a working setup
Hooking it up
Step 1. Create a custom API token
Cloudflare→My Profile→API Tokens→Create Token, then Create Custom Token. Not the Global API Key: it can change anything in every account you belong to, and CheckRoost refuses it.Step 2. Give it three read permissions
Under Permissions, all on Zone:Zone — Read,Zone Settings — ReadandDNS — Read. Nothing that edits. CheckRoost checks for all three when you paste the token and says which one is missing.Step 3. Choose which zones it covers
Under Zone Resources, All zones covers every zone in every account you are a member of, including a client’s account that has added you. Or pick specific zones or one account. Set an expiry date if you like; the integration page shows it.Step 4. Optionally, limit it to CheckRoost’s addresses
Under Client IP Address Filtering, allow only the addresses CheckRoost connects from, and a leaked token is useless anywhere else. Include both its IPv4 and IPv6 address: it reaches Cloudflare over IPv6, so the IPv4 one alone locks it out. They are not published here — they are also the server behind CheckRoost’s own Cloudflare proxy — so ask support for them.Step 5. Paste it into CheckRoost
Settings→Integrations→Cloudflare, as an owner or admin. It is checked against Cloudflare before it is saved, and the confirmation says how many zones it can read. It is stored encrypted and never shown again.
Within a minute or two the Cloudflare integration page lists the zones, and from then on they are read every hour. Changed the token — added a client’s account, say? Editing a token in Cloudflare keeps the same token, so press Sync now to have it read straight away instead of at the next hour.
What it reads, and what it never does
- The zone list, with each zone’s status and account.
- Four settings per zone: SSL/TLS mode, Always Use HTTPS, minimum TLS version and HSTS.
- The zone’s DNS records, of which only the proxied names and the server addresses they point at are kept. Nothing else from the record list — TXT records carry other services’ verification codes — is stored.
- Never a change. Every request is a read. A token with only read permissions could not change anything if it tried.
Server addresses are kept close
Hiding a site’s server is one reason it sits behind Cloudflare: an address somebody knows is an address they can reach around the firewall. So CheckRoost uses the addresses for the blocklist check, whose own page names the address it measured, for your team; the integration page only counts how many it knows. They are never shown on a status page or in a client report.
If it stops working
When the token expires or is revoked, the next read fails and the Cloudflare integration page shows Cloudflare’s reason. Two days after the last good read, the SSL modes and server addresses stop being used anywhere else, so a reading nobody is refreshing never stands in for the current setting. Create a new token and paste it with Replace key.
Disconnecting
Removes the token and everything the account reported; the blocklist check goes back to what it can see from outside. Delete the token in Cloudflare as well — removing CheckRoost’s copy does not cancel it.