Разное качество поддержки протокола HTTPS на разных хостингах

SSL Если раньше большинство сайтов использовало небезопасный протокол HTTP, то сегодня наблюдается массовый переход на протокол HTTPS, обеспечивающий шифрование данных. Эта тенденция добралась даже до меня, и я перевел свой персональный сайт на протокол HTTPS. Получив бесплатный SSL-сертификат (далее — сертификат) StartCom Class 1 DV, я занялся включением протокола HTTPS на хостинге. Оказалось, что в случае одних хостингов для этого требуется много времени и нервов, в случае других — все делается очень просто.

Очень похожие обещания хостеров

Сегодня многие хостеры продают сертификаты и обеспечивают поддержку протокола HTTPS даже на начальных тарифах. Например, HTS.ru, услугами которого я пользовался примерно с марта 2015 года, и Beget, на который пришлось перейти в конце июня 2016 года, предоставляют сертификаты (в отличие от HTS.ru, Beget предлагает не только купить платные, но и получить бесплатные сертификаты) и позволяют включить протокол HTTPS даже на самых дешевых тарифах Анлим 1 (1000Мб) и Blog, соответственно. Кажется, что предложения очень похожи, и можно воспользоваться услугами любого хостера. Как оказалось, здесь может скрываться большая ошибка, для выявления которой придется испытать обе услуги на собственной шкуре своем сайте. Именно поэтому я решил написать данную статью, которая поможет Вам хотя бы примерно знать о «сюрпризах», связанных с поддержкой протокола HTTPS на хостингах.

Процедура включении протокола HTTPS на хостингах

В подавляющем большинстве случаев для включения поддержки протокола HTTPS на виртуальном сервере необходимо выполнить две процедуры:
 Приобрести выделенный IP-адрес и переключить виртуальный сервер на его использование (необходимость покупки дополнительного IP-адреса связана с особенностями протокола HTTPS и недостаточной распространенностью технологии Server Name Indication (SNI), позволяющей применять один IP-адрес для нескольких HTTPS-серверов). Как правило, приобретение выделенного IP-адреса и переключение виртуального сервера на его использование является простой и интуитивно понятной процедурой, которая заключается в нажатии нескольких кнопок в панели управления хостингом. Стоимость выделенного IP-адреса зависит от хостинга. Например, HTS.ru продает выделенные IP-адреса по 85 /месяц с помесячной оплатой, а Beget по 660 /год с погодовой оплатой.
 Приобрести платный или получить бесплатный сертификат и установить его на виртуальный сервер. Как правило, все хостинги с поддержкой протокола HTTPS позволяют купить платный сертификат. Реже предлагается не только купить, но и установить уже имеющийся бесплатный или платный сертификат. Совсем редко можно не только купить или установить имеющийся, но и сгенерировать новый бесплатный сертификат. Часто установкой сертификата занимается служба поддержки, реже доступна дополнительная возможность самостоятельного изменения необходимых параметров виртуального сервера через панель управления хостингом. Например, HTS.ru позволяет купить платный или предоставить любой имеющийся сертификат и обещает, что он будет установлен службой поддержки в течение часа. Beget не только предлагает перечисленные услуги, но и предоставляет клиенту специальный раздел панели управления хостингом, с помощью которого можно быстро приобрести и установить платный, установить имеющийся или сгенерировать и установить бесплатный сертификат Let’s Encrypt.

Проверка корректности установки сертификата

Не забывайте о том, что возможность обращения к сайту по протоколу HTTPS и появление зеленого замочка в левой части адресной строки браузера совсем не гарантируют корректность установки сертификата и поддержку современного набора шифров. В связи с этим Вам придется заняться самостоятельной проверкой соответствующих параметров виртуального сервера. К счастью, сегодня есть много online-инструментов, которые не только позволяют выполнять необходимые тесты, но и предоставляют достаточно подробные инструкции по устранению основной массы выявленных ошибок. Если Вы испытываете затруднения с выбором сервиса проверки, я рекомендую попробовать SSL Checker от SSL Shopper. Расположенная ниже форма, любезно предоставленная SSL Shopper, позволяет запустить проверку корректности установки сертификата прямо на этой странице (результат проверки будет отображен в новой вкладке):

URL сайта:
(например, www.google.com)
Check SSL

Я предлагаю использовать именно этот чекер по двум причинам. Во-первых, предоставляемая им информация не перегружена техническими подробностями, для понимания которых требуется наличие соответствующих знаний, во-вторых, он позволяет посмотреть, как установлены такие же сертификаты, как у Вас, на других сайтах и быстрее заметить недочеты, которые могли возникнуть при установке Вашего сертификата. Для просмотра указанного списка сайтов, достаточно нажать кнопку Write review of НазваниеПоставщикаВашегоСертификата на странице с результатами проверки.
После устранения проблем, связанных с установкой сертификата, имеет смысл выяснить актуальность используемого набора шифров. Для ее примерной оценки вполне подойдет браузер Chrome для Android. Если открыть в нем сайт, а затем щелкнуть по зеленому замочку в левой части адресной строки, будет отображено окно с сообщением Используется современный/устаревший набор шифров и сведениях об алгоритмах шифрования, аутентификации и обмена ключами. Если Вас не устроит полученная информация, придется договариваться с хостером об изменении настроек (учтите, что оно возможно далеко не всегда).
Если сайт успешно прошел перечисленные этапы тестирования, можно с большой уверенностью сказать, что сертификат установлен корректно, и успокоиться. В тех случаях, когда стандарты шифрования должны соответствовать жестким требованиям, понадобятся более сложные инструменты анализа, такие как Symantec SSL Toolbox и Qualys SSL Labs SSL Server Test. К сожалению, для их эффективного применения требуется не только наличие определенных знаний в сфере технологий шифрования, но и изучение таких «занимательных» документов, как SSL and TLS Deployment Best Practices.

Поддержка протокола HTTPS, которая меня расстроила

Во время перевода этого сайта на протокол HTTPS, я пользовался услугами HTS.ru. Переход выполнялся по рассмотренному выше сценарию, включающему покупку и подключение выделенного IP-адреса, а также установку сертификата службой поддержки. Если все, что связано с выделенным IP-адресом, не вызвало проблем, то обещанная «установка сертификата, предоставленного в любом формате, в течение часа» завершилась только с четвертой попытки и заняла больше половины суток, а, самое главное, не дала тот результат, который я ожидал. Как выглядели эти попытки, и что получилось в результате?
«Веселье» началось с того, что я сообщил службе поддержки о своем намерении включить протокол HTTPS и поинтересовался, можно ли прислать сертификат в формате PKCS12. Мне быстро дали утвердительный ответ, я отправил pfx-файл, и начал ждать, когда сайт будет доступен по протоколу HTTPS.
 Попытка №1 завершилась, даже не начавшись, потому что службе поддержки не понравился сертификат в предварительно согласованном формате PKCS12. Меня попросили прислать сертификат и закрытый ключ в виде отдельных файлов. Я воспользовался командой Certificate»Separate PFX утилиты StartCom Tool и отправил запрошенные файлы, не придав никакого значения третьему выгруженному файлу, представляющему из себя цепочку сертификатов промежуточных центров сертификации в формате PEM. Я думал, что служба поддержки хорошо знает, что делает, поэтому не стал умничать давать какие-либо советы.
 Попытка №2 завершилась быстро и дала первый «результат» — сайт стал доступен по протоколу HTTPS. Я изменил необходимые параметры WordPress (этой процедуре будет посвящена отдельная статья), и в левой части адресной строки браузера появился тот самый зеленый замочек. Казалось бы, осталось убедиться в корректности установки сертификата и успокоиться, но описанный выше чекер отобразил более чем унылый результат проверки:

SSL-сертификат не является доверенным во всех браузерах

Сообщение, выделенное красным цветом, во-первых, обозначает, что сертификат не является доверенным во всех браузерах, во-вторых, предлагает попробовать установить сертификат промежуточного центра сертификации или цепочку сертификатов промежуточных центров сертификации для связи сертификата сервера с доверенным корневым сертификатом, в-третьих, содержит ссылки на более подробное описание проблемы и инструкцию по установке сертификатов StartCom на используемую серверную платформу. Проблема выявлена, решение предложено, остается только гадать, почему служба поддержки не проверила результаты «выполненной» работы и не попыталась устранить собственные ошибки, пока их еще не заметил клиент. Впрочем, решение организационных вопросов должно беспокоить руководителей службы поддержки, а я вернусь к сообщению об ошибке. Содержащаяся в нем фраза cert chain заставила меня вспомнить про цепочку сертификатов доверенных центров сертификации, извлеченную из .pfx-файла. Я отправил в службу поддержки очередное сообщение, содержащее .pem-файл и ссылку на результат проверки корректности установки сертификата, а затем опять приступил к ожиданию.
 Попытка №3 не заняла много времени и дала второй «результат», выглядящий не так уныло, как прежде, но все еще очень далекий от ожидаемого:

Один из SSL-сертификатов использует устаревшую подпись SHA1

Сообщение, выделенное красным цветом, обозначает, что один из сертификатов использует устаревший алгоритм подписи SHA1. Очередная ошибка, и новый набор рекомендаций по ее устранению, а служба поддержки опять ничего не проверила и, соответственно, не исправила, да еще и прекратила отвечать на мои сообщения. Я расстроился окончательно, позвонил в службу поддержки, меня вежливо попросили еще раз написать, что мне нужно, приложить к сообщению все упомянутые в переписке файлы и подождать полчаса. В этот раз я отправил, во-первых, ссылки на соответствующие инструкции для Apache (на всякий случай) и NGINX (именно он используется в качестве фронтенда), во-вторых, ссылки на результаты проверки корректности установки сертификата как на моем сайте, так и на сайте с аналогичным сертификатом, установленным прямыми руками без ошибок, и, наконец, в-третьих, .crt-/.key-/.pem-файлы. После подготовки очередной «просьбы» я приступил к ожиданию результата, для достижения которого опять не хватило ни получаса, ни часа, ни двух часов.
 Попытка №4 заняла приблизительно восемь часов. Мне стало известно, что все готово, только на следующее утро. Я предполагаю, что мою заявку наконец-то передали сотруднику, который умеет устанавливать сертификаты, и только после его вмешательства все заработало как положено:

SSL-сертификат установлен корректно

Я сомневаюсь, что описанный случай способен удивить моих коллег, которым в силу профессии приходится находить общий язык со службами поддержки банков, провайдеров, хостеров и других организаций, при этом мне страшно думать о том, как подобное мероприятие может повлиять на психику далекого от IT человека, который обзавелся сертификатом и решил перевести свой сайт на протокол HTTPS. Вам уже стало грустно? А ведь это еще не все!
Во-первых, Google очень оперативно выявил факт корявой установки сертификата и уже на следующее утро сообщил о нем в Google Search Console:

Google считает SSL-сертификат просроченным

Во-вторых, в результате щелчка по зеленому замочку в адресной строке браузера Chrome для Android я увидел вот такое сообщение:

Соединение зашифровано с помощью устаревшего набор шифров

Я поинтересовался, когда наборы шифров станут современными, и почему нигде не написано, что в настоящий момент они устаревшие. Мне ответили, что после запланированного на ближайшие месяцы обновления программного обеспечения все придет в норму, при этом вторая часть вопроса «не была услышана».
Вот, собственно, и вся поддержка протокола HTTPS, с которой я столкнулся, будучи клиентом HTS.ru. Я уверен, что перечисленные «мелочи» не сильно повлияли на любительский сайт, созданный ради прикола для экспериментов, но неприятный осадок оставался вплоть до «переезда» на другой хостинг

Поддержка протокола HTTPS, которая меня порадовала

После прочтения предыдущей части моего повествования у Вас может сложиться впечатление, что переход на протокол HTTPS является сложной процедурой, для выполнения которой нужны не только некоторые знания в сфере IT, но и отчетливые склонности к садомазохизму. На самом деле, все зависит от организации управлением сертификатами на хостинге и компетентности службы поддержки. Например, я был удивлен грамотной организацией управления сертификатами на хостинге Beget, благодаря которой у меня не возникло необходимости обращаться в службу поддержки. В отличие от HTS.ru, в случае Beget для установки имеющегося сертификата достаточно перейти в раздел Домены, выбрать собственный домен и выполнить команду Управление SSL-сертификатами (щелкнуть по щиту с надписью SSL), на открывшейся странице перейти на вторую закладку Установка SSL сертификата, вставить в поле Сертификат текст сертификата (содержимое файла ИмяДомена.zip\NginxServer.zip\1_ИмяДомена_bundle.crt), в поле Приватный ключ — текст закрытого ключа, полученного с помощью утилиты StartCom Tool, выбрать Домен, выбрать или приобрести новый Выделенный IP, а затем нажать кнопку Установить:

Самостоятельная установка сертификата на хостинге Beget

Через несколько минут все будет готово, чекер покажет примерно такой результат проверки корректности установки сертификата:

Результат самостоятельной установки сертификата на хостинге Beget

А щелчок по зеленому замочку в адресной строке Chrome для Android приведет к отображению примерно такого сообщения:

Соединение зашифровано с помощью современного набор шифров

Как видите, все делается более чем просто, почти не требует времени и дает результат, к которому очень сложно придраться

Заключение

Данная статья ни в коем случае не должна рассматриваться как антиреклама HTS.ru или пиар Beget. Здесь рассказано только о том, с чем столкнулся я, и с чем можете столкнуться (а можете не столкнуться) Вы. Раньше я не знал, во что может вылиться добавление пары строчек в файл конфигурации NGINX. Теперь знаю, и советую Вам не бояться менять хостинг, пока не будет найдено оптимальное соотношение цены и качества услуг. Например, данный сайт совершенно спокойно перенес два переезда, при этом каждый следующий хостинг оказывался заметно лучше предыдущего. На сегодняшний день меня полностью устраивает Beget, а что будет завтра, я еще не знаю. Верьте в лучшее, но не расслабляйтесь, и обязательно оставляйте комментарии об особенностях поддержки протокола HTTPS на используемых Вами хостингах. Я уверен, что собранная информация сильно поможет другим читателям.

Понравилась статья?

 Подпишитесь на RSS или почтовую рассылку;

 Присоединяйтесь в Twitter, Facebook, Google+, VK;

 Поделитесь ссылкой в социальной сети или блоге:

8 комментариев к “Разное качество поддержки протокола HTTPS на разных хостингах

  1. Спасибо за вашу статью. Учтем и исправим в срочном порядке, думаем, что к октябрю у нас все будет работать в автоматическом режиме!

    • На здоровье! Если Ваша служба поддержки будет брать пример с PR-отдела, никто и никогда не напишет ничего подобного 😉

  2. недостаточной распространенностью технологии Server Name Indication (SNI), позволяющей применять один IP-адрес для нескольких HTTPS-серверов

    Лолшто? SNI давно поддерживается всеми актуальными браузерами, поисковиками и софтом, не поддерживает его разве что IE6 на XP, но кому он нужен?

    • 1. IE8 на XP его тоже не поддерживает, а пользователей с таким компьютерами еще достаточно много.
      2. Хостеры хотят зарабатывать больше, поэтому вместо SNI предлагают купить выделенный IP-адрес.

      «Лол», напишите названия хостингов, на которых включают HTTPS без покупки выделенного IP-адреса 😉

  3. Очень полезная информация!
    Я-то думала, что, раз зелёный замочек, то всё ок:))
    А оказывается…:))
    Спасибо за ссылку на чекер. Всё зелёное, значит, с сайтом порядок.
    Вопрос: не знаете ли Вы, где и каким образом можно приобрести сертификат для сайта с IDN-доменом?
    Пишут, это сложнее, чем для обычных доменных имён на латинице.
    И ещё вопрос: влияет ли переход на показатели сайта, не может ли он стать причиной снижения посещаемости?
    Насколько желательно и насколько срочно стоит переводить сайты на https?
    Благодарю:)

    • Всё зелёное, значит, с сайтом порядок.

      Не совсем так. Все зеленое в SSL Checker от SSL Shopper говорит только о том, что сертификат установлен корректно. После устранения ошибок установки сертификата желательно проверить сайт в SSL Server Test от Qualys SSL Labs. Кроме всего прочего, этот чекер покажет список устройств и браузеров, которые смогут отображать сайт. Вполне возможно, часть Ваших посетителей со старыми браузерами не сможет зайти на сайт после его перевода на HTTPS.

      Вопрос: не знаете ли Вы, где и каким образом можно приобрести сертификат для сайта с IDN-доменом?

      Сейчас я использую дешевый платный сертификат Comodo Positive SSL, купленный здесь (дешевле, вроде бы, нет). Этот сертификат поддерживает IDN.

      И ещё вопрос: влияет ли переход на показатели сайта, не может ли он стать причиной снижения посещаемости?

      Не может, а станет. Например, я перевел сайт на HTTPS в середине июня прошлого года, а посещаемость так и не вернулась на прежний уровень.

      Насколько желательно и насколько срочно стоит переводить сайты на https?

      Если Вы не принимаете платежи и не обрабатываете персональные данные, не стоит торопиться. За слово «Надежный» и зеленый замочек придется заплатить потерей 20-30% посетителей. Еще никто не доказал на реальном примере, что перевод сайта на HTTPS дал какие-то плюсы, при этом разговоров про минусы все больше и больше.

  4. Благодарю за развёрнутый ответ!
    Вы подтвердили мои смутные догадки, что ситуация не так однозначна, как представляется 🙂
    Прочитав, что с 2017 года Google Chrome помечает сайты без SSL-сертификатов как небезопасные, я решила постепенно переводить свои, но не могла добиться от знакомых вебмастеров точной информации, так ли уж это необходимо. Вернее, все утверждали, что нужно, но меня одолевали сомнения.
    А так как конфиденциальные данные я не обрабатываю, то и спешить теперь с этим не стану.

    • с 2017 года Google Chrome помечает сайты без SSL-сертификатов как небезопасные

      Этот вброс создали SEOшники, которые неправильно перевели соответствующий пост Google. На самом деле, в указанном документе четко сказано, что с 01.01.2017 года Chrome будет помечать HTTP-сайты, требующие ввод паролей или номеров кредитных карт как небезопасные, а в долгосрочной перспективе это коснется всех HTTP-сайтов. При этом нет никаких пояснений по поводу того, что подразумевается под долгосрочной перспективой.

      Вернее, все утверждали, что нужно, но меня одолевали сомнения.

      Я тоже видел множество подобных утверждений без каких-либо объяснений. Конечно же, какие-то «объяснения» есть, но они звучат слишком невнятно: «враг» не перехватит трафик, Google будет выше ранжировать и т.д. и .т.п. При этом советчики обычно «забывают», что ссылки, накопленные годами, станут редиректными (имеющими меньший вес), склейка зеркал займет много времени (точно не две недели и даже не два месяца), ну и, как я уже сказал, часть посетителей просто не сможет зайти на сайт.

      А так как конфиденциальные данные я не обрабатываю, то и спешить теперь с этим не стану.

      Это правильно. Прежде чем наступит «долгосрочная перспектива», Google многократно предупредит вебмастеров.

Оставить комментарий