Как найти протокол ssl

До 2014 года протокол HTTPS на сайтах встречался редко. Сегодня же это обязательный элемент сайта, влияющий как на ранжирование в поисковых системах, так и на доверие пользователей. В этой статье поговорим о протоколе HTTPS и расскажем, чем отличается HTTP от HTTPS и как перейти на сайт с HTTPS.

• Что такое HTTPS и чем он отличается от HTTP
• Зачем переводить сайт на HTTPS
• Как перевести сайт на HTTPS

Что такое HTTPS и чем он отличается от HTTP

Для начала давайте разберемся, зачем нужны протоколы передачи данных и в чем разница между HTTP и HTTPS.

Любой вбитый в поисковую строку запрос проходит путь от пользователя к серверу и обратно. Такая коммуникация возможна благодаря работе протокола HTTP (Hypertext Transfer Protocol).

Но у HTTP есть один недостаток — он не шифрует данные. Это означает, что злоумышленники смогут в любой момент перехватить реквизиты банковских карт, номера телефонов, email-адреса и другую личную информацию пользователей.

Чтобы уберечь эти данные от хакеров, был внедрен протокол HTTPS — это HyperText Transfer Protocol Secure, в переводе «защищенный протокол». В этом случае передача данных осуществляется по такому же принципу, что и в HTTP, но с криптографическим шифрованием, о чем говорит дополнительная буква «S».

Работает HTTPS протокол благодаря SSL/TLS-сертификату — это цифровая подпись сайта, подтверждающая подлинность ресурса.

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

Зачем переводить сайт на HTTPS

Здесь можно выделить несколько причин.

1. Безопасность. Как вы уже поняли, основная цель использования протокола HTTPS – защита персональных данных. Но отметим, что использование SSL-сертификата — не лекарство от всех бед. Учтите, что злоумышленники могут перехватить данные до момента передачи их на сервер, если компьютер или устройство клиента было заражено. Но всё же использование протокола шифрования — значительный вклад в снижение уязвимости сайта.
2. Доверие клиентов. Пользователи просто привыкли, что на сайтах крупных компаний можно увидеть надпись «защищено» или замок в адресной строке. Кроме того, посетитель страницы может кликнуть на иконку замка и узнать:

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

1. SEO-продвижение. Поддержка HTTPS-протокола — один из факторов ранжирования для многих поисковых систем. Об этом не раз писали Google и Яндекс. Если хотите активно заниматься продвижением в поисковиках, установка SSL-сертификата на сайт добавит вам несколько SEO-очков для сайта.
2. Дополнительные инструменты. Некоторые сервисы, например, Яндекс.Деньги, голосовой помощник Google Chrome или Google AdWords, можно подключить только к сайтам с сертификатом безопасности.
3. Закон. Существует федеральный закон №152 «О персональных данных». Согласно нему, если на вашем сайте собирается минимальная информация о клиентах (ФИО, email и др.), то он становится оператором персональных данных. Согласно закону, такие сайты должны соблюдать множество правил по защите данных своих клиентов, и переход на HTTPS — одно из них.

Теперь поговорим том, как перейти на защищенное соединение и настроить редирект с HTTP на HTTPS.

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

Переезд сайта на другой протокол выполняется за несколько шагов.

• Шаг 1. Выберите нужный тип SSL-сертификата
• Шаг 2. Активируйте сертификат
• Шаг 3. Установите SSL
• Шаг 4. Измените внутренние ссылки на относительные
  • Плагин Search Regex
  • Плагин Easy HTTPS Redirection
• Шаг 5. Настройте редирект на HTTPS
• Шаг 6. Оповестите поисковые системы о смене протокола
  • Для настройки в Яндекс.Вебмастере
  • Для настройки в Search Console
• Шаг 7. Проверяем правильность установки SSL-сертификата

Шаг 1. Выберите нужный тип SSL-сертификата

Для начала определитесь с типом SSL, который подойдет вашему сайту.
Сертификаты подразделяются по типу проверки данных:

• DV (Domain Validation) — базовый уровень сертификата, который обеспечивает только шифрование данных, но не подтверждает существование организации. Такие бюджетные сертификаты подойдут физическим и юридическим лицам.
• OV (Organization Validation) — обеспечивает не только шифрование данных, но и подтверждает существование организации. Такие сертификаты доступны только для юридических лиц.
• EV (Extended Validation) — это решение с самым высоким классом защиты, которое активно применяется в онлайн-бизнесе. Для оформления требуется пройти процедуру расширенной проверки, подтвердить законность организации и право собственности на домен.

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

• WildCard — защищает соединение с доменом и всеми его поддоменами.
• SAN — защищает домены по списку, указанному при получении SSL-сертификата.

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

Шаг 2. Активируйте сертификат

После покупки сертификат появится в списке услуг в личном кабинете.
Как же включить SSL:

• Если вы выбрали базовый сертификат (DV), делать что-то дополнительно не придется, потому что SSL активируется автоматически в течение 2-3 часов после покупки.
• Если вы приобрели OV и EV-сертификаты, подходящие только для юридических лиц, подождите от 3 до 7 дней. Процесс занимает большее количество времени, потому что Центр сертификации обязан проверить сведения о вашей организации или запросить их, если чего-то не хватает. Всё потому, что в случае с OV и EV компания подтверждает факт существования и все официальные каналы связи с ней, а ее владельцы — свои полномочия.

Шаг 3. Установите SSL

Когда вы получили на контактный email данные об активации SSL, можно переходить к установке сертификата.

Если вы приобрели сертификат не в SpaceWeb:

1. Откройте Панель управления.
2. Перейдите в SSL и нажмите Установить.
3. Далее в открывшемся списке выберите нужный IP-адрес, на который хотите установить сертификат.
4. Вставьте скопированный файл сертификата (подписанный публичный ключ) в первое поле, а приватный ключ — во второе.
5. Если сертификат подписан не напрямую, укажите файл с сертификатами промежуточных центров сертификации в последнем поле.

Если вы приобрели сертификат в SpaceWeb:

1. Откройте Панель управления.
2. После активации сертификата, перейдите в раздел SSL.
3. Привяжите его к IP-адресу, к которому привязан нужный домен.

Подробнее об установке SSL-сертификата читайте в этой статье.

Шаг 4. Измените внутренние ссылки на относительные

Внимание! Перед настройкой внутренних ссылок обязательно сделайте резервную копию.

Внутренние ссылки — страницы, с помощью которых вы перенаправляете пользователя на другие страницы вашего сайта. Например, https://sweb.ru/ — это основная ссылка, а https://sweb.ru/example/ — внутренняя.

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

Чтобы избежать потери трафика, измените ссылки на относительные — это ссылки, которые не содержат протокола и адреса сайта. Вместо них браузер подставляет адрес и протокол сайта, на котором находится пользователь. Например, https://sweb.ru/example/ — абсолютная ссылка (т.е. полный URL страницы), а /example/ — относительная.

Если вы используете WordPress, то изменить поправить ссылки можно с помощью плагинов, например, Search Regex и Easy HTTPS Redirection.

Плагин Search Regex:

1. Скачайте и установите плагин.
2. Перейдите в рубрику Инструменты ― Search Regex.
3. Для замены ссылок в строке поиска (Search) напишите старый URL с http://. В строку замены (Replace) введите новый URL с https://.
4. Чтобы проверить файлы сайта, в строке Source выберите нужные виды файлов.
5. Нажмите на Search.
6. Готово.

Плагин Easy HTTPS Redirection:

1. Скачайте и установите плагин.
2. Перейдите в раздел настроек и выберите HTTPS Redirection.
3. Поставьте галочку рядом с Enable automatic redirection to the «HTTPS».
4. В графе «Apply HTTPS redirection on» выберите The whole domain.
5. Поставьте галочку напротив Force resources to use HTTPS URL.
6. Готово.

Как только все файлы сайта будут работать по протоколу HTTPS, переходите к следующему шагу.

Шаг 5. Настройте редирект на HTTPS

Шаг 6. Оповестите поисковые системы о смене протокола

В этом шаге нужно будет работать со сторонними инструментами, такими как  Яндекс.Вебмастер или Google Search Console. Процедура перехода на HTTPS может занять от 2 до 4 недель. Если это критично для клиентов вашего бизнеса, выберите подходящее время.

Для настройки в Яндекс.Вебмастере:

1. Авторизуйтесь в Яндекс.Вебмастере.
2. Нажмите на плюс и добавьте новую версию сайта с HTTPS.

1. Если до этого вы использовали Яндекс.Вебмастер, подтвердите права на данный адрес любым предложенным способом. Нажмите Проверить:
2. После этого начните переезд сайта на HTTPS. Для этого перейдите в старое зеркало сайта. В разделе «Индексирование» ― «Переезд сайта» поставьте галочку Добавить HTTPS. Нажмите Сохранить.

Если вы подписаны на email-рассылку, Яндекс отправит письмо о том, что склейка зеркал сайта прошла успешно.

Для настройки в Search Console:

1. Авторизуйтесь в Google-аккаунте и добавьте ваш новый адрес с HTTPS.

1. Если до этого вы использовали инструмент, подтвердите право собственности на домен, добавив в их зону TXT-запись. Нажмите Подтвердить.
2. Добавьте новую карту сайта.
3. Если у вас есть отклоненные ссылки в Disavow Tool, то загрузите их заново.

Шаг 7. Проверяем правильность установки SSL-сертификата

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

1. Ввести новый адрес с HTTPS в поисковой строке. Если страница загружается, а в адресной строке появился замочек, значит, сайт стал доступен по HTTPS.
2. Воспользоваться специальными сервисами, например, sslshopper или globalsign.ssllabs. Если результат после проверки окажется положительным, значит, переезд сайта на HTTPS сделан правильно.

Готово! Вы разобрались, что такое HTTPS, в чем отличие HTTP от HTTPS, и узнали, как настроить переадресацию и перенести сайт на HTTPS.

Что такое HTTPS

Для того, чтобы объяснить, что такое HTTPS, обратимся к истокам.

Большая часть запросов в интернете проходит по протоколу HTTP. Его придумали еще в 90-х годах для передачи текстов с гиперссылками (документы, в которых вшиты ссылки для перехода к другим документам). Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol.

Сайт — это по сути своей документ, который состоит из файлов: текста, картинок, видео и так далее. При помощи HTTP браузер просит сервер отправить данные разного формата для отображения страницы.

Для того, чтобы его открыть, протокол HTTP подходил идеально. За исключением одного «но» — его использование не подразумевает шифрование данных. То есть, пока запрос идет от клиента (вас) к серверу и обратно, к информации о вас и о вашем запросе могут иметь доступ посторонние, например, интернет-провайдер или злоумышленники.

В целях повышения безопасности в интернете компания Netscape Communications в 2000-м году выпустила расширение протокола HTTP — HTTPS (HyperText Transfer Protocol Secure). При использовании HTTPS данные передаются поверх криптографических протоколов SSL или TLS и зашифровываются. Для того, чтобы сайт мог работать по протоколу HTTPS, на домен должен быть выпущен и установлен SSL-сертификат.

Что такое SSL/TLS

Перейдем к понятию SSL/TLS. SSL — это сертификат, который подтверждает подлинность веб-сайта. Аббревиатура переводится как Secure Sockets Layer.

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

Протокол SSL был выпущен более 25 лет назад компанией NetScape в нескольких версиях, но ни одна из них не могла полностью обеспечить безопасность данных пользователей. Поэтому в 1999 году компания IEFT создала новую версию сертификата — TLS (Transport Layer Security), которая смогла решить проблемы предшественника. Первые версии протокола сейчас не актуальны, но TLS-соединение 2008 и 2018 года все еще используются в наши дни.

Интересно, что компания IEFT не могла использовать в названии аббревиатуру SSL по юридическим причинам (права на имя принадлежали NetScape), но в обиходе мы до сих пор чаще используем именно название первого протокола.

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

Как работает SSL

SSL-сертификат позволяет установить TLS-соединение с сервером, которое работает по следующей схеме:

Все шаги для подключения по безопасному соединению занимают миллисекунды.

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

Чтобы проверить валидность сертификата вы можете воспользоваться онлайн-ресурсами. Например, с помощью инструмента «Проверка SSL» от 2IP.

Зачем нужен SSL

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

SSL играет роль и в SEO-оптимизации. Google и Яндекс учитывают наличие валидного сертификата и работу сайта по HTTPS как один из факторов ранжирования сайта в поисковой выдаче.

Если ваш сайт работает по HTTP, то рядом с адресной строкой браузеры выводят предупреждение «Не защищено», а значит пользователи будут меньше доверять вашему ресурсу.

Виды сертификатов

DV — Domain Validation — для подтверждения домена. Это значит, что сертификат подтверждает именно домен сайта, а не его владельца. Он показывает, что подключение защищено, и клиент обменивается зашифрованной информацией с сервером.

OV — Organization Validation — для подтверждения организации и домена. Он позволяет проверить не только домен, но и его владельца. Этот сертификат могут получить как физические, так и юридические лица. OV отлично подойдет для социальных сетей, форумов, интернет-магазинов или других ресурсов с приемом платежей.

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

Сертификаты всех указанных типов обеспечивают шифрование трафика между сайтом и браузером.

Бесплатный SSL-сертификат от Let’s Encrypt

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

Со временем ситуация изменилась. Появилась некоммерческая организация Let’s Encrypt, которая выпускает бесплатные SSL-сертификаты на сайты. Они подходят для небольших информационных сайтов, которые не собирают данные пользователей.

Бесплатный сертификат относится к типу DV (Domain Validation).

Сертификаты Let’s Encrypt отвечают современным стандартам качества: используется 256-битное шифрование симметричным ключом, центр Let’s Encrypt никогда не хранит закрытые ключи на своих серверах, а информация о сертификатах находится в публичном доступе.

Основной минус сертификата от Let’s Encrypt — его действие рассчитано на срок не более 90 дней. Затем его нужно перевыпускать. Сделать это можно как вручную, так и автоматически через планировщик задач Cron. Например у нас можно настроить автоматический перевыпуск сразу в панели. Если вам интересно, вы можете почитать об этом в нашей статье на сайте Beget.

Платный SSL-сертификат

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

Платные сертификаты бывают трех видов (DV, OV, EV).

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

Сертифицированные центры (CA)

Итак, если вы решили выпустить SSL-сертификат на ваш сайт, то вы можете обратиться к доверенным сертифицированным центрам (CA, Certification authority). Вот неполный список проверенных центров:

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

Выпуск SSL-сертификата через хостинг

Другой способ выпустить сертификат – обратиться к своему хостинг-провайдеру. Обычно хостинг-провайдеры становятся партнерами с сертифицированными центрами.

Выпуск сертификата у вашего провайдера значительно упрощает процесс, ведь вы можете заказать, установить и настроить его в одном окне.

Кликнув на иконку щита, вы перейдете на страницу для выпуска или установки сертификата.

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

Вот и все!

Несколько простых шагов и на вашем сайте установлен SSL-сертификат.

Настройка редиректа на HTTPS

Для того, чтобы ваш сайт работал только по безопасному соединению, вам необходимо настроить редирект страниц вашего сайта на HTTPS. Инструкции по его установке вы можете узнать у своего хостинг-провайдера. Например, в Beget в большинстве случаев вы можете настроить редирект на HTTPS одной кнопкой в Панели управления.

Если же ваш сайт работает через популярные CMS, такие как WordPress, Joomla или Bitrix, то настройка редиректа займет немного больше времени. Вам на помощь придут плагины и дополнительные инструкции.

2. Также вы можете воспользоваться этой инструкцией;

Такие инструкции существуют для всех популярных CMS. Найти вы их сможете в Google или Яндекс по запросу «mixed content» или «смешанное содержимое» с добавлением названия вашей CMS.

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

Основная установка и настройка будет проходить под Debian 8 Jessie, вебсервер NGINX, в бекенде Apache или PHP-FPM.
Инструментарий: Far Manager и Putty.
Команды вводятся в консоль SSH.
Если вы авторизованы не под root, добавляйте перед консольными командами sudo

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2014 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.

TLS (англ. Transport Layer Security — безопасность транспортного уровня) — криптографический протокол, обеспечивающий защищённую передачу данных от сервера к клиенту. TLS является потомком SSL 3.0. В основе работы лежат симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации и коды аутентичности сообщений для сохранения их целостности.

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

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

Почему нужно использовать SSL/TLS

Есть как минимум одна веская причина: вы не сможете воспользоваться преимуществами нового протокола HTTP2 (HTTP/2 приходит на смену текущему стандарту HTTP/1.1), если для вашего сайта не установлен и настроен сертификат безопасности SSL/TLS.

Также безопасность данных в интернете является всё более востребованной и актуальной темой. И чем дальше, тем больше: Google заявил, что наличие SSL-шифрования на сайте является положительным фактором в ранжировании сайта в поисковой выдаче. Также, наличие HTTPS является обязательным атрибутом для каждого e-commerce сайта: интернет-магазинов, сервисов по приёму платежей, обменников, а также платных сервисов, данные пользователей которых являются желанной добычей хакеров. Чтобы предотвратить фишинг-атаку на пользователя и не дать обмануть его, и нужно настроить SSL-сертификат безопасности и шифрования данных, чтобы он видел подтверждение того, что находится на правильном сайте.

Бесплатные сертификаты SSL/TLS от Let’s Encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

1. Они бесплатные;
2. Подойдут большинству проектов;
3. Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

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

Установка Certbot

Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.

Certbot — это утилита от Let’s Encrypt, помогающая в настройке SSL/TLS сертификата на сервер и его дальнейшем обновлении.

Установка Certbot в Debian 8 Jessie

Сначала убедимся, что certbot ещё не установлен:
certbot --help
Если увидите ошибку, значит, надо его установить.

Выбираем установку https://certbot.eff.org/#debianjessie-nginx

apt-get install certbot -t jessie-backports

Если вылезла ошибка The value 'jessie-backports' is invalid for APT::Default-Release as such a release is not available in the sources
, нужно настроить поддержку Backports

Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

Потом обновляете список пакетов:

apt-get update

и снова пробуете установить Certbot:

apt-get install certbot -t jessie-backports

Затем проверяете, как вышло

certbot --help

Установка Certbot в CentOS 7

Установка происходит так:

1. yum -y install yum-utils

2. yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

3. yum install certbot

Если у Вас CentOS 6, воспользуйтесь универсальной инструкцией ниже.

Универсальная инструкция по установке Certbot

1. Скачиваем Certbot:

   wget https://dl.eff.org/certbot-auto

2. Даём права на исполнение с помощью chmod

   chmod a+x certbot-auto

3. Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с certbot

   mv certbot-auto /usr/local/bin/certbot

4. Проверяем, что получилось:

   certbot --help

   Должы увидеть что-то подобное:
   

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду
certbot --help), советую заглянуть в cron-задачи

cd /etc/cron.d

В директории должен появиться файл certbot с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило && /etc/init.d/nginx reload вручную в конец строки.

В итоге, строка будет выглядеть примерно так:

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

Добавили, сохраняем.

Если строка в cron.d отстутствует, можно установить правило обновления сертификатов вручную:

1. Открываем расписание планировщика (сначала приведу пример для nano, затем для vim):

   crontab -e

2. Добавляем новое правило в конце планировщика:

   0 */12 * * * test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

3. Затем сохраняем (Ctrl+X , сохранить кнопкой Y)

Для vim то же самое, только при открытии планировщика нужно запустить режим редактора кнопкой Insert, внести правило для планировщика (см. выше), затем выйти из режима редактора кнопкой Esc, затем нажать комбинацию Shift + :(двоеточие), ввести буквы wq и нажать Enter, и новые правила для планировщика cron вступят в силу.

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt.
Staging Environment — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

• Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
• Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ --staging.
Например, так можно протестировать выдачу сертификата:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email [email protected] --agree-tos --staging

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

certbot renew --dry-run

А обновить все сертификаты на сервере вручную можно командой

certbot renew

После перезагрузите NGINX

nginx -s reload

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email [email protected] --agree-tos

• -w /var/www/example.com — путь до директории с файлами сайта
• -d example.com -d www.example.com — прописываем имена доменов
• --email [email protected] — ваш email, куда можно будет восстановить доступ
• --agree-tos — согласие с лицензионными требованиями

Если домен в кириллице, надо получить его Punnycode (например, яндекс.рф имеет код xn--d1acpjx3f.xn--p1ai) и пользоваться этим кодом. Сделать это можно с помощью Punycode-конвертера.

Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата

Итак, сертификат установлен в директорию /etc/letsencrypt/live/{тут_ваш_домен}/

Идём настраивать NGINX.

Настройка SSL, TLS в NGINX

Открываем конфигурационный файл вашего сайта.
Если NGINX настроен как тут, то конфигурационный файл может быть расположен тут:
/etc/nginx/vhosts/example.com.conf

Для уменьшения загрузки процессора официальная документация рекомендует

• установить число рабочих процессов равным числу процессоров,
• разрешить keep-alive соединения,
• включить разделяемый кэш сессий,
• выключить встроенный кэш сессий
• и, возможно, увеличить время жизни сессии (по умолчанию 5 минут):

Изменения я буду комментировать

# Создаём отдельный server для перенаправления с http на https
server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера
 rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https
}

# А это основной сервер с https
server {
  server_name example.com www.example.com;  # Копируем из верхнего сервера
  listen 1.2.3.4:443 ssl http2; #вместо 1.2.3.4 вставляете IP своего сервера. http2 включчает поддержку протокола http/2

  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # Сертификат
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # Ключ

  # Рекомендации по кешированию запросов
  keepalive_timeout   70; # 70 секунд держим соединение открытым
  keepalive_requests 150; # 150 запросов максимум на 1 соединение, после закрываем
  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  # А строки ниже - для усиления безопасности соединения
  ssl_prefer_server_ciphers on; # Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA; # Типы шифров
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Разрешённые типы протоколов

... # Тут остальные правила NGINX

Сохранили, проверили, перезагрузили

nginx -t && service nginx reload

Настройка SSL, TLS на WordPress

Для примера, возьмём сайт на WordPress и настроим на нём SSL/TLS, сделаем его доступным по HTTPS.
Нужно будет обязательно пройтись по списку и внести соответствующие изменения:

1. Переписать в базе данных все ссылки, заменив http://example.com на https://example.com
   Для этого, вы можете воспользоваться WP-Cli или специальной утилитой Seach Replace DB
2. Переписать в файлах темы все ссылки, заменив http:// на https:// или //
3. Отредактировать wp-config.php, а именно, перед define('WP_DEBUG', false); добавить:

   // example.com меняем на своё имя домена
   define('WP_HOME', 'https://example.com'); 
   define('WP_SITEURL', 'https://example.com');
   
   // Принудительная авторизация в админке по защищённому протоколу
   define('FORCE_SSL_ADMIN', true);
   
   // Чтобы предотвратить бесконечный редирект с http на https
   if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
          $_SERVER['HTTPS']='on';
   
   

   2 и 3 строки не обязательны, если выполнили первый пункт списка.

   Про последнее можно добавить, что если WordPress находится за проксирующим сервером с SSL, но хостится на сервере без SSL (то есть, как в нашем случае, SSL на NGINX, Apache без), запросы к страницам сайта будут создавать бесконечный цикл. Чтобы его предотвратить, и используется определение в заголовках HTTP_X_FORWARDED_PROTO, наличие https в котором и будет говорить о том, что в заголовки надо будет записать метку о том, что HTTPS включен, и она будет сигнализировать Вордпрессу о том, что мы работаем на https.
   Подробности можете посмотреть тут https://codex.wordpress.org/Administration_Over_SSL

Как перенести сайт с HTTP на HTTPS правильно

Я считаю, что можно не ждать склейки http и https, и сразу настроить редирект на https, они всё равно склеятся, но далее приведу рекомендации, которые дают специалисты по поисковому продвижению

Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил http и https версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в robots.txt нужный адрес в директиве Hosts.

Не забудьте добавить новую версию сайта на HTTPS в Яндекс Вебмастер и Google Webmasters.

Вот, скажем, пример файла robots.txt для сайта sheensay.ru

User-agent: Yandex
Disallow:
Host: https://sheensay.ru

User-agent: *
Disallow:

Sitemap: https://sheensay.ru/sitemap.xml

Далее, рекомендуется, чтобы все внутренние ссылки были относительными либо начинались строго с протокола https://. У всех внешних javascript скриптов, ссылок, вставленных картинок, аудио- и видеоплееров, и других внешних объектов протоколы http:// заменяются на абсолютные https:// или относительные //.
Приведу пример:

• НЕПРАВИЛЬНО: <img src="http://placehold.it/250x250">
• ПРАВИЛЬНО: <img src=»//placehold.it/250×250″>
• ПРАВИЛЬНО: <img src=»https://placehold.it/250×250″>

Далее, проверяем секцию head, ищем теги <rel rel canonical=""> и <rel rel alternate="">, и следим, чтобы адреса в них начинались с https://
Таким образом, вы добьётесь более быстрой склейки разных версий сайта в одну.

Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https

Как настроить 301 редирект с HTTP на HTTPS

Для NGINX мы настраивали редирект выше, поэтому если редирект настроили в нём, в Apache ничего не меняем. Но, для примера, покажу блок, ответственный за него

301 редирект с HTTP на HTTPS в NGINX

Тут нужно указать 2 блока server, для http (там мы настраиваем редирект) и для https

server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера
 rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https
}

server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:443 ssl; #где 1.2.3.4 - айпи вашего сервера
 ### Остальные правила
}

301 редирект с HTTP на HTTPS в .htaccess (Apache)

Если у Вас основной сервер Apache, в его конфигурационном файле (apache.conf) или в .htaccess в корне сайта прописываем

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:SSL} !=1 [NC]
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [L,R=301]

Или

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Эта конструкция отлавливает все запросы к портам, отличным от 443 (а именно на 443 порту сидит SSL), и редиректит на нужную версию сайта с HTTPS.

Если у вас во фронтенде NGINX, то редирект в .htaccess может и не сработать. В таком случае, рекомендую воспользоваться редиректом в WordPress.

301 редирект с HTTP на HTTPS в WordPress

Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта wp-config.php и прописать там в любом месте (если ещё не прописано, example.com меняете на свой домен):

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

В большинстве ситуаций этого достаточно.

Если доступа к wp-config.php нет, то есть ещё один вариант.
Код ниже используете в MU Plugin, также можно создать обычный плагин (требует активации) или вставить в functions.php рабочей темы:

<?php // Эту строку удалить, если код вставляется в существующий файл php

/**
  Plugin Name: Sheensay HTTP HTTPS Redirect
  Plugin URI: http://sheensay.ru/?p=2013
  Description: Плагин, который редиректит с HTTP на HTTPS
  Version: 1.0.0
  Author: Sheens
  Author URI: http://sheensay.ru/
  License: GPLv2
 */

defined( 'ABSPATH' ) or exit;

// Редирект с HTTP на HTTPS
add_action( 'template_redirect', function () {

	if ( 'on' != $_SERVER['HTTPS'] ) {

		$url = get_option( 'siteurl' ) . $_SERVER['REQUEST_URI'];

		wp_redirect( $url, 301 );

		exit;
	}
} );

Перед включением кода убедитесь, что сайту уже присвоен HTTPS: (Настройки — Общие)

Как проверить правильность работы SSL, TLS

В интернете можно найти множество сервисов, которые помогут определить, как правильно вы установили SSL и настроили сайт под него.
Один из таких сервисов: ssllabs.com

Рекомендую проверять правильность установки и настройки сертификата SSL/TLS с помощью ssllabs.com

Вы просто вводите адрес сайта и через несколько минут получаете результаты теста. Например, вот высший результат тестирования (A+) по домену https://sheensay.ru

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного A+, нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

server {
  server_name sheensay.ru www.sheensay.ru;

  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP

  # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице
  add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report";

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже:
  ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048
  ### После генерации расскомментируем строку ниже
  ssl_dhparam /etc/letsencrypt/dhparam.pem;
  
  ### Дальше другие настройки сервера
  ### ...

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

Видео установки и настройки SSL сертификата в хостинге Beget

Если Вы хотите установить SSL, TLS сертификат на сайт, который расположен в Beget, Вам пригодится следующая видеоинструкция:

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту 443 уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это /root):

• cert.pem — это сертификат SSL/TLS;
• key.pem — это ключ к сертификату.

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

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям Connection Failed. И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

• Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
• Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге /root/. Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта example.com, мы можем использовать следующую конфигурацию (example.com заменяем на свой домен, 1.2.3.4 — на свой IP сервера):

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}

SSL certificate problem: certificate has expired

Что делать, если при запросах curl вылезает ошибка:

curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

Самым правильным вариантом будет обновление сертификатов на сервере. В Linux Debian, Ubuntu это делается так:

update-ca-certificates --fresh

Эта команда обновляет символические ссылки сертификатов в /etc/ssl/certs.

Если это не помогло, то нужно будет обновить пакеты системы.

Сначала убедитесь, что пакеты безопасности в /etc/apt/sources.list выглядят примерно так:

deb http://security.debian.org/debian-security stretch/updates main contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free

Если всё в порядке, обновляем пакеты

apt update && apt upgrade -y

После обновления изменения можно проверить с помощью команды:

apt-cache policy ca-certificates

TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.

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

SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года

Принцип работы SSL и TLS

Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:

Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.

Установка соединения обеспечивается в несколько этапов:

1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.

2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

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

5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

Корневой сертификат

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

Запрос на подпись (CSR, Certificate Sign Request)

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

Клиентский сертификат

Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

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

$ openssl genrsa -out root.key 2048
Generating RSA private key, 2048 bit long modulus
..........+++
...........................................+++
e is 65537 (0x10001)

$ openssl req -new -key root.key -out root.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:My Company Root Certificate
Email Address []:it@mycompany.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:My Company

$ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com
Getting Private key

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

$ openssl x509 -noout -issuer -enddate -in root.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com
notAfter=Jan 22 11:49:41 2025 GMT

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

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

$ openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
...................................................................................+++
..........................+++
e is 65537 (0x10001)

$ openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petersburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:IT Service
Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com
Email Address []:webmaster@mycompany.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365
Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in server.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com
subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com
notAfter=Jan 25 12:22:32 2016 GMT

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

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

server {
       listen 443;
       server_name www.mycompany.com;

       root html;
       index index.html index.htm;

       ssl on;
       ssl_certificate server.pem;
       ssl_certificate_key server.key;

       ssl_session_timeout 5m;

       # Не рекомендуется использовать SSLv3 !!!
       # Он здесь только для примера
       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
       ssl_prefer_server_ciphers on;

       location / {
               try_files $uri $uri/ =404;
       }
}

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin webmaster@mycompany.com

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

        SSLEngine on

        SSLCertificateFile    /etc/ssl/certs/server.pem
        SSLCertificateKeyFile /etc/ssl/private/server.key

        # Эта директива добавляет файл, содержащий список
        # всех сертификатов, которыми подписан сертификат сервера
        #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt

        <FilesMatch ".(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        BrowserMatch "MSIE [2-6]" 
                nokeepalive ssl-unclean-shutdown 
                downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

<IfModule mod_ssl.c>
    Listen 443
</IfModule>

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

NameVirtualHost *:443

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

$ openssl genrsa -out client.key 2048

Generating RSA private key, 2048 bit long modulus
........................+++
..................................................+++
e is 65537 (0x10001)

$ openssl req -new -key client.key -out client.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Saint-Petersburg
Locality Name (eg, city) []:^C
mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:N/A
Locality Name (eg, city) []:Saint-Petrersburg  
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:Engineering
Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov
Email Address []:iivanov@mycompany.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

$ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365

Signature ok
subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com
Getting CA Private Key

$ openssl x509 -noout -issuer -subject -enddate -in client.pem
issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com
subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com
notAfter=Jan 25 13:17:15 2016 GMT

Если необходим клиентский сертификат в формате PKCS12, создаем его:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12

Enter Export Password:
Verifying - Enter Export Password:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:

# Корневой сертификат(ы), которым(и) подписан клиентский
ssl_client_certificate /etc/nginx/certs/clientroot.pem;
# Возможные варианты: on | off | optional | optional_no_ca
ssl_verify_client optional;
# Глубина проверки цепочки сертификатов, которыми подписан клиентский
ssl_verify_depth 2;

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

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

# Директория, содержащая корневые сертификаты для проверки клиентов
SSLCARevocationPath /etc/apache2/ssl.crl/
# или файл, содержащий сертификаты
SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Опция верификации клиента. Возможные варианты:
# none, optional, require and optional_no_ca
SSLVerifyClient require
# Глубина просмотра цепочки подписей. По умолчанию 1
SSLVerifyDepth  2

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

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

curl -k https://127.0.0.1:443

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Со стороны сервера ошибка выглядит так:

140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:

Со стороны клиента так:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

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

Включение протокола SSL (Secure Socket Layer) обеспечивает безопасность подключения и передачи информации. Кроме этого просмотр определенных веб-узлов невозможен без поддержки SSL и файлов cookie. Процедура включения нужного протокола может быть выполнена без привлечения дополнительного программного обеспечения.

Инструкция

Нажмите кнопку «Пуск» для вызова главного меню системы и перейдите в пункт «Программы» для выполнения операции включения протокола SSL.

Выберите используемый браузер и запустите его.

Раскройте ссылку «Свойства обозревателя» в меню «Сервис» верхней панели инструментов окна Internet Explorer и перейдите на вкладку «Конфиденциальность» открывшегося диалогового окна приложения (для Internet Explorer).

Восстановите настройки cookie по умолчанию нажатием на одноименную кнопку и перейдите на вкладку «Дополнительно» (для Internet Explorer).

Примените флажки на полях SSL 2.0 и SSL 3.0 в разделе «Безопасность» и нажмите кнопку OK для подтверждения применения выбранных изменений (для Internet Explorer).

Укажите пункт «Настройки» в меню «Инструменты» верхней панели инструментов браузера Mozilla Firefox и выберите группу «Приватность» для обновления файлов cookie (для Mozilla Firefox).

Примените флажок на поле «Принимать cookies с сайтов» в группе Cookie и раскройте узел «Дополнительно» (для Mozilla Firefox).

Выберите вкладку «Шифрование» в открывшемся диалоговом окне и примените флажки на полях «Использовать SSL 2.0» и «Использовать TLS 1.0» (для Mozilla Firefox).

Подтвердите применение выбранных изменений нажатием кнопки OK (для Mozilla Firefox).

Укажите пункт «Свойства» в меню «Правка» верхней панели инструментов окна браузера Netscape и выберите пункт «Конфиденциальность» (для Netscape).

Раскройте ссылку Cookies и примените флажок а поле «Включить все cookies» (для Netscape).

Укажите раздел SSL в списке в левой части окна приложения и примените флажки на полях «Использовать SSl 2» и «Использовать SSL 3» (для Netscape).

Нажмите кнопку OK для подтверждения применения выбранных изменений (для Netscape).

Источники:

• Как включить поддержку SSL и файлов cookie в браузере?