Переезд с http на https в Веб-окружении 1С-Битрикс. Битрикс на https
Переезд с http на https в Веб-окружении 1С-Битрикс
В последнее время очень участились запросы на настройку сайтов на https-защиту.
Для специалиста в администрировании серверов это простое дело, а вот для всех остальных, данный процесс может быть очень даже не простым. Попробую в общих чертах обрисовать процесс добавления сертификата для сайта, размещенного на виртуальной машине 1С-Битрикс (для варианта, когда сайт установлен как дополнительный для веб-окружения).
Перед началом работ по переносу сайта с http на https убедитесь, что у вас на сайте отсутствуют абсолютные ссылки. Чаще всего такое встречается в текстах, которые прописывают контент-менеджеры - они обычно тексты пишут в каком-то текстовом процессоре, а потом просто копируют в редактор. При этом ссылки все остаются с указанием протокола и домена. Тут нужно или глазами просматривать, или писать скрипт проверки - все индивидуально.
Для начала получаем сертификат. Где вы будете брать сертификат и какой лучше выбрать - это оставлю за кадром - в сети очень много информации по данному вопросу. Для установки SSL в nginx потребуются следующие файлы: коренвой сертификат (root), сертификат посредника (intermediate) и непосредственно сам сертификат для домена.
Перейдем сразу к процессу создания сертификата. Будем считать, что вы выбрали обычный сертификат с проверкой одного домена.
Итак, вы начинаете генерацию сертификата. На первом же шаге система вам генерирует ключ (обычно он показывается в простом текстовом поле и подразумевается само собой, что вы должны его скопировать себе и сохранить). Это ваш секретный ключик, который нужно! сохранить - без него все, что дальше - бесполезно!
На основании этого, сохраненного вами ключа будет сгенерирован сертификат для вашего домена (или доменов), который, скорей всего, будет выслан вам на контактный e-mail, но, возможно, также будет и ссылка на скачивание прямо в панели.
Будем считать, что ключик у вас уже есть (самое главное, есть личный ключ, который сохраняем в виде: domain_ru.key). Нас интересуют всего 2 файла: domain_ru.crt и domain_ru.key.
Авторизуемся в веб-окружении под root-пользователем. Создаем папку:
mkdir ~/sertsВ данную папку заливаем наши файлы с сертификатом.
Дальше, эти 2 файла нужно объединить в один общий:
cat domain_ru.key domain_ru.crt domain_ru.ca-bundle >> domain.ru.pemdomain_ru.ca-bundle - цепочка сертификатов от сервера лицензий. Более подробно про то, какие сертификаты объединять, можно почитать тут
И копируем полученный файл в список сертификатов сервера:
cp domain.ru.pem /etc/nginx/ssl/domain.ru.pemДальше нужно изменить файл сертификата
/etc/nginx/bx/site_avaliable/bx_ext_ssl_domain.ru.conf(если сайт заведен в веб-окружении как основной, править нужно файлы /etc/nginx/bx/site_avaliable/ssl.s1.conf и /etc/nginx/bx/site_avaliable/s1.conf)
В файл /etc/nginx/bx/site_avaliable/bx_ext_ssl_domain.ru.conf необходимо включить наши файлы сертификата.
Для этого комментируем строчку include bx/conf/ssl.conf; (вставляем впереди нее #) а вместо нее вставляем содержимое файла /etc/nginx/bx/conf/ssl.conf
Во вставленном коде, необходимо указать наши ssl-сертификаты:
ssl_certificate /etc/nginx/ssl/domain.ru.pem ssl_certificate_key /etc/nginx/ssl/domain.ru.pemСохраняем файл и проверяем конфигурацию на отсутствие ошибок:
nginx-tДальше, нам нужно настроить, чтобы сайт был доступен только по https. Для этого открываем файл:
/etc/nginx/bx/site_avaliable/bx_ext_ssl_domain.ru.confВ данном файле после блока
server_name domain.ru www.domain.ruпишем:
if ($scheme = http) { return 301 https://$server_name$request_uri; }Еще раз проверяем конфигурацию nginx и перезагружаем nginx. Если все было сделано верно - вы получите корректно настроенный 301-й редирект с http на https с установленным для домена сертификатом.
Для проверки корректности установки сертификата вы можете воспользоваться сервисом.
Как видите, данный процесс не такой уж и сложный. Далее не забудьте изменить адрес sitemap.xml и хост в robots.txt, а также изменить протокол для адресов в генераторе вашей карты сайта (если, конечно, ваш генератор карты не делает этого сам. К примеру, мой генератор карты сайта, построенный на основе модуля поиска определяет протокол автоматически).
Update 2017-02-02. Шпаргалка по SSL-сертификатам:
Запрос на выдачу сертификата и приватный ключ удобно генерировать в Онлайн CSR Генератор .
Основные цепочки сертификатов:
Comodo Essential SSL:
cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundleComodo Essential SSL\PositiveSSL:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundleRapidSSL
cat ServerCertificate.cer CACertificate-1.cer CACertificate-2.cer > yourDomain.ca-bundleСервис от Qualys SSL Labs представляет очень подробную техничесткую информацию о настройке ssl на Вашем сайте.
Update 2018-07-10. Замечательное видео о выпуске сертификата:
Инструкция на сайте ssl.com.ua..
Update 2018-07-13. Как искать http://
Если ваш сайт переежает с http на https - первое, что вы должны сделать - это избавиться от всех http:// ссылок.
Процесс перехода состоит вообще из таких шагов:
- Необходимо заменить все внутренние абсолютные ссылки на относительные. К примеру, ссылку http://you.site/catalog/section/product/ нужно заменить на /catalog/section/product/ , т.е. ссылки без указания протокола и доменного имени. Заменить нужно том числе и все ссылки на медиаконтент (изображения, документы, видео, файлы стилей, файлы js-скриптов, подключение разных внешних сервисов).
- После переезда на https - нужно настроить 301-й редирект со старого протокола на новый, проверить, чтобы все ссылки на сайте имели корректный формат, все канонические ссылки были заменены, ссылки в карте сайта были заменеы
- Пройтись по разным типовым страницам сайта и проверить, чтобы адресная строка подсвечивалась зеленым цветом - если это так, то вы все сделали верно.
Но как же искать эти все http? Не просматривать же вручную все элементы инфоблока? Для поиска протокола в элементах инфоблоках можно отрыть в административном разделе сайта страницу Настройки - Инструменты - SQL-запрос и тут выполнить запрос:
В результате вы получите список из ID элементов и ID инфоблоков, в которых эти элементы лежат - остается только пройтись по этим элементам и внести правки.
Для поиска http-ссылок в файлах можно воспользоваться сервером (есил вам повезло и сайт у вас хотя бы на VPS и у вас есть ssh-доступ к файлам сайта). Переходим в корневую папку сайта и запускаем поиск по всем файлам, за исключением файлов ядра:
grep -inR "http://" --exclude-dir={bitrix,upload,1} --exclude={'*.xml','*.jpg','*.png','*.gif','*.log'} . > search_res.logВ результате, в корне сайта появится файл search_res.log, в котором будут перечислены все файлы, в которых нужно внести правки (из анализа будут исключены папки ядра, а также файлы с изображениями и логами). После этого можно аналогичный поиск прогнать в папке с шаблоном сайта, чтобы http-ссылок не осталось в шаблонах компонентов или, что еще хуже - в header.php и footer.php
pai-bx.com
преимущества HTTPS-сайта в 2017 году, санкции поиска Google и браузера Chrome, инструкция по переходу на HTTPS
Чем опасен протокол HTTP?
Протокол передачи гипертекста HTTP по умолчанию не содержит встроенных средств шифрования. Данные пользователей, которые передаются по этому протоколу, легко могут попасть в руки преступников. Даже простой вызов поисковика проходит 13 узлов, через всю Европу, до Америки и обратно. Применяя снифферские атаки или атаки посредника (man in the middle, MITM), киберпреступники перехватывают трафик и крадут незашифрованные пароли пользователей и номера банковских карт.
Маршрут трафика при вызове сайта Яндекс, данные сервиса Visual Trace Route Tool
Политика Google
Компания Google активно поддерживает распространение протокола безопасности HTTPS. Не только все сервисы Google работают на этом протоколе. С августа 2014 года поисковая система Google начала оценивать использование HTTPS как фактор ранжирования сайтов в выдаче. С декабря 2015 года поисковая машина Google в первую очередь индексирует страницы на HTTPS, отдавая им предпочтение перед аналогами на HTTP. В январе 2016 года инженер отдела качества поиска Гэри Илш (Gary Illyes) заявил, что страницы на HTTPS ранжируются выше, даже если реализованы с ошибками.
В декабре 2016 года Google предупредила, что начиная с января 2017 года браузер Chrome 56 будет уделять особое внимание сайтам с регистрационными формами. Те из них, кто передают данные пользователей по незащищенному протоколу HTTP, будут помечаться как небезопасные.
Предупреждение в группе Google Webmasters, соцсеть Google+
И поисковый гигант не обманул. С января 2017 года браузер Chrome помечает строчкой «Не защищено» всех, кто не озаботился перейти на HTTPS. А с вашим сайтом как дела?
Так пользователи браузера Chrome видят сайт «Билайн»
Chrome предупреждает
Как сейчас работает проверка Google Chrome? Браузер раздает «черные метки», ориентируясь на историю посещений. Проверьте сами: откройте Chrome, нажмите «Ctrl + H», и проверьте часто посещаемые сайты. Этим методом мы быстро нашли «черные метки» на сайте «Билайн», портале «Пикабу», поисковике «Нигма».
Причем формат предупреждения дифференцируется: недавние запросы к «Нигма» отмечаются строкой «Не защищено», а главная страница «Нигма» - скромным значком (i) на общих основаниях.
Часто посещаемые страницы первыми отмечаются строкой «Не защищено»
Это очень неприятная новость для тех, кто часто принимает платежи от постоянных клиентов. Сайты провайдеров мобильных услуг, интернета и хостинга, передающие персональные данные по HTTP, уже сейчас отмечаются в браузере Chrome строкой «Не защищено».
Остальные сайты на протоколе HTTP, в первую очередь с лид-формами, помечаются в браузере значком (i). Те, кто не поленятся кликнуть, увидят грозное предупреждение.
«Подключение к сайту не защищено. Не сообщайте этому сайту конфиденциальную информацию (например, пароли и номера банковских карт). К ней могут получить доступ злоумышленники».
Под эту раздачу попадает немало интернет-магазинов и львиная доля посадочных страниц. И всё! Не помогут ни дизайн, ни юзабилити, ни продающие тексты, ни А/В тестирование. Браузер предупреждает – прочь отсюда! Между тем по данным LiveInternet, в январе 2017 года браузером Chrome пользовались 55% пользователей. Больше половины аудитории.
Chrome предупреждает: не вводите пароль на сайте CITILINK.RU
В рейтинге RUWARD за 2016 год магазин CITILINK.RU занимает 3-е место. А Google все равно: на HTTP – значит, не пользуйтесь! И ведь кто-то непременно послушается, побоится фишинга и хакеров. В 2015 году CITILINK.RU отгрузил 2,8 миллионов заказов. Сколько из них он потеряет в 2017 году как «небезопасный»?
Переходить на HTTPS выгодно
Во-первых, протокол HTTPS защищает данные покупателей от сетевого перехвата. Сниффинг для грамотного программиста – азы ремесла, тысячи публикаций учат, как перехватывать трафик. Если же вашему клиенту обчистят банковский счет, он может и в суд подать. И в любом случае опозорит вас по друзьям, СМИ и соцсетям. Сам уйдет, других постоянных клиентов сагитирует, новых покупателей распугает. И будет прав.
Во-вторых, провайдеры не могут модифицировать вид HTTPS-сайта. А с HTTP-сайтами такой «фокус» проделывается легко. Даже операторы «большой тройки не стесняются так поступать. Скажем, в июле 2016 центральные СМИ возмущались баннерами «Мини-кабинет», которые «Билайн» размещал прямо поверх страниц их сайтов.
Провайдер связи может сделать с сайтом на HTTP все, что захочет
В-третьих, использование криптографического протокола TLS на базе SSL-сертификата позволит легко перейти на скоростной протокол HTTP/2. Основанный на разработанном Google протоколе SPDY («speedy» - «быстрый»), HTTP/2 ускоряет загрузку на 23-55%.
Как получить SSL-сертификат?
Переход на HTTPS начинается с получения ключей шифрования, или SSL-сертификата. Всего их 6 видов. В России только RU-CENTER выпускает сертификаты самостоятельно. Если вы работаете с другим провайдером хостинга, проще заказать сертификат через него.
Для посадочных страниц и малых предприятий подойдет SSL-сертификат с проверкой домена (Domain Validation). Доступен физическим лицам. Выдается после элементарной проверки: получатель ключа подтверждает права на домен, перейдя по ссылке в письме регистратора, либо разместив на хостинге домена текстовый файл, присланный регистратором. Большинство центров сертификации предоставляют вместе с SSL-сертификатом с проверкой домена статичный знак безопасности. Однако некоторые дают динамическую «печать доверия», ссылающуюся на страницу с подробными сведениями о сертификате. Сертификат выдается за 5-10 минут, стоит 1000 – 4000 рублей за год.
SSL-сертификаты с проверкой компании (Business Validation). Эти сертификаты выдаются после проверки документов. Надо будет отправить в центр сертификации выписку из ЕГРЮЛ или регистрационный номер ИНН/ ОГРН. Затем сотрудники центра делают контрольный звонок по указанному в документах телефонному номеру организации. Первый попавшийся номер указывать нельзя: он должен быть заверен DUNS, нотариусом или внесен в ЕГРЮЛ. Обыкновенно звонит англоязычный сотрудник центра. Если вы к этому не готовы, выбирайте центры Comodo или Thawte, у них есть русскоязычный персонал. Сертификат выпускается за 1-5 дней, и стоит от 4000 до 50000 рублей за год.
Банки, финансовые компании, холдинги подтверждают свою надежность, получая SSL-сертификаты с расширенной проверкой (Extended validation). Такой сайт очень просто отличить: перед адресом браузер выводит зелеными буквами название компании. Пример – личный кабинет Сбербанка, или ВТБ24.
«Зеленая строка» гарантирует: этот сайт принадлежит «Сбербанку»
Для получения этого сертификата тоже требуются выписка из ЕГРЮЛ или регистрационный номер ИНН/ ОГРН. Кроме того, существование организации проверяется по базам: Yell.ru, «Желтые страницы», D&B, KOMPASS.COM. Если предприятие существует менее 3-х лет, сертификат не выдается.
Валидация по телефону в этом случае двухэтапная. Сотрудник центра сертификации просит к телефону генерального директора (лицо, подписавшее договор), а потом начальника отдела кадров для подтверждения личности первого собеседника. Неудивительно, что многие предпочитают не связываться. Например, банк «Уралсиб» решил обойтись сертификатом с проверкой компании, как и «Юникредит». Сертификат выпускается за 3-10 дней и стоит от 10000 до 100000 за год.
Зачем нужен SSL-сертификат c поддержкой субдоменов (Wildcard)? Взять хотя бы вышеупомянутый Билайн. Он защищает шифрованием HTTPS только личный кабинет. Региональные версии не защищены, что вызывает потери клиентов. Региональных сайтов у оператора 288, и все на субдоменах (например, noyabrsk.beeline.ru). Покупать на каждый субдомен по сертификату нерационально, придется заключать 288 договоров, по всем вести переписку, отслеживать оплату, своевременно продлевать. Куда как проще купить 1 сертификат Wildcard для домена beeline.ru, и защитить сразу все настоящие и будущие субдомены. Сертификат может оформляться с проверкой только по домену, в течение 2-х суток. Стоит он от 7000 до 25000 рублей в год.
Мультидоменные SSL-сертификаты SAN (единые сертификаты связи, UCC) позволяют защищать сразу несколько полных доменов. Скажем, SAN сертификаты Symantec рассчитаны на 100 доменов, COMODO – до 250. Такой вариант подойдет крупному холдингу с множеством разнопрофильных предприятий. Сертификаты SAN специализированы для интранет, совместимы с платформами Microsoft Exchange 2007, 2010, 2013, 2016, Office Communications Server 2007, Microsoft Lync, Office 365. Мультидоменные SSL-сертификаты могут оформляться как с проверкой домена (до 1 суток), так и организации (до 5 суток). Стоимость – от 2000 до 90000 рублей за год.
Случается, что сайт работает с аудиторией, особо привязанной к родному языку. Например, русской, китайской, арабской. В таких ситуациях нужна защита данных в национальных (диакритических) кодировках. Ее обеспечивает опция поддержки IDN (Internationalized Domain Name). Некоторые сертификационные центры не выпускают таких сертификатов вообще, другие включают опцию поддержки IDN во все сертификаты подряд. Пример – линейка сертификатов COMODO или Symantec. Соответственно, сроки и стоимость варьируют в широких пределах.
На что еще обратить внимание при выборе SSL-сертификата? Во-первых, проверяйте количество перевыпусков. Это позволяет исправить ошибку, если при оформлении сертификата отправлены неверные сведения об организации. Большинство центров сертификации не ограничивают количество повторных попыток, но есть исключения. Для проверки качества крупные сертификаторы дают бесплатный тестовый период, можно потренироваться. Наконец, есть смысл учесть возможность возврата средств (moneyback), если сотрудничество с выбранным центром вас не устроило.
Для подготовки и проверки файлов CSR с данными организации используйте Symantec SSL Toolbox. А контролировать продление сертификата поможет SSL Checker.
Переход на HTTPS: исправляем ссылки
Создаем дубликат сайта и дальше работаем с ним. Прежде всего избавляемся от ссылок, использующих протокол HTTP. Все внутренние ссылки делаем относительными вне зависимости от протокола. Скажем, если ссылка была абсолютной и имела вид
http://example.com/jquery.js
то после исправления она должна выглядеть так
//example.com/jquery.js
Все внешние ссылки с протоколом HTTP проверяем. Если их содержание доступно по HTTPS – заменяем ссылку на относительную вне зависимости от протокола. Например, ссылка на Youtube должна выглядеть так:
//www.youtube.com/
А подключение библиотеки jQuery – так:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
Если содержимое внешней ссылки недоступно по HTTPS, переносим контент к себе на сервер и ссылаемся по внутренней ссылке. Так поступаем с изображениями, библиотеками, веб-шрифтами.
Особое внимание уделяем ссылкам с атрибутами rel=«canonical» (канонические версии страниц) и rel=«alternate» (для мобильных страниц и иноязычных версий). Проверяем файл карты сайта sitemap.xml, убеждаемся, что ссылки в нем используют протокол HTTPS.
По окончании проверки загружаем на новый дубликат сайта файлы сертификата и включаем протокол HTTPS. Для этого меняем конфигурацию веб-сервера (Apache, Nginx). Эту настройку сможет выполнить программист или системный администратор сайта, используя соответствующие инструкции.
Переход на HTTPS: проверяем ошибки настроек
После запуска протокола тестируем настройки SSL-сертификата. Сделать подробный анализ конфигурации SSL можно с помощью SSL Server Test от Qualys SSL Labs.
SSL-сертификат на сайте «Web Responsvie PRO» установлен корректно, уровень «А»
Если тест обнаруживает ошибки, исправляем их, и снова тестируем, пока не получим уровень «А». К примеру, сайт «Мегафона» оценивается на «F», уязвим к атакам DROWN, нуждается в подключении алгоритма шифрования SHA-2 и шифронаборов Perfect Forward Secrecy.
Настройки SSL-сертификата Мегафон небезопасны, уровень «F»
Обязательно загляните в отчет «Handshake Simulation», он показывает, как HTTPS-версия отображается на мобильных устройствах.
В файл robots.txt на HTTPS-версии сайта добавляем директиву, назначающую эту версию главным зеркалом сайта (yoursitename.ru – ваш домен)
Host: https://yoursitename.ru/
Не исключено, что HTTP-версия сайта когда-то попадала по санкции Google. Если для выхода из-под фильтров использовался инструмент отклонения внешних ссылок «Disavow links», непременно перенесите файл Disavow на HTTPS-версию.
Переход на HTTPS: склеиваем зеркала
Теперь, когда у нас есть два сайта-зеркала, сообщим о них поисковым машинам. Начнем с Google, поскольку это быстрее. Google по умолчанию ставит выше страницы и сайты на протоколе HTTPS. Достаточно добавить оба зеркала в Google Search Console и подтвердить права.
Затем переходим к Яндекс.Вебмастер. Добавляем оба ресурса и подтверждаем права собственности на них (мета-тегом, загружаемым файлом или DNS-записью). В разделе «Настройки индексирования» - «Переезд сайта» указываем «Добавить HTTPS» для домена, переезжающего на HTTPS.
Поставьте галочку, чтобы настроить HTTPS как предпочтительный протокол
Если вдруг HTTPS-дубликат сайта уже существовал и Яндекс считает его неглавным зеркалом, то придется расклеить зеркала вручную в Яндекс.Вебмастере. В том же разделе «Настройки индексирования» - «Переезд сайта». А затем склеить в правильном порядке, как описано выше.
Затем ждем, пока Яндекс запишет наши сайты как зеркала, с HTTPS в качестве главного зеркала. Через 2-3 недели Яндекс пришлет уведомление.
Уведомление в панели Яндекс Вебмастер
После этого трафик на главном зеркале начнет расти, а на неглавном падать. Следим за количеством проиндексированных страниц главного зеркала. Тем временем не забудем проверить, совпадают ли региональные настройки зеркал, если нет – пишем в техподдержку Яндекса. После того, как в индекс Яндекса попадут 90% страниц, придет пора настраивать переадресацию.
Организуем постраничный 301-й редирект с HTTP на HTTPS сайт. Проще всего это сделать через директивы в htaccess-файле:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://site.ru/$1 [R=301,L]
Проверка смешанного содержимого
После всех трудов браузер все равно может помечать некоторые страницы HTTPS-сайта как незащищенные. Причина в смешанном контенте. Страницы все еще загружают элементы по небезопасному протоколу HTTP. Скажем, www.usa.gov">сайтправительства США помечается значком (i), который при клике выдает диагностику «Подключение к сайту защищено не полностью».
Администратор сайта правительства США недоработал
Найти источник проблемы поможет инструментарий разработчика Chrome. Вызовем его сочетанием клавиш (Ctrl+Shift+I), перейдем на вкладку Security, и перезагрузим страницу, чтобы получить полный отчет.
Инструментарий разработчика Chrome помог найти ошибку
И увидим, что причиной незащищенности является смешанный контент (Mixed Content, по красной стрелке), источником которого является веб-форма, вызываемая по ссылке с HTTP (зеленая стрелка).
Чтобы не ковыряться с каждой страницей в отдельности, делайте пакетную проверку сайта с помощью программы ScreamingFrog SEO Spider.
Проблемы после переноса: проседание трафика
Трафика на новом HTTPS-сайте вначале не будет совсем. После переклейки зеркал и настройки переадресации он восстановится до привычных значений за пару недель. А через месяц после переноса вернется обнуленный тИЦ. Да, все небыстро, но так уж работает Яндекс и с этим ничего не поделаешь.
Проблемы после переноса: рекламные ссылки
Рекламные ссылки на сторонние ресурсы придется дорабатывать. По умолчанию при переходе по ссылке с HTTPS на HTTP заголовок-реферер не передается. Значит, счетчики сайтов-рекламодателей не смогут распознать источник трафика и запишут его в прямой. Потери рекламных контрактов? Нет.
Укажите сайту, что при переходе по ссылке надо передавать в заголовке протокол и домен. Для этого разместите в шапке между тегами <head></head> следующую команду
<meta name="referrer" content="origin">
Проблемы после переноса: счетчики Like
Счетчики социальных сетей после перехода на HTTPS обнуляются. У них учет простой: изменился протокол – значит, изменился адрес. А по новому адресу и статистика начинает собираться с нуля.
Facebook и Vkontakte со временем распознают совпадение домена, статистика лайков и шеров возвращается. Возможно, их примеру когда-нибудь последует Google+. А с потерей активностей Одноклассников, Twitter, Pinterest и Instagram придется смириться.
Чек-лист по переносу сайта на HTTPS от «1С-Битрикс»
8 декабря 2016 года вышла 17-я версия системы управления контентом «1С-Битрикс». Администраторам системы предлагается чек-лист по адресу «Рабочий стол» - «Магазины» - «Подготовить сайт к переходу на HTTPS». Инструкция краткая, но исчерпывающая.
Чек-лист по переходу на HTTPS в панели управления «1С-Битрикс» 17
Услуги «Web Responsvie PRO» по переносу сайтов на HTTPS
Ситуация получается напряженная. С одной стороны, ваш сайт на HTTP теряет клиентов по вине Google Chrome прямо сейчас. С другой стороны, переход сайта на HTTPS «в один клик» не сделать никак, требуется много часов квалифицированного труда. Если ваш программист перегружен срочной работой, компания «Web Responsvie PRO» предлагает помочь с переходом на HTTPS:
- Подобрать SSL-сертификат, соответствующий потребностям вашего бизнеса;
- Помочь получить сертификат: организовать переписку с центрами сертификации, подготовить CSR-файлы с «анкетными данными» вашей компании;
- Установить SSL-сертификат на ваш сервер;
- Настроить ваш сервер для работы по протоколу HTTPS;
- Протестировать ваш сайт, выявить и устранить небезопасные элементы;
- Оповестить о переходе вашего сайта на HTTPS поисковые системы Google и Яндекс в панелях управления Google Search Console и Яндекс Вебмастер;
- Настроить переадресацию с HTTP на HTTPS-версию сайта;
- Помогать консультациями в ходе переноса и в течение 1 месяца после него.
Работы по переносу потребуют от 3 дней чистого времени. Их стоимость составит не менее 10 000 рублей.
Компания «WRP». Золотой сертифицированный партнер «1С-Битрикс» с подтвержденными компетенциями «Композитный сайт», «Коробочная версия», «Интеграция с 1С». С 2006 года «WRP» внедрила более 80 проектов.
Откладывая перенос сайта на HTTPS, вы каждый день теряете покупателей. !
Дата публикации: 17 Февраля 2017
wrp.ru
Подключение SSL на Битрикс виртуальная машина, заметки по Битрикс на сайте camouf.ru
С первого января 2017 года, наличие безопасного соединения HTTPS становится практически обязательным. Ваши сайты будут занижаться в результатах поисковой выдачи, если используют не безопасные соединения. Рекомендую позаботиться об установке SSL сертификата на ваш сайт
Для некоторых сервисов, типа Яндекс Касса, требуется наличие SSL сертификата. То есть сайт должен без ошибок и предупреждений открываться по адресу https://ВАШ_САЙТ.ru. Если сайт запущен на виртуальном окружении от 1С битрикс, сделать это достаточно просто. Расскажу как.
Https на Битрикс веб окружении
Для начала получаем сертификаты у любой компании, это не принципиально. В итоге, после оформления заявки и оплаты сертификатов, получаем несколько файлов. Нас интересуют только: ВАШ_САЙТ_Root.crt, private.key и ВАШ_САЙТ.crt
Складываем все эти файлы в папку "serts", подключаемся к нашему серверу по SFT от имени root и закидываем папку "serts" в папку /root/
Подключаемся к серверу по SSH и выполняем команды:
cd /root/serts/ - заходим в папку cat ВАШ_САЙТ.crt ВАШ_САЙТ_Root.crt >> cert.pem - объединяем файлы сертификатов в pem cp /root/serts/cert.pem /etc/nginx/ssl/cert.pem - копируем pem в рабочую папку nginx cp /root/serts/private.key /etc/nginx/ssl/private.key - тоже самое делаем с файлом key
Далее открываем файл /etc/nginx/bx/conf/ssl.conf , можно через терминал или просто по SFTP и примерно, в 16 и 17-ю строки прописываем пути к нашим файлам сертификатов и ключа. Если там уже что-то прописано- то просто заменяем
ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/private.key;
И перезагружаем nginx командой
service nginx restart
На этом все. После перезагрузки, ваш сайт должен открываться по адресу https://ВАШ_САЙТ.ru без каких-либо уведомлений о возможной опасности
camouf.ru
Перевод сайта на https | www.bx-master.com
Перевод сайта на https
Зачем нужен защищенный протокол?
HTTPS – это не новый протокол. Это все тот же HTTP, работающий через шифрованные транспортные механизмы SSL и TLS.
Защищенный протокол соединения будет очень полезен вашему сайту, т.к. он обеспечивает:- - Проверку подлинности;
- - Шифрование;
- - Целостность данных.
Многие интересуются, зачем производить лишние манипуляции с сайтом, если он и без этих нововведений работал отлично. А ответ кровется в том, что если не перевести ваш интернет-ресурс на https, то сайт вскоре будет помечен как “небезопасный” и вы потеряете как доверие пользователя, так и преимущество при ранжировании сайта в поисковой системе.
Если проанализировать ТОП 10 сайтов в поисковой системе по любой тематике, то можно заметить, что почти все они переведены на https.
Как корректно перевести сайт на https?
1. Подготовить сайт к переходу на HTTPS:
- Изменить ссылки, используемые в проекте, с абсолютных на относительные.
- Проверить и изменить для контента (видео, картинки), загружаемого со сторонних ресурсов, протокол, по которому проект запрашивает контент.
- Изменить подключение внешних скриптов с абсолютных на относительные.
2. Установить SSL-сертификат:
- Выбрать и получить сертификат.
- Установить полученный сертификат на хостинг.
- Проверить доступность сайта через HTTPS-протокол.
3. Выполнить важные изменения на сайте:
- Установить директиву Host в файле robots.txt на протокол HTTPS.
- Установить 301 редирект со старого на защищенный протокол.
- Изменить ссылки в файле sitemap.xml.
4. Оповестить поисковики об изменениях:
- Добавить HTTPS-версию сайта в панель для вебмастеров Google Search Console.
- Изменить адрес в панели Яндекс Вебмастера и Google Search Console.
Скорее переводите свой сайт на защищенный протокол, пока можно получить от поисковых систем некие преимущества. Ведь поисковые системы в любом случае обяжут перевести ваш интернет-ресурс на https, но в будущем вы полезностей от ПС уже не получите, потому что защищенный протокол будет уже нормой и на нем будут все.
www.bx-master.com
Редирект https в Битрикс - это очень просто
С ребятами работаем уже 2 года. Отличная команда, отличный подбор программистов. Практически в любое время суток есть связь с руководителями. Критичные вопросы можно решить даже в 2 часа ночи (для нас как интернет-проекта это очень важно).
Время, когда начинали сотрудничество с Атлантом сейчас вспоминается с легкой ухмылкой. А тогда - все было очень плохо. Решили кардинально изменить сайт — старый "снести" и перейти на 1С-Битрикс.
Разработку сайта поручили фрилансеру. Он все сделал, сверстал сайт. Но прямо перед запуском у него случились какие-то трудности, 2 недели мы без связи. О нем ничего плохого сказать не могу, но - факт на лицо. Мы остались с недоработанной копией сайта (более 30 критичных доработок).
Как быть в такой ситуации - понятия не имели. Стали искать среди Золотых партнеров Битрикса, которые могли бы нам помочь в сложившейся ситуации. Написали порядка сотни запросов. Ответ от Атланта выделялся среди всех! Стоимость за работы оказалась одной из самых низких. Уверенность придавала пошаговая инструкция, что ребята собираются сделать с сайтом.
В итоге, запустили сайт, работаем с ними и ни разу не пожалели! В первые 6 месяцев после начала сотрудничества - у нас рост продаж в 2 раза. Ставим любые, даже самые сложные задачи. Все выполняется. Удобно, что все в одном месте: работы по сайту, 1С, хостинг, seo, дизайн и т.д. Рекомендуем!
Андрей Рудый ( Директор — LEDPremium )
atlant2010.ru
Https и многосайтовость Битрикс
Лебедев Димитрий 8(812)603-74-43 Россия, Санкт-Петеребург Димитрий Лебедев- 17.05.2017
- Комментариев: 1
- Интернет Магазин
Как то поймали такую ошибку: сайт с сертификатом SSL https://site_main.ru обращался ко второму адресу связанным через многосайтовость http://site_second.ru/bitrix/spread.php?s= и передавал второму сайт куки, за что получил от Google Merchant бан «Сбор и использование личной информации без обеспечения ее безопасности».
Мы работаем на 1С-Битрикс и у нас была организованная многосайтовость, сайты между собой передавали куки и авторизацию пользователей, и первый сайт подружил эту информацию от второго, незащищенного.
Решает проблема просто, снятием галочек которые стоят по умолчанию. Идем в настройки Главного модуля, Настройки -> Настройки продукта -> Настройки модулей -> Главный модуль, закладка Авторизация, ну или перейти по ссылке: ВАШ_САЙТ/bitrix/admin/settings.php?lang=ru&mid=main&mid_menu=1
Снимаем галочку Распространять авторизацию на все домены:
dimitrii.pro