2

Earlier this evening I migrated an installation of WHMCS from another web-server. Upon finishing this, I did the following...

  • Went into Cloud Flare and changed the IP of the Sub-Domain record to point to the new CPanel/website.
  • Created a new sub-domain in CPanel to point to the proper directory
  • Checked the Advanced DNS Zone Editor to ensure that the A-Record for the sub-domain was pointing to the web-server as expected.

Essentially I did everything that this person described in a similar thread. https://serverfault.com/questions/702383/how-to-create-a-subdomain-on-cpanel-while-cloudflare-is-hosting-my-dns

It seems to actually work partly when using HTTP:// but none of the images/css are working. That is fine as it should actually be operating as HTTPS:// anyways. Unfortunately when I use that protocol, I just get a page not found error message. Is there any steps I am missing for this to work?

  • 1
    This is very difficult to look at without knowing the actual domain/subdomain. – damoncloudflare Aug 11 '15 at 19:01
  • 1
    You purchased a SSL for sub domain? since your need to secure cpanel > cloudflare otherwise SSL is pointless. – Simon Hayter Aug 17 '15 at 11:15
1

SSL must be enabled for every domain/subdomain required individually in cPanel.

If you have moved your WHMCS installation to another domain, it is likely that you will need to regenerate the CSR/Key and request a new certificate. Once you've done that, follow the usual procedure to set it up and enable SSL for your subdomain.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.