web-dev-qa-db-fra.com

Le sous-domaine créé sur Cloudflare et CPanel ne fonctionnera pas avec HTTPS

Plus tôt dans la soirée, j'ai migré une installation de WHMCS à partir d'un autre serveur Web. En terminant, j'ai fait ce qui suit ...

  • Entré dans Cloud Flare et changé l'adresse IP de l'enregistrement de sous-domaine pour qu'il pointe vers le nouveau site Web/CPanel.
  • Création d'un nouveau sous-domaine dans CPanel pour pointer vers le répertoire approprié
  • A vérifié l'éditeur de zone DNS avancée pour s'assurer que l'enregistrement A pour le sous-domaine pointait vers le serveur Web comme prévu.

Essentiellement, j'ai fait tout ce que cette personne a décrit dans un fil similaire. https://serverfault.com/questions/702383/how-to-create-a-subdomain-on-cpanel-while-cloudflare-is-hosting-my-dns

Cela semble fonctionner en partie avec HTTP: // mais aucune des images/css ne fonctionne. Cela convient car il devrait en fait fonctionner sous HTTPS: // de toute façon. Malheureusement, lorsque j'utilise ce protocole, je viens d'avoir un message d'erreur "page not found". Y a-t-il des étapes qui me manquent pour que cela fonctionne?

web-hostingdnssubdomaincpanelcloudflare
2
Aidan Knight

SSL doit être activé pour chaque domaine/sous-domaine requis individuellement dans cPanel.

Si vous avez déplacé votre installation WHMCS vers un autre domaine, il vous faudra probablement régénérer la CSR/clé et demander un nouveau certificat. Une fois que vous avez fait cela, suivez la procédure habituelle pour le configurer et activer SSL pour votre sous-domaine.

1
Peter Bishop

Utilisez-vous votre propre SSL, un SSL sur Cloudflare ou les deux? Le message de la page non trouvée dans votre application est-il un serveur cPanel maître ou par défaut 404, ou autre chose comme un navigateur standard non-obsolète 404?

Si vous voyez votre fournisseur d’hébergement par défaut ou votre page cPanel 404 par défaut, cela laisse à penser que quelque chose n’a pas fonctionné lors de la configuration du sous-domaine, que le SSL local n’est pas régénéré sur le nouveau serveur, que le DNS n’est pas synchronisé correctement ou qu’il prend indéfiniment votre FAI pour réaliser le record TTL. Si vous éliminez la possibilité d'erreur dans la configuration, votre certificat est bon et votre hôte/WHM peut en effet utiliser un DNS distant, consulter votre fournisseur d'accès Internet et la mise en cache locale.

Un moyen de tester cela en dehors de votre fournisseur de services Internet consiste à tilisez l'un des nombreux proxy Web pour afficher la page (car leur prob DNS ne la mettra pas en cache sous un TTL). Si le même 404 est identique, suivez les étapes de création du sous-domaine, assurez-vous de choisir le type de SSL approprié dans Cloudflare et créez éventuellement une règle de page pour forcer https: // sur tous les domaines (comme cible *.example.com*). N'oubliez pas que forcer https: // utilisera la règle d'une page et que vous ne pourrez pas la combiner à d'autres. N'oubliez pas non plus que si votre SSL côté serveur fonctionne mal ou n'est pas présent, vous devez choisir "SSL flexible" dans Cloudflare ... même si vous voulez le tester. Si cela fonctionne, vous savez que c'est votre plate-forme/application, ou un SSL mal configuré du côté serveur.

Si vous en êtes à ce point à travers les étapes ci-dessus, ou si votre plate-forme/application fabrique la 404, il semblerait que le sous-domaine puisse effectivement fonctionner correctement. Cependant, votre plate-forme/application risque de ne pas reconnaître les en-têtes de proxy CF corrects et, par conséquent, de ne pas t comprendre quand/où/comment activer HTTPS: //. Les symptômes incluent des ressources manquantes, des boucles de redirection et/ou d’autres comportements étranges tels que des scripts défaillants.

Une façon de le vérifier consiste à créer sur votre domaine un dossier qui est en dehors de ou déconnecté depuis votre plate-forme/routage d'application. Mettez une photo et un fichier css. Accédez-y directement avec https et ils peuvent fonctionner. Si tel est le cas, vous devez forcer https: // comme ci-dessus pour la règle de page CF ou vous pouvez fusionner d'autres en-têtes à l'aide de quelque chose comme ceci (pour un exemple PHP):

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;
}

Cela réécrit les en-têtes les plus obscurs dans 'HTTPS' => 'on' que tout le monde peut comprendre. Chaque plate-forme/application est différente cependant .... certains ont besoin que dans une bibliothèque, une classe ou une méthode fusionnée ... d'autres simplement dans l'index ..... d'autres dans un événement ou un hook .... etc. Une règle de page https: // forcée peut être un choix plus facile que ce code ne change dans votre backend. J'espère que cela pourra aider

0
dhaupin