Что такое SSL сертификат и для чего он нужен

Сегодня на каждом углу слышим про безопасность и что SSL сертификаты решат все проблемы для вашего сайта. Особый страх нагоняют такие компании как Гугл (LLC Google) и Яндекс (Публичная Компания С Ограниченной Ответственностью Яндекс), владеющие одними из самых популярных поисковых систем. Давайте вместе разбираться что же это за SSL/TLS такой.

Secure Sockets Layer

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

По сути TLS является продолжением SSL, последняя версия SSL 3.0 была выпущена в 1996-ом году и на ее основе выпустили протокол TLS 1.0. На текущий момент последняя версия TLS 1.3. Сейчас практически не используется SSL из-за множества обнаруженных уязвимостей (США в 2014-ом году ), поэтому иногда говоря об SSL подразумевают именно TLS.

Для просмотра страниц сайта используется протокол HTTP (Hyper Text Transfer Protocol - протокол передачи гипертекста). Она по умолчанию работает на порту 80. Когда мы хотим попасть на сайт, то вводим в адресной строке syncweb.ru, браузер автоматически дописывает http://syncweb.ru:80. Есть защищенная версия этого протокола - HTTPS (HTTP Secure - защищённый протокол передачи гипертекста), который как раз использует SSL/TLS и для того, чтобы сразу перейти на сайт по HTTPS нужно вводить в начале адреса сайта https://.

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

Помимо клиента(вернее браузера) и нашего сайта появился посторонний в лице Центра Сертификации (он же удостоверяющий центр, CA - Certification Authority). ЦС условно считаем честным и всегда ему доверяем, а его защищенность от различных угроз неоспорима. Чтобы еще проще объяснить - представим, что мы хотим купить автомобиль. Нашли продавца, но доверия ему нет. И тут появляется третье лицо, которому мы верим и говорит, что хорошо знает продавца и ему можно верить. После этого Вы совершаете сделку по покупке автомобиля.

Таких центров сертификации довольно много, даже Вы сами можете им выступать, но доверия к Вам не будет. Есть довольно крупные ЦС, которым все доверяют:

• Let’s Encrypt
• Comodo
• GeoTrust
• RapidSSL
• Symantec
• Thawte
• Global Sign

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

Мы же помним, что мы полностью доверяем ЦС? Поэтому когда клиент обращается на наш сайт (первое действие на картинке) и получает в ответ сертификат (второе действие на картинке), он проверяем его в ЦС на валидность (помимо того, что сертификат настоящий и выдан этому сайту, могут быть другие ограничения, например срок сертификата) и генерирует предварительный секретный ключ (pre-master secret) - третье действие на картинке. Отправляем предварительный секретный ключ зашифрованный открытым ключом сервера - четвертое действие. В завершении сервер создает секретный ключ и начинает шифрованную передачу с клиентом. Весь этот процесс называется рукопожатием или handshake.

Что же такое шифрование? Давайте рассмотрим вариант, что мы хотим написать другу письмо, но не хотим чтобы кто-либо его прочитал. У нас обоих есть одинаковая книга “Граф Монте Кристо” Александра Дюма. Мы договорились изначально, что будем каждое слово заменять шестью цифрами. Например, “051234” будет означать то, что на пятьдесят первой странице в двадцать третьей строке четвертое слово. Почтальон или кто-либо другой не догадается о тексте письма, если не будут знать о нашей с другом договоренности. Весь этот процесс и называется шифрованием, а книга - это наш ключ. А теперь представьте, что такая книга есть только у Вас и у друга.

Немного дополнительной информации про шифрование и ключи. Есть различные математические алгоритмы для шифрования информации, например с симметричным шифрованием DES, 3DES, RC5, IDEA, ГОСТ 28147-89, ГОСТ Р 34.12-2015 или асимметричным - RSA, DSA, Diffie-Hellman, ГОСТ Р 34.10-2012. Как можно догадаться, последние алгоритмы в списках - это Российские. В некоторых случаях Вы будете обязаны использовать только их.

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

А теперь посмотрим несколько примеров SSL сертификатов.

На картинке мы видим сертификат, который уже не действителен из-за истекшего срока. Если секретный ключ попал в чужие руки, то ключ скомпрометирован и такой сертификат на основе этого ключа отзывается ЦС. Если же сертификат действительный, как этот:

То нам откроется сайт и мы увидим рядом с адресом значок замочка (зависит от браузера), например, вот так выглядит это в Google Chrome:

Какие бывают виды SLL сертификатов

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

DV или Domain Validated

Самым часто используемым является DV (Domain Validated - проверенный домен). Прям из названия можно понять, что он гарантирует лишь то, что домен(адрес сайта, например syncweb.ru) соответствует сертификату. Процесс получения SSL занимает несколько минут, а сам процесс проверки гарантирует, что запросчик имеет контроль над доменом.

Такой вариант идеально подойдет малому и среднему бизнесу, начинающим или даже если Вы решили завести страничку о себе. Такие сертификаты бывают как платные, так и бесплатные. Самыми популярными бесплатными сертификатами DV являются сертификаты от Let’s Encrypt. Ключевой особенностью помимо стоимости является отсутствие каких-либо компенсаций, если Ваш ключ будет скомпрометирован по вине ЦС. Как получить такой сертификат расскажем чуть позже. У платных сертификатов есть сумма страховки, например у Comodo эта сумма равна 10000 долларов.

Ну и конечно, почти все ЦС предлагают платные сертификаты типа DV. Из плюсов можно выделить:

• стандартные SSL дешевле других сертификатов
• пользователи могут защитить свой сайт в течение нескольких минут
• не нужны деловые документы для проверки
• поддерживает 99,9% настольных и мобильных браузеров
• повышает доверие клиентов.

OV или Organization Validated

Organization Validated переводится как проверка организации. и это нам говорит о том, что помимо проверки контроля над доменным именем проводится и проверка Вашего бизнеса, такие как контактная информация, название компании, название отдела, город расположения, область, страна и другие. ЦС проверяет довольно долго, но обычно это занимает около 2-3 дней.

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

• регистрация в ЕГРЮЛ
• регистрационная информация домена(можно посмотреть с помощью сервисов whois)
• запись в телефонной книге.

Теперь в сертификате можно посмотреть некоторую информацию об организации, например как здесь:

В указанном примере этот сертификат еще и WildCard (CN у такого сертификата начинается с “*.”), о котором мы узнаем чуть ниже.

SSL/TLS сертификат типа OV больше подойдет организациям, которые работают с конфиденциальной информацией пользователя, например, больницы, или небольшим организациям с электронной коммерцией, например, интернет-магазин.

Также гарантия от ЦС на примере сертификата от Comodo составит 100000 долларов.

Из плюсов по сравнению с SSL DV добавляется:

• более выигрышная позиция по сравнению с конкурентами
• неограниченные серверные лицензии
• доверие клиентов к организации значительно выше.

EV или Extended Validation

Extended Validation (EV) переводится как расширенная проверка. Помимо всех проверок, которые нужно пройти при получении сертификатов типов DV и OV, Вам нужно:

• заполнить заявление и соглашение с центром сертификации
• предоставить документ, подтверждающий существование юридического лица
• проверка по телефону организации
• проверка e-mail

Из дополнительным бонусов теперь рядом с замочком в адресной строке будет название Вашей организации, а вся адресная строка будет подсвечена зеленым цветом, например, как сайт личного кабинета Сбербанка:

Сроки получения такого типа сертификата возрастают, обычно не более двух недель. Поэтому, если Вашей компании нужен именно такой сертификат, то следует заказать его заранее. Гарантию на такой сертификат ЦС Comodo предоставляет на сумму 1750000$.

Успех бизнеса электронной коммерции зависит от репутации бренда и доверия клиентов. Сертификат EV еще сильнее повысит доверие клиентов, что даст в свою очередь увеличение потока клиентов и, как следствие, денежных средств. Такие сертификаты больше подойдут банкам и крупным интернет-магазинам. Из дополнительных плюсов выделим:

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

Wildcard Certificates

Сертификаты Wildcard позволяют экономить. Если у Вашего сайта планируются различные поддомены, например, mail.my-company.ru, shop.my-company.ru и develop.my-company.ru, то у Вам нужно приобретать либо 3 сертификата на каждый из сайтов, либо один Wildcard сертификат на *.my-company.ru, а затем использовать на всех своих поддоменах. Wildcard сертификаты могут применяться для неограниченного количества поддоменов.

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

• неограниченное количество поддоменов
• централизованное управление - один сертификат вместо нескольких
• простота обновления - не нужно следить за
• каждым сертификатом и истечением срока годности

А мне нужен SSL сертификат?

А теперь самый главный вопрос: мне SSL сертификат нужен? Ответить на этот вопрос должны Вы сами себе, руководствуясь следующими наводящими вопросами:

• не планируется никаких вводов личных данных пользователей, у меня обычный сайт-визитка или информационный сайт. Для данного случая не обязательно иметь сертификат. Почему? Главная задача SSL/TLS - защита данных. Если пользователи Вашего сайта не будут вводить никаких своих данных и оплачивать товары - то Вам не обязателен сертификат. К тому же перевод уже работающего проекта на HTTPS не прост и нужно предусмотреть много нюансов, о которых чуть ниже.
• у меня интернет - магазин, я продаю товары и услуги. Однозначно нужен сертификат. Особенно на страницах ввода данных платежных карт, чтобы обезопасить покупателя. Мы же не хотим подвергать их опасности, если вдруг злоумышленник будет перехватывать данные?
• мой сайт работает с персональными данными пользователей, здесь хранятся личные документы, данные о болезнях и лекарствах, секретная информация, ну или может храниться. Тоже нужен сертификат, да и очень желательно не DV типа. Особенно на территории России, где действует закон №152-ФЗ “О персональных данных”, подобные законы есть и в других странах.

HTTPS и поисковые системы

Мы рассмотрели варианты, где нужно использовать SSL/TLS сертификаты и где не обязательно, а теперь рассмотрим как же на все это смотрят гиганты в сети Интернет. Мы, конечно, о таких компаниях как Google и Яндекс (мы в России живем, для нас это гигант). Для начала сделаем небольшое отступление и расскажем кратко про SEO (Search Engine Optimization - поисковая оптимизация). Как люди узнают про Ваш сайт? Есть, конечно, вариант через рекламный баннер на здании и визитки, но в основном все пользуются поисковиками, поэтому их мнение об SSL/TLS сертификатах очень важно. Если Вы хотите получить известность своего проекта, то нужно искать SEO-специалиста.

В августе 2014-го года Google публикует информацию, что они за секретность и безопасность интернета, что все их сервисы работают на HTTPS и всем web-мастерам рекомендуют сделать то же самое. А так же они вводят в алгоритм ранжирования (поисковая выдача, т.е. наличие HTTPS чуть выше ставит Ваш сайт в результатах поиска) параметр с влиянием 1% (временно, на тест, позже увеличат) при наличии у сайта HTTPS.

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

Потом практически не было никаких особых вестей от Google последующие пару лет, но затем сразу после информации, что 50% поисковой выдачи - это сайты на HTTPS, появляется следующий твит:

Здесь говорится о том, что Google отказался от планов увеличения влияния в поисковой выдаче параметра наличия HTTPS. Оставлю ссылку для самостоятельного ознакомления. Попутно, Google в своем браузере(Google Chrome версии 56 и выше) реализует пометку страниц для ввода данных платежных карт как небезопасные, если они работают не на HTTPS.

Что же теперь? В июле этого года появляется статья, в которой говорится, что теперь с версии 68 браузера Google Chrome все сайты, работающие по HTTP будут помечаться как “Not Secure” или “Не защищено”, а так же трафик страниц HTTPS теперь составляет 84%.

Другие популярные браузеры, такие как Firefox и Opera тоже поддерживают данное нововведение. Что это значит на практике? Что теперь при наличии любого сайта желательно иметь SSL/TLS сертификат и работать по протоколу HTTPS, иначе Ваши пользователи будут видеть режущую глаз надпись.

У нас в России Яндекс тоже не уступает зарубежному гиганту, но не так “терроризирует” пользователей. Официальная позиция - “В поисковой системе Яндекс сайты по протоколу HTTP/HTTPS индексируются и участвуют в поиске на равных условиях.”. На одном из международных форумов по практической безопасности Positive Hack Days (PHDays) при выступлении сотрудники Яндекс советовали переходить на HTTPS всем, даже при наличии у Вас простого сайта-визитки.

А что на практике? Если поискать тех, кто проводил исследования, то все отмечают рост количества посетителей после перехода на HTTPS. Вот тестирование одного крупного издания по SEO, результатами которого стал рост количества посетителей. Выводами данного исследования стало, что Яндекс не игнорирует наличие у сайта HTTPS, а также при переезде будьте готовы к небольшой просадке по посещаемости. Две крупные для нашей страны поисковые системы ратуют за переход на HTTPS, так что выбора нет, если мы хотим сохранить посещаемость своего сайта.

Особенности перехода на HTTPS

С поисковыми системами разобрались, нам нужен SSL/TLS сертификат. Если это новый проект - то особых проблем нет, сразу планируйте расходы на поддержку HTTPS. Если же у Вас старый проект, то тут надо задуматься о поиске хороших специалистов. Это скорее тема для отдельной статьи, поэтому здесь мы приведем кратко рекомендации по переходу:

• сертификат должен иметь ключ длиной 2048 бит
• убедиться, что SSL/TLS сертификат настроен корректно
• перед тем, как поставить в web-сервере переадресацию с 301 кодом, нужно настроить правильно инструменты web-мастера в кабинетах Яндекс и Google
• проверить все ссылки на сайте, чтобы везде было использован HTTPS
• не блокировать robots.txt по HTTPS
• корректно настроенный файл robots.txt
• корректный файл sitemap.xml
• убедиться, что у каждой страницы HTTP есть страница HTTPS.

Здесь можно почитать рекомендации от Яндекс, ну а здесь рекомендации от Google.

Практика

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

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

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

Идем на сайт ЦС https://letsencrypt.org. Там нажимаем кнопку Get Started. Здесь описаны способы получения сертификата. Нас интересует раздел With Shell Access, что означает, что у нас должен быть консольный доступ к серверу. Там щелкаем по Certbot или сразу переходим по ссылке https://certbot.eff.org. На главной странице есть два выпадающих списка, в одном нужно указать используемый Web сервер, а в другом - операционную систему. Я приведу пример с использованием NGINX на CentOS 7. Можно воспользоваться инструкцией, которая отобразится на сайте после Вашего выбора. Для моего примера - в консоли сервера набираем следующие команды (NGINX еще не установлен, поэтому тут и установка web-сервера):

Разрешим доступ в нашем межсетевом экране доступ по 80 (используется по умолчанию для протокола HTTP) и 443 (используется по умолчанию для HTTPS) портам. С HTTP сделаем переадресацию на HTTPS чуть дальше средствами Certbot. Я использую зону public для внешнего интерфейса, поэтому для меня будут такие команды:

В данном случае бы добавили сервисы, в которых прописаны порты 80 и 443, можно вместо этого прописать порты:

Если Вы решили не использовать firewalld и больше привыкли к iptables, то:

Запускаем процедуру выпуска сертификата и здесь же, когда спросит о переадресации на HTTPS выберем пункт 2 (переадресовывать):

Теперь у нас правильная переадресация и сертификат. Мы же помним, что бесплатные сертификаты Let’s Encrypt выдаются на 3 месяца? Можно помнить об этом и заходить раз в 3 месяца и обновлять его или автоматизировать этот процесс. Для этого добавим в cron ежедневную попытку перевыпустить сертификат (по рекомендациям Certbot это действие надо выполнять 2 раза в день). До истечения срока сертификата в зависимости от настроек он будет перевыпущен(по умолчанию за 30 дней до окончания сертификата):

Проверяем результат:

По умолчанию, в операционной системе CentOS 7 файлы cron пользователя root хранятся здесь /var/spool/cron/root, но путь может отличаться, поэтому советую для правки задач использовать команду

Самоподписанный сертификат

Такой сертификат не рекомендуется использовать кроме как тестирования или внутреннего использования. Вы, конечно, можете использовать его и в Интернет, но это не рекомендуется. Будем ставить самоподписанный сертификат на NGINX на CentOS. Итак, начнем.

Проверим статус NGINX и не забываем про межсетевой экран

Зайдем на наш сайт, введя в строку адреса IP адрес сервера или домен(например, my-company.ru), мы должны увидеть приблизительно такое:

Хорошим тоном будет называть сертификат именем домена, к которому он относится - так проще будет находить и обслуживать сертификаты, особенно если он не один. Пусть для нашего примера будет домен my-site.ru(Вам нужно везде заменить этот домен на свой). Теперь приступим непосредственно к установке SSL/TLS сертификата:

Опишем, что означают ключи в команде генерации сертификата и секретного ключа:

• openssl: непосредственно программа управления сертификатами
• req: команда управления запросами на получение сертификатов X.509
• -x509: создает самоподписанный сертификат вместо запроса на сертификат
• -nodes: не шифрует паролем секретный ключ. Нужно для того, чтобы после перезапуска NGINX не требовалось вводить пароль на доступ к ключу
• -days 365: срок действия сертификата, в данном случае - год. По умолчанию - 30 дней
• -newkey rsa:2048: создает секретный ключ для асимметричного алгоритм RSA с длиной ключа 2048 бит
• -keyout: место расположения секретного ключа и его имя
• -out: место расположения сертификата и его имя

При создании сертификата и ключа будут заданы вопросы о стране, области, городе, названии организации, название отдела, домена (или ip адрес сервера) и email организации.

Затем нужно создать ключи Диффи-Хеллмана:

Спустя пару минут ключ будет создан, ну а у нас теперь есть самоподписанный сертификат. Осталось подключить его к NGINX.

По умолчанию главный файл конфигурации находится здесь /etc/nginx/nginx.conf. В CentOS 7 есть директория для собственных доменов /etc/nginx/conf.d/. Эта директория включена в главный конфигурационный файл, но Вы все эти настройки можете изменить и вносить правки напрямую. Именно в этой директории мы создадим файл с именем нашего домена и расширением .conf:

В файл /etc/nginx/conf.d/my-site.conf запишем следующие строки:

Этого уже достаточно для того, чтобы при вводе в строке адреса https://my-site.ru у вас открывалась страница по протоколу HTTPS.

Но часто ли пользователи вводят полностью адрес сайта вместе с протоколом? Нам нужна переадресация с HTTP на HTTPS. Для этого есть директория /etc/nginx/default.d/, где мы создадим файл с одной лишь строчкой

Мы можем это все сделать и одной командой:

Теперь проверяем настройки nginx:

Тест прошел без ошибок и теперь перезапускаем NGINX:

Настройка закончена. Но при попытке зайти у Вас будет вот такое сообщение:

Не переживайте. Помните, что при рукопожатии проверяется ЦС, выдавший сертификат? Поскольку мы сами являемся тем самым ЦС, то о нас никто не знает, поэтому мы видим данное сообщение. Но браузер позволит нам посетить сайт, достаточно нажать “дополнительные”, а затем “перейти на сайт my-site.ru (не безопасно)”. В некоторых браузерах это может выглядеть немножко по-другому, например, в Firefox нужно нажать “добавить исключение”.

Установка SSL сертификатов от Comodo

Приведем пример установки сертификата от Comodo. Для многих случаев получения платных сертификатов действия будут аналогичными. Чтобы не повторяться, установку NGINX и настройку межсетевого экрана можно посмотреть в пунктах выше. Заходим на официальный сайт Comodo и в меню выбираем “Сертификаты Comodo->Пробная версия сертификата SSL на 90 дней”. Затем нажимаем кнопку “Скачать бесплатно”. На вновь открывшейся странице нажимаем кнопку “GET Free SSL”.

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

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

• -new: генерирует новый запрос сертификата

Теперь нам нужно получить содержимое файла CSR для вставки в форму на сайте Comodo(вывод урезан):

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

Затем необходимо выбрать способ прохождения процедуры проверки управления доменом:

Почту администратора владельца домена может автоматически взять из данных о домене у регистратора, но в данном случае такой информации нет, поэтому нам предлагается несколько стандартных вариантов электронной почты и несколько альтернативных способов. Пройдем проверку с помощью “HTTP CSR Hash”, выбираем этот пункт и нажимаем “Continue”.

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

Заполняем и нажимаем “Continue”. Затем читаем соглашение, соглашаемся и нажимаем “Continue”.

Как видно, нам осталось пройти лишь процедуру проверки управления доменом. Нажимаем “Click here for more details” напротив “Domain Control Validation”, затем откроем подсказку “Show Alternative DCV Information”:

Нам нужно, чтобы при обращении по адресу http://my-site.ru/.well-known/pki-validation/93DB719176A6FFD42A6FC548CC0505FA.txt открывался файл с содержимым:

Теперь настроим NGINX. Создадим файл:

В файл запишем следующие строки:

Здесь мы отрезаем /.well-known/pki-validation/, что позволит нам положить только сам нужный файл в корень директории сервера (по умолчанию /usr/share/nginx/html/), что и сделаем дальше:

Теперь откроем созданный файл и допишем в него:

И проверяем конфигурацию на предмет ошибок и перезапускаем сервер NGINX:

Теперь возвращаемся на страницу Comodo, где мы не прошли подтверждение управление сервером, выбираем “HTTP CSR Hash” и нажимаем “Submit”. Проверка должна быть пройдена, а на указанный email должно прийти несколько писем, в последнем будет Ваш сертификат. Его так же можно скачать с личного кабинета на сайте Comodo. Дальнейшая настройка NGINX и переадресация на HTTPS ни чем не отличается от действий при самоподписанном сертификате, разве что названием сертификата и месторасположением. Дополнительную информацию и рекомендации от Comodo можно прочитать здесь.

Заключение

Это была большая статья, но мы постарались как можно подробнее и простым языком объяснить Вам про SSL/TLS сертификаты, каких видов они бывают и их важность на сегодня в сети Интернет, об отношении поисковых гигантов к использованию HTTPS, о сложности перехода на HTTPS и о том, что сайтов на HTTP с каждым днем все меньше и меньше. День прошёл не зря, не так ли?

У нас есть SSL сертификаты всех видов