Что нужно чтобы получить? Что такое центр сертификации. Как работает SSL-сертификат

Многие задавали себе вопрос, чем различаются разные SSL-сертификаты, зачем его получать и почему нельзя использовать самоподписанный.

Здесь я попытаюсь ответить на эти вопросы, рассмотрев:

  • Причемущества от наличия SSL вообще, и подписанного сертификата в частности.
  • Типы SSL-сертификатов.
  • Пути их получения.

Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте:)

SSL - Secure Sockets Layer - стандарт передачи защифрованных данных через сеть. Касательно web-индустрии это протокол HTTPS .

О сертификатах вообще и зачем их нужно подписывать.

Для начала разберемся, что такое SSL -сертификат.

Здесь и далее речь пойдет приемущественно о web-сайтах. Вопросы SSL + FTP, Email, цифровых подписей исходного кода и пр. до поры оставим в стороне.

SSL-сертификат, это индивидуальная цифровая подпись вашего домена. Он может быть:

  1. Самоподписанным. Это значит, что вы сами выдали себе сертификат, и сами его подписали.
  2. Подписанный недоверенным центром сертификации. Это значит, что сертификат сайта проверен, но сам «проверяющий» доверия не удостоен.
  3. Подписанный доверенным ЦС. Это значит, что данные сертификата проверены компанией, которая имеет на это право, они как минимум существуют.

Разберем их более подробно.

Самоподписанный сертификат не гарантирует ничего. Любой человек может взять и выдать себе такой сертификат. Все браузеры выдают клиенту предпреждение о том, что сертификат не надежен.
Подписанный не доверенным ЦС сертификат тоже не подтверждает ничего, т.к. существуют ЦС, продающие сертификаты всем желающим и без проверок. Большинство браузеров реагирует на такие сертификаты аналогично самоподписанным.

Сертификат, подписанный доверенным источником (как пример - Thawte или VerySign) подтверждает, что:

  • Данный сайт действительно принадлежит компании, за которую себя выдает, а не Васе-фишеру из соседнего подъезда.
  • Компания, которую представляет сайт - действительно существует в жизни, а не в мыслях Васи из соседнего подъезда.
  • Данные этой компании проверены и зарегистрированы центром сертификации.

На доверенные сертификаты браузеры ошибку не выдают.

Но это технически. А теперь о том, что показывает доверенный сертификат посетителю вашего сайта.

  • Это действительно тот сайт, на который мы шли, а не дефейс или фишинг.
  • Сайт создан в серьез и надолго. В общем случае, желающие «поиграть недельку» не готовы выложить деньги за сертификат.
  • Сайт принадлежит компании, либо зарегистрированному физ. лицу, а не неведомому анониму. Плюсы понятны - желающие обмануть или украсть редко стремятся удостоверить свою личность.
  • Компанию волнует защищенность информации и подтверждение своей подлинности.
  • Если что-то случится, эту компанию можно найти через сертификатора.

Многих пользователей (особенно зарубежных - наши пока к этому не привыкли) самоподписанный сертификат (или отсутствие SSL в вещах, касающихся услуг\финансов\privacy) может если и не отпугнуть, то поставить жирный минус в вашу пользу.

Мой личный вывод: на всех сайтах, связанных с онлайн-коммерцией, платежами, личной информацией SSL должен быть.

Типы сертификатов.

Допустим, руководствуясь соображениями из 1 части статьи вы решили купить подписанный сертификат. Каково же будет ваше удивление, когда на сайте ЦС вы узнаеете, что они бывают разные:)

Типы сертификатов:

Esential SSL - самый не дорогой и быстро оформляемый сертификат. Доступен как для юридических, так и для физических лиц. Проверяется только право владения доменным именем, личные данные или регистрация компании не проверяются. Выдается на 1 домен.

Instant SSL - доступен и для физ. лиц, и для юр. лиц. Проверяется право владения доменом, регистрационные данные компании либо личность физ. лица. Выдается на 1 домен.

SGC SSL-сертификат. - Аналогично Instant SSL, но с поддержкой 40-битных расширений (актуально для старых ОС и браузеров). Выдается на 1 домен, либо wildcard (см. ниже).

Обычный Wildcard. - тоже самое, что и обычный сертификат, но выдается не на 1 домен, а на все поддомены корневого домена. Т.е. не только на domain.com, a и на www.domain.com , bill.domain.com и т.д. Стоит на порядок дороже.

EV (Extended Validation) сертификат. - сертификат расширенной проверки, доступен только юридическим лицам. Проверяется владение доменом, компания, нотариально заверенные переводы документов на английский язык, требует подтверждения данных третьей стороной. Позволяет установить на сайте картинку-подтверждение владением и отображается в браузерах как гарантированно доверенный (зеленым цветом), против желтого у обычных сертификатов. Стоит в 2-3 раза дороже обычного, регистрация занимает продолжительное время.

В браузере выглядит так:

EV Wildcard и EV SGC. - аналогично Wildcard и SGC, но с расширенной проверкой.

Instant и Essential сертификаты позиционируются как продукт для сайтов частных лиц и органзаций, не связанных с электронной коммерцией.
Extended Validation - для сайтов, связанных с финансами, услугами (интернет-банкинг, платежные системы, интернет-магазины и пр.).

В следующей статье я напишу, как выбрать регистратора и получить сертификат.

Что такое HTTPS?

Все наши запросы в Интернете представляют собой обмен данными. Информация от пользователя к серверу и обратно поступает по открытому протоколу передачи данных HTTP (HyperText Transfer Protocol). Он лежит в основе работы сети. Однако у HTTP есть недостаток — отсутствие защиты шифрованием. Из-за этого личная информация пользователей (пароли, номера банковских карт, паспортные данные) может быть украдена третьими лицами. Для защиты информации был внедрён HTTPS — протокол безопасного соединения.

При работе по HTTPS браузер пользователя и сервер обмениваются ключами. Сервер также отправляет сертификат, подтверждающий, что он является именно тем сервером, к которому обращался пользователь. Браузер устанавливает подлинность ключа . Если ключ не подделан, браузер пользователя и сервер доверяют друг другу и выбирают шифр на одну сессию (один сеанс обмена запросами и ответами), чтобы исключить возможность вмешательства третьих лиц.

Для чего нужен SSL-сертификат?

Чтобы ваш сайт работал по протоколу HТТPS, необходимо установить SSL-сертификат безопасности . После установки сертификата данные, которыми пользователи обмениваются с сервером, будут надёжно защищены от третьих лиц специальными ключами шифрования.

Все популярные браузеры поддерживают шифрованное соединение. Чтобы узнать, работает ли сайт по HTTPS, присмотритесь к URL в адресной строке. Если адрес начинается с https:// и перед ним отображается зелёный замок, разработчик сайта позаботился о безопасности пользовательских данных:

Где применяется HTTPS?

В настоящее время использование протокола HTTPS — признак хорошего тона. HTTPS демонстрирует посетителям сайта, что они могут без опасений оставлять на нём личную информацию и совершать транзакции. Также он служит для SEO-продвижения проекта — позволяет занять более высокую позицию в поисковой выдаче. Поисковые системы (Google, Яндекс и пр.) дорожат доверием аудитории и выше ранжируют сайты, которые работают через безопасное соединение.

  • электронные платёжные системы и сайты магазинов;
  • социальные сети и сайты, на которых пользователи оставляют личную информацию;
  • ресурсы, для которых важна статусность.

Установка SSL-сертификата на сайт гарантирует:

  • подлинность соответствия ресурса подписям в сертификате, что положительно сказывается на уровне доверия посетителей к вашему сайту;
  • целостность передаваемой информации. На время передачи информации от сервера к браузеру гарантируется отсутствие изменений или потерь данных;
  • конфиденциальность . За счёт использования 256-разрядного шифрования данных информация, передаваемая между вашим сервером и браузером посетителя, недоступна для просмотра и изменения посторонним лицам.

Как перейти с HTTP на HTTPS?

Если ваш сайт обслуживается на хостинге сайт, выполните следующие шаги:

  1. 1 Закажите SSL-сертификат или подключите бесплатный SSL-сертификат при регистрации домена или услуги хостинга в сайт. Подробнее о заказе SSL читайте в разделе .
  2. 2 Активируйте сертификат по соответствующей инструкции из раздела

SSL (Secure Sockets Layer - уровень защищенных сокетов) представляет собой криптографический протокол, который обеспечивает защищенную передачу информации в Интернете.

Чаще всего протокол SSL используется с самым распространенным протоколом передачи гипертекста – http. О наличии защищенного соединения свидетельствует суффикс «s» – протокол будет называться https. Стандартный порт http – 80, а https – 443.

Протокол SSL используется в тех случаях, если нужно обеспечить должный уровень защиты информации, которую пользователь передает серверу. На некоторые сайты, которые работают с электронными деньгами (банки, Интернет-магазины, биржи контента), передаются секретные данные. Кроме пароля, это может быть номер и серия паспорта, номер кредитной карты, пин-код и др. Такая информация предоставляет большой интерес для злоумышленников, поэтому если вы используете для передачи незащищенный протокол http, то ваши данные вполне можно перехватить и использовать в корыстных целях. Для предотвращения перехвата секретных сведений компанией Netscape Communications был создан протокол SSL.


Протокол Secure Sockets Layer позволяет передавать зашифрованную информацию по незасекреченным каналам, обеспечивая надежный обмен между двумя приложениями, работающими удаленно. Протокол состоит из нескольких слоев. Первый слой – это транспортный протокол TCP, обеспечивающий формирование пакета и непосредственную передачу данных по сети. Второй слой – это защитный SSL Record Protocol. При защищенной передаче данных эти два слоя являются обязательными, формируя некое ядро SSL, на которое в дальнейшем накладываются другие слои. Например, это может быть SSL Handshake Protocol, позволяющий устанавливать соответствие между ключами и алгоритмами шифрования. Для усиления защиты передаваемой информации на SSL могут накладываться другие слои.


Для шифрования данных используются криптографические ключи различной степени сложности – 40-, 56- и 128-битные. Показатель количества бит отражает стойкость применяемого шифра, его надежность. Наименее надежными являются 40-битные ключи, так как методом прямого перебора их можно расшифровать в течение 24 часов. В стандартном браузере Internet Explorer по умолчанию используются 40- и 56-битные ключи. Если же информация, передаваемая пользователями, слишком важна, то используется 128-битное шифрование. 128-битные криптографические ключи предусмотрены только для версий, поставляемых в США и Канаду. Для того, чтобы обеспечить надежную защиту, вам следует загрузить дополнительный пакет безопасности - security pack.


Для передачи данных с помощью SSL на сервере необходимо наличие SSL-сертификата, который содержит сведения о владельце ключа, центре сертификации, данные об открытом ключе (назначение, сфера действия и т. д.). Сервер может требовать от пользователя предоставления клиентского сертификата, если это предусматривает используемый способ авторизации пользователя.


При использовании сертификата SSL сервер и клиент обмениваются приветственными сообщениями инициализации, содержащими сведения о версии протокола, идентификаторе сессии, способе шифрования и сжатия. Далее сервер отсылает клиенту сертификат или ключевое сообщение, при необходимости требует клиентский сертификат. После нескольких операций происходит окончательное уточнение алгоритма и ключей, отправка сервером финального сообщения и, наконец, обмен секретными данными. Такой процесс идентификации может занимать немало времени, поэтому при повторном соединении обычно используется идентификатор сессии предыдущего соединения.


Нельзя не отметить независимость протокола от программ и платформ, на которых используется SSL, так как этот протокол работает по принципу переносимости. В приложениях заключается основная угроза безопасности передаваемых данных. Это наличие уязвимостей в браузерах.

Таким образом, в настоящее время протокол SSL получил широкое распространение в сети Интернет, так как он обеспечивает достаточно высокий уровень защиты передаваемой между приложениями информации.

Бимал Шах, Айя Загуль, IBM

Безопасность данных в открытых информационных сетях, таких как Интернет, всегда будет источником серьезного беспокойства для разработчиков и клиентов. Поэтому для любого используемого продукта крайне важно создать безопасную среду исполнения.

Протокол SSL (Secure Socket Layers - протокол защищенных сокетов), совместно разработанный Netscape Communications и RSA Data Security, позволяет эффективно обеспечить такую безопасность. Протокол SSL обеспечивает безопасность, аутентификацию на базе сертификатов и согласование безопасности по установленному сетевому соединению, поэтому множество компаний и продуктов приняли SSL в качестве коммуникационного протокола.

В этой серии мы сконцентрируемся на двух главных аспектах:

  1. подробная информация о схеме работы SSL;
  2. детальная информация о поддержке SSL в версиях 5.1 и 6.0.1 среды ISC.

В данной статье исследуется SSL и объясняется, почему его рекомендуется реализовать в среде ISC. Во второй и третьей частях этой серии будет представлена подробная пошаговая инструкция по реализации и подключению SSL к ISC 5.1 и 6.0.1.

Реализация протокола SSL, используемая в WebSphere® Application Server, хранит персональные сертификаты в файле ключей SSL и сертификаты издателя в файле со списком доверенных источников. Файл ключей содержит коллекцию сертификатов, каждый из которых может быть представлен во время установки SSL соединения для подтверждения подлинности. В файле со списком доверенных источников хранится коллекция сертификатов, которые считаются достоверными и с которыми будет сравниваться представленный сертификат во время установки SSL-соединения для проверки подлинности.

Хорошим примером реализации протокола SSL является его поддержка в IBM WebSphere Application Server. Система безопасности этого сервера имеет многоуровневую архитектуру, показанную на рисунке 2.




Уровень сетевой безопасности обеспечивает аутентификацию на транспортном уровне, целостность и шифрование сообщений. Коммуникации между различными серверами WebSphere Application Server могут быть сконфигурированы на использование протоколов SSL и HTTPS. Для дополнительной защиты сообщений также можно использовать протоколы IP Security и VPN (Virtual Private Network - виртуальная частная сеть).

Протокол SSL обеспечивает безопасность на транспортном уровне: аутентификацию, целостность и конфиденциальность для безопасного соединения между клиентом и сервером в WebSphere Application Server. Этот протокол работает поверх TCP/IP и под прикладными протоколами, такими как HTTP, LDAP, IIOP, обеспечивая достоверность и секретность передаваемых данных. В зависимости от конфигурации SSL на клиенте и сервере могут быть установлены различные уровни достоверности, целостности данных и секретности. Понимание основ функционирования протокола SSL очень важно для правильной настройки и достижения требуемого уровня защиты для данных клиента и приложения.

Некоторые функции безопасности, предоставляемые протоколом SSL:

  • Шифрование данных с целью предотвратить раскрытие конфиденциальных данных во время передачи.
  • Подписывание данных с целью предотвратить несанкционированное изменение данных во время передачи.
  • Аутентификация клиента и сервера, позволяющая убедиться, что общение ведется с соответствующим человеком или компьютером.

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

Протокол SSL используется различными компонентами внутри WebSphere Application Server для обеспечения достоверности и конфиденциальности. К этим компонентам относятся: встроенный HTTP-транспорт, ORB и безопасный LDAP-клиент.

Реализация SSL, используемая в WebSphere Application Server, - это либо расширение для Java - IBM Java™ Secure Sockets Extension (IBM JSSE), либо IBM System SSL. Провайдер IBM JSSE содержит эталонную реализацию, поддерживающую протоколы SSL и TLS (Transport Layer Security - безопасность транспортного уровня) и API для интеграции. С провайдером IBM JSSE также поставляется стандартный провайдер, предоставляющий поддержку RSA для функциональности цифровой подписи из библиотеки JCA (Java Cryptography Architecture - Архитектура Шифрования для Java) для платформы Java 2, стандартные наборы шифров для SSL и TLS, менеджеров доверенных источников сертификатов и ключей, использующих технологию X509, и реализацию технологии PKCS12 для хранилища цифровых сертификатов JCA.

Конфигурация провайдера JSSE очень похожа на конфигурацию большинства других реализаций SSL, например GSKit, однако пару отличий следует выделить:

  • Провайдер JSSE поддерживает хранение собственного сертификата и сертификатов издателя в файле ключей SSL, но он также поддерживает и отдельный файл, т.н. файл источников сертификатов (trust file). Этот файл может содержать только сертификаты источников. Можно поместить свои собственные сертификаты в файл ключей SSL, а сертификаты издателей - в trust-файл. Это может потребоваться, например, при наличии недорогого аппаратного криптографического устройства, у которого памяти достаточно только для хранения персонального сертификата. В этом случае файл ключей указывает на аппаратное устройство, а trust-файл указывает на файл на диске, содержащий все сертификаты издателей.
  • Провайдер JSSE не распознает специальный формат файла ключей SSL, используемый плагином - файлы с расширением.kdb. Провайдер JSSE распознает только стандартные форматы файлов, такие как Java Key Store (JKS - хранилище ключей Java). Совместное использование файлов ключей SSL плагином и сервером приложений невозможно. Более того, для управления ключами сервера приложений и trust-файлами необходимо использовать различные реализации утилиты управления ключами.

SSL и Integrated Solutions Console

Приложение ISC - это единая среда Web-консолей администрирования для развертывания и интеграции консольных модулей, позволяющая заказчикам управлять решениями, а не конкретными продуктами IBM. Эта среда включает в себя контейнер портлетов, Java-компоненты (JMX) для управления приложениями и модули справки Eclipse.

Для реализации конфиденциальности и шифрования можно использовать протокол SSL. С помощью SSL можно защитить взаимодействие между Web-браузером пользователя и сервером ISC. Шифрование важно потому, что в ISC используется аутентификация, основанная на формах; при этом идентификатор и пароль пользователя для входа в систему не шифруются при пересылке по сети. Если консольному модулю требуется доступ к внутренним ресурсам через безопасное соединение, его портлеты могут использовать SSL.

Какие преимущества дает использование SSL?

Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам - это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей. В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе - крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.

В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.

Я сам долгое время не понимал, что такое SSL сертификат, и почему мне так срочно нужно переносить свой сайт с http на https. Но все вокруг твердили, что переезжать надо обязательно, иначе – каюк.

Тогда я решил самостоятельно разобраться, что же это такое, и зачем оно нужно. Результаты моих исследований вы найдете ниже.

И знаете что? SSL сертификаты – это одна из главных веб-мистификаций последних лет. И вполне серьезная угроза для всех интернет-пользователей.

Что такое SSL сертификат самыми простыми словами

Вспомните, как часто происходит дело в шпионских детективах. Нам нужно отправить послание сообщнику в другую страну, и нам очень не хочется, чтобы враги перехватили наше послание и прочитали его.

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

Мой сообщник получает письмо с цифрами «137-536-9978», берет свой томик Стругацких, и в обратной последовательности расшифровывает мое послание. Понятно, что даже если письмо будет перехвачено по дороге – никто не поймет, что там написано, потому что только мы с сообщником знаем, какую именно книгу мы используем для шифрования.

Вот и SSL протокол работает схожим образом. Только вы с сообщником каждого нового письма используете новую книгу. Кроме того, ваши книги – уникальны. То есть, нигде в мире больше нет ни одного экземпляра этой книги – только у вас и у сообщника.

Ну и, плюс ко всему, письмо вы отправляете не «Почтой России», а привязываете его к лапе самого быстрого ястреба, который летит от вас прямо по нужному адресу, и скорее погибнет, чем даст кому-то забрать у него ваше письмо.

Вы – это ваш сайт. Ваш сообщник – это ваш хостер-провайдер. Сообщение, которое вы передаете – это любая информация, которую пользователи вводят у вас на сайте – номера банковских карточек, пароли, емейлы и прочее. Быстрый ястреб-камикадзе – это прямой цифровой туннель для сообщения между вашим сайтом и сервером.

Такая работа через «уникальные книги» называется «SSL протоколом». А чтобы иметь возможность работать через этот протокол – вам надо сначала получить SSL сертификат. Это своеобразное удостоверение личности вашего сайта в интернете.

Можно ли взломать SSL протокол?

Теоретически, взломать можно даже эту сложную систему шифрования. То и дело на разных конференциях зачитываются доклады о том, как можно перехватывать сообщения по SSL, и как можно их расшифровывать.

Но на практике все эти способы либо очень сложные, либо очень долгие. То есть на расшифровку одной «буквы» послания может уйти до 2-3 часов времени. Естественно, такая «расшифровка» не сможет применяться для реального воровства ваших данных. И до сих пор SSL протокол считается «невзламываемым».

Но вот другой вопрос. Означает ли это, что ваш сайт и ваши данные в безопасности? Как ни удивительно, но вовсе не означает.

В чем главная опасность SSL сертификата?

То, что вы используете уникальные книги для шифрования, не значит, что злоумышленник не может притаиться где-нибудь на втором этаже вашего дома. В бинокль он увидит все, что вы пишите на листочке бумаги, и ему не придется даже ничего расшифровывать – он считает сообщение еще до того, как оно будет хитро зашифровано.

Точно так же и с сайтами. Наличие «https» у сайта не гарантирует, что на этом сайте нет вирусов или вредоносных программ. Такие программы могут считывать все, что вы вводите в поля платежной формы.

Кроме того, получить SSL сертификат сегодня очень просто. Самый распространенный вариант – это сертификат для подтверждения домена (так называемые DV – Domain Validation). То есть для его получения достаточно подтвердить, что у вас есть доступ к емейлу, на который зарегистрирован домен, вот и все. Никто не проверяет, что это за сайт, какой деятельностью он занимается, нет ли на нем вирусов.

Соответственно, любой хакер может сделать сайт, купить для него SSL (или даже взять бесплатный, их сейчас хватает) – и собирать ваши данные себе в копилку. Да, на его сервер они попадут в безопасности. Но куда они отправятся оттуда? Вопрос открытый.

И главной опасностью всей этой истории с SSL я считаю то, что у рядовых пользователей возникает ложное ощущение безопасности (либо наоборот — опасности), когда они видят, что сайт на https-протоколе (либо наоборот – на обычном «http»).

А масла в огонь подливает мой любимый Гугл.

Мол, и сайты-то без «https» мы будем помечать как «небезопасные» (читай – «мошеннические» с точки зрения пользователей), и как сигнал для SEO-ранжирования это включим. И все вебмастера в срочном порядке бросились переходить на SSL. Вот тут-то и открылась вся страшная правда.

Далеко не для всех сайтов SSL одинаково полезен. А во многих случаях даже вреден.

Нужен ли SSL сертификат для вашего сайта?

Если вы собираете важные личные данные посетителей сайта – такие как номера банковских карточек – то однозначно да. Вам обязательно нужно установить SSL протокол на свой сайт. Вы обязаны максимально обеспечить безопасностей людей на вашем ресурсе, иначе вы станете невольным пособником злоумышленников.

Вопрос в другом – надо ли вам заморачиваться со всеми этими сертификатами, если у вас не интернет-магазин, а обычный блог или информационный сайт? Принесет это вам какую-то пользу или наоборот? Да, к сожалению, может быть и наоборот.

Давайте я приведу здесь ТОП-3 мифов про SSL-сертификаты, которые распространены среди веб-мастеров.

Миф #1 – Гугл пометит мой сайт страшным красным значком, и все посетители с него убегут

На самом деле, Гугл давно стращает веб-мастеров тем, что в новой версии браузера Google Chrome все сайты без https будут помечаться как «небезопасные». Сначала они хотели ввести это в 53 версии своего браузера, потом в 58, потом в 62… Сейчас у меня установлена уже 63 версия Гугл Хром, и вот, что я вижу, когда открываю через него свой сайт (который работает на обычном «http»).

Вместо обещанного страшного красного значка висит круглый значок «i», который означает, что тут можно прочитать какую-то информацию. И если кликнуть по этому значку, тогда открывается сообщение, что подключение к сайту не защищено, и тут не надо оставлять личные данные.

То есть ничего страшного не показывается. А вдруг они начнут показывать «страшное» чуть позже, в 64 или 164 версии Хрома? Не начнут. Я в этом уверен по следующим причинам:

  1. Гугл Хром помечает красными значками только те страницы, на которых есть реальные формы для ввода каких-то данных, а эти страницы не защищена SSL;
  2. Гугл Хром показывает предупреждение «Не защищено», только когда вы начинаете вводить свои данные в форму. До этого момента она висит безо всяких предупреждений;
  3. Если Гугл вдруг разом начнет запугивать посетителей обычных сайтов, то они на самом деле разбегутся. То есть Гугл потеряет всю свою поисковую выдачу, которую любовно выстраивал в течение многих лет. Это однозначно негативно скажется на качестве поисковой выдачи, и тогда пользователи разбегутся уже от самого Гугла (подтверждение моих слов смотрите чуть ниже).

То есть, другими словами, пока вы не собираете важные личные данные людей – Хрому нет никакого дела до того, на каком протоколе вы работаете.

Миф #2 – Гугл ставит выше в поиске сайты на https

Именно благодаря этому мифу во многом SSL-протокол получил такое широкое распространение. Веб-мастера вообще любят простые решения. Им сразу понравилась идея, что можно просто переехать на защищенный протокол, и тогда их сайты сразу «попрут» в гору. Не надо работать над качеством ресурса, не надо создавать ценный контент. Здорово же.

На самом деле, https нисколько не влияет на поисковую выдачу (по крайней мере в положительную сторону). Если отбросить весь треп, который стоит вокруг этой темы, и обратиться к первоисточнику (то есть к самому Гуглу), то мы увидим следующее.

В 2014 году Гугл потряс сообщество веб-мастеров сообщением о том, что теперь SSL будет учитываться как сигнал ранжирования. То есть буквально – сайты с SSL будут иметь приоритет при прочих равных.

Однако, влияние данного фактора будет очень незначительным – менее 1% от совокупности всех факторов ранжирования (а их у Гугла уже тысячи). Конечно, они пообещали, что далее вес данного фактора будет только увеличиваться и… замолкли на целых три года.

Официальных сообщений на эту тему больше не поступало. Сайты переезжали на https и дружно со свистом вылетали из индекса, а потом с большим трудом туда возвращались (хорошо, если вообще удавалось вернуть все свои позиции). А Гугл молчал.

В конце концов, в апреле 2017 году он объявил, что не намерен увеличивать вес данного фактора ранжирования. Перевод переписки между сотрудником Moz и представителем поиска Гугла на скриншоте ниже:

— Сейчас по нашим данным почти 50% сайтов в ТОПе Гугла используют SSL. Планируете ли вы дальше усиливать ранжирование в пользу защищенных сайтов?»

— Нет, мы рассмотрели эту идею несколько месяцев назад, и решили отказаться от неё»

Иначе говоря, для Гугла это был эксперимент – улучшится ли качество поисковой выдачи благодаря влиянию https или нет. Не улучшилась (и в самом деле, с чего бы?) Соответственно, от эксперимента отказались.

В качестве еще одного доказательства своей точки зрения я могу привести вам пример выдачи гугла по запросу «контент план».

Как вы видите сами, в ТОП-5 выдачи только один сайт имеет https протокол. И стоит он только на 4 месте. Все остальные сайты (включая мой на второй позиции) работают на обычном http, что нисколько им не мешает продвигаться.

При чем, обратите внимание, на https работает очень крупный и известный ресурс в нашей нише — Texterra. У этого сайта намного больше страниц, чем у меня, над ним трудится целая армия авторов и контент-менеджеров (а я пишу один), и этот сайт почти в два раза старше моего. То есть тут даже не «прочие равные». И если «https» — такой крутой фактор ранжирования, так поставьте его на первое место.

Но такого почему-то не происходит. Наверное, потому что для выхода на первые места одного SSL все-таки недостаточно.

Миф #3 – Переезд на SSL – это быстро и безопасно

На самом деле, это очень опасно и совсем не быстро. Если вы переезжаете с «http» на «https», то с точки зрения поисковых систем появляется абсолютно новый сайт. Вся его история обнуляется, все страницы надо заново индексировать, и выбирать им место в поиске.

А поисковые системы очень не любят, когда что-то так резко меняется на сайте. Гугл приводит список «best practice» переездов на https (то есть список кейсов, где переезд закончился удачнее всего). И знаете, какой результат считается самым успешным? Когда в течение 2-3 месяцев удается вернуть себе весь или почти весь трафик, который был до переезда.

То есть ни о каком качественном прорыве речи даже не идет. И никакой пользы в плане выдачи вы не получите.

А вот навредить своему сайту и себе можете очень даже запросто. Дело в том, что переезд на SSL – дело довольно тонкое. Если вы настроите что-то немножко не так, то ваш сайт вообще полностью вылетит из индекса очень надолго.

Например, вы можете неправильно настроить работу двух версий сайта – http и https, и тогда абсолютно на всех страницах будет выскакивать огромное предупреждение во весь экран – «Этот сайт небезопасен! Не удалось проверить сертификат! Немедленно уходим!»

Или вы можете «забыть» переделать ваши внутренние ссылки на сайте. Ведь после переезда они перестанут работать, соответственно вес сайта будет распределяться неправильно.

Или могут заблокировать организацию, которая выдала вам SSL сертификат. Тут уже не будет никакой вашей вины. Заблокировать сертификатора может даже Роскомнадзор за какую-нибудь провинность. И тогда ваш сертификат «обнулится», и опять «на дворе мочало – начинай с начала».

Резюмируем так: если у вас обычный блог или информационный сайт, то переезд на SSL ТОЧНО не принесет вам никакой пользы и выгоды, и ТОЧНО нанесет вам временный ущерб (а в половине случаев – постоянный ущерб).

Отсюда еще один интересный вопрос, чтобы закончить тему. Если SSL – это такая мутная штука, которая непонятно как выстрелит – почему тогда вокруг столько шума о необходимости немедленного переезда на https?

Кому выгодно, чтобы у вас был SSL?

Как всегда, если какая-то мистификация получает широкое распространение – значит есть те, кому это выгодно.

В нашем случае это многочисленные хостер-провайдеры, которые сразу почуяли запах денег. Одно дело – брать с вас деньги каждый год только за хостинг, а другое – еще и за SSL сертификат. Естественно они будут уверять всех и вся, что SSL – это жизненная необходимость. Вон, мол, сам Гугл это подтверждает.

Мне часто пишут вебмастера с вопросами про этот SSL. И говорят, что впали в паническое состояние после какой-нибудь веб-конференции, где им рассказывали про преимущества SSL. После пары вопросов всегда выясняется, что данный доклад делали представители компании, которая как раз занимается продажами SSL-сертификатов. Кто бы мог подумать.

Тут я не могу удержаться и не показать вам одно видео от компании, занимающейся продажами SSL. Это просто шедевр трэш-контента =) И по этому видео прекрасно видно, как такие хостинг-провайдеры относятся к своим клиентам – как к безмозглым животным))

Заключение

Конечно, только вам решать, нужен вам SSL сертификат или нет. Я могу только кратко резюмировать:

  • SSL – действительно хороший способ шифрования, который пока на практике никому не удалось взломать;
  • Наличие SSL сертификата не гарантирует, что сайт безопасен. На нем могут быть вирусы и вредоносные программы, которые перехватывают данные до отправки на сервер;
  • Если вы занимаетесь электронной коммерцией, то вам обязательно надо ставить SSL сертификат (либо для совершения транзакций отправлять посетителей на сторонний защищенный ресурс платежной системы, как это делаю, например, я);
  • Гугл не помечает сайт без SSL как «небезопасные», и не будет этого делать, потому что так он навредит сам себе;
  • Наличие SSL никак не влияет на положение в поисковой выдаче вашего сайта;
  • При переезде с «http» на «https» очень высока вероятность где-нибудь ошибиться, и тогда ваш сайт может вообще никогда до конца не восстановить свои позиции;
  • Больше всего паники среди вебмастеров наводят хостер-провайдеры, потому что они зарабатывают деньги на продаже SSL-сертификатов.

Другими словами – если у вас новый сайт и вам нечего терять, то вы можете спокойно сразу сделать его на https. Главное купите его у надежного провайдера. А то поставщиков разных бесплатных SSL скорее заблокируют, и вам тогда будет очень плохо.

А если у вас ресурс уже раскручен и вы не принимаете платежи непосредственно на сайте – скорее всего он вам и даром не нужен. Пишите статьи и выходите в ТОП без него. А можете просто использовать отдельный сайт на «https» для приема платежей.

Надеюсь, статья была для вас полезной. Не забудьте скачать мою книгу . Там я показываю вам самый быстрый путь с нуля до первого миллиона в интернете (выжимка из личного опыта за 10 лет =)

До скорого!

Ваш Дмитрий Новосёлов