Are you using your own SSL, an SSL on Cloudflare, or both? Is the page not found message within your app, a cPanel master or default server 404, or something else like a standard unpretty browser 404?
If you are seeing your default hosting provider or default cPanel 404 page, it hints that something went awry when the subdomain was set up, the local SSL isnt regenerated on new server, the DNS isn't syncNlinked right, or it's just taking forever for your ISP to realize the record TTL. If you eliminate the possibility of error in setup, your cert is good, and your host/WHM can indeed utilize remote DNS, look to your ISP and local caching.
A way to test this outside of your ISP is to use one of the many web proxies to view the page (since their DNS prob won't have it cached under a TTL). If it has the same 404, then trace back through the steps creating the subdomain, make sure you chose the right type of SSL in Cloudflare, and optionally make a page rule to force https:// on all domains (like target *.example.com*
). Keep in mind forcing https:// will use 1 page rule and you can't combine it into others. Also keep in mind that if your server side SSL is malfunctioning or not present, you need to choose "Flexible SSL" in Cloudflare....even if just to test. If this works, you know it's your platform/app, or a misconfigured server side SSL.
If you got to this point through the steps above, or it's your platform/app making the 404, then it sounds like the subdomain may actually working correctly, however your platform/app might not recognize the correct CF proxy headers, and therefore doesn't understand when/where/how to turn on HTTPS://. Symptoms of this include missing assets, redirect loops, and/or other strange behavior like malfunctioning scripts.
A way to test this is to make a folder on your domain that is either outside or disconnected from your platform/app routing. Put a picture in there and a css file. Access them directly with https and they may work. If this is the case, you either force https:// like above CF page rule, or you can merge in alternate headers using something like this (for a PHP example):
if (!isset($_SERVER['HTTPS'])) {
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
$proxy = array('HTTPS' => 'on');
} elseif (isset($_SERVER['HTTP_X_FORWARDED_PROTOCOL']) && $_SERVER['HTTP_X_FORWARDED_PROTOCOL'] == 'https') {
$proxy = array('HTTPS' => 'on');
} elseif (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] == 'on') {
$proxy = array('HTTPS' => 'on');
} elseif (isset($_SERVER['HTTP_FRONT_END_HTTPS']) && $_SERVER['HTTP_FRONT_END_HTTPS'] == 'on') {
$proxy = array('HTTPS' => 'on');
} elseif (isset($_SERVER['HTTP_X_URL_SCHEME']) && $_SERVER['HTTP_X_URL_SCHEME'] == 'https') {
$proxy = array('HTTPS' => 'on');
} else {
$proxy = array();
}
$_SERVER = array_merge($_SERVER, $proxy);
} else {
$_SERVER = $_SERVER;
}
That rewrites all the more obscure headers into 'HTTPS' => 'on'
which anything can understand. Each platform/app is different though....some need that in a library, class, or as a method merge....others just in index.....others in an event or hook....etc. A forced https:// page rule may be an easier choice than this code changes in your backend. Hope that helps