Поддомен, созданный на Cloudflare & CPanel не будет работать с HTTPS

Ранее этим вечером я перенес установку WHMCS с другого веб-сервера. Закончив это, я сделал следующее ...

  • Пошел в Cloud Flare и изменил IP-адрес записи поддомена, чтобы указать на новый CPanel /веб-сайт.
  • Создал новый поддомен в CPanel, чтобы указать на соответствующий каталог
  • Проверка редактора расширенной зоны DNS, чтобы убедиться, что A-запись для поддомена указала на веб-сервер, как ожидалось.

По существу я делал все, что описывал этот человек в подобной теме. https: //serverfault. ком /вопросы /702383 /как к Create-A-субдомен-на-Cpanel-While-CloudFlare-это-хостинг-мой-DNS

Похоже, что он работает частично при использовании HTTP: //, но ни один из изображений /css не работает. Это нормально, поскольку на самом деле он должен работать как HTTPS: //в любом случае. К сожалению, когда я использую этот протокол, я просто получаю сообщение об ошибке, не найденное страницей. Есть ли какие-то шаги, которые мне не хватает для этого?

2 голоса | спросил Aidan Knight 2 AM00000030000004431 2015, 03:26:44

2 ответа


1

SSL должен быть включен для каждого домена /поддомена, требуемого индивидуально в cPanel.

Если вы переместили установку WHMCS в другой домен, вполне вероятно, что вам нужно будет восстановить CSR /Key и запросить новый сертификат. После этого выполните обычную процедуру настройки и включите SSL для своего поддомена.

ответил Peter Bishop 17 AM000000110000000631 2015, 11:06:06
0

Используете ли вы свой собственный SSL, SSL на Cloudflare или оба? Является ли сообщение не найденным в вашем приложении, cPanel master или сервером 404 по умолчанию, или чем-то другим, например, стандартным нечетким браузером 404?

Если вы видите своего хостинг-провайдера по умолчанию или страницу cPanel 404 по умолчанию, это говорит о том, что что-то пошло не так, когда был настроен субдомен, локальный SSL не был регенерирован на новом сервере, DNS не синхронизирован вправо, или это просто навсегда для вашего интернет-провайдера, чтобы реализовать запись TTL. Если вы устраните возможность ошибки при настройке, ваш сертификат будет хорош, и ваш хост /WHM действительно сможет использовать удаленный DNS, посмотрите на ваш интернет-провайдер и локальное кэширование.

Способом протестировать это за пределами вашего интернет-провайдера является использование одного из многих веб-прокси , чтобы просмотреть страницу (поскольку их DNS-запрос не будет кэшироваться под TTL). Если он имеет тот же 404, а затем проследить шаги, создающие субдомен, убедитесь, что вы выбрали правильный тип SSL в Cloudflare и, возможно, сделаете правило страницы для принудительного https: //для всех доменов (например, target *.example.com*). Имейте в виду, что https: //будет использовать правило 1 страницы, и вы не сможете объединить его в другие. Также имейте в виду, что если ваш серверный сервер SSL работает неправильно или нет, вам нужно выбрать «Гибкий SSL» в Cloudflare .... даже если просто проверить. Если это работает, вы знаете, что это ваша платформа /приложение или неверно сконфигурированный серверный SSL-сервер.

Если вы дошли до этой точки с помощью описанных выше шагов или это ваша платформа /приложение, создающая 404, то похоже, что субдомен может работать правильно, однако ваша платформа /приложение может не распознать правильные заголовки прокси CF и поэтому не понимает, когда /где /как включить HTTPS: //. Симптомы этого включают недостающие активы, переадресацию циклов и /или другое странное поведение, такое как неисправные скрипты.

Чтобы проверить это, сделайте папку в своем домене, которая либо снаружи , либо отключена из маршрутизации платформы /приложения. Поместите изображение туда и файл css. Доступ к ним напрямую с помощью https, и они могут работать. Если это так, вы либо навязываете https: //как правило выше, чем правило CF-страницы, либо можете объединить альтернативные заголовки, используя что-то вроде этого (для примера 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;
}

Это переписывает все более неясные заголовки в 'HTTPS' => 'on', которые все может понять. Каждая платформа /приложение отличается, хотя .... некоторые нуждаются в том, что в библиотеке, классе или в качестве метода слияния .... другие просто в индексе ..... другие в событии или крючке .... и т. Д. Принудительное https: //правило страницы может быть более легким выбором, чем этот код изменяется в вашем бэкэнд. Надеюсь, что поможет

ответил dhaupin 17 PM00000060000005431 2015, 18:09:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132