Что такое SSL-сертификат и для чего он нужен?
Если говорить просто, то это специальная технология, функция которой заключается в обеспечении безопасного обмена данными между сайтом и вашим браузером. Сам сертификат по своей сути содержит криптографические ключи, информацию о регистраторе и владельце сайта, что позволяет обезопасить пользователей от утечек данных.
Что такое HTTPS?
HTTPS (защищенный протокол передачи гипертекста) — представляет собой усовершенствованную версию HTTP, которая значительно уменьшает вероятность перехвата данных пользователей. Перед отправкой информация шифруется с использованием протокола SSL/TLS.
Применение HTTPS и SSL-сертификата существенно влияет на позиции сайта в поисковых системах.
Отсутствие защищенного соединения свидетельствует пользователям сайта и поисковым системам о том, что данные на этом сайте могут быть не защищены. Сайты без HTTPS могут быть помечены как небезопасные.
В чем разница между HTTP и HTTPS?
Разница между HTTP и HTTPS сводится к тому, что последний обеспечивает высокий уровень безопасности, что важно для защиты конфиденциальной информации пользователей, а HTTP не обеспечивает никакой безопасности.
HTTP — в адресе сайта указывает на использование Hypertext Transfer Protocol, который служит для передачи данных между клиентом и сервером в Интернете. Это стандартный цифровой протокол, который обычно не выделяется в адресной строке и может даже не отображаться, поскольку это подразумевается по умолчанию, но в некоторых браузерах отсутствие настроенного HTTPS будет отображаться с ошибкой и сообщать о небезопасности сайта, например в Chrome это может выглядеть так:
HTTPS — если вы видите HTTPS, это свидетельствует о том, что используется защищенная версия этого же протокола. Буква «S» означает «Secure» и указывает на то, что данные защищены криптографическими методами, реализованными с использованием SSL или обновленной версии — TLS. Это шифрование предотвращает доступ к данным без специального ключа.
В Google Chrome это будет выглядеть так:
Технически HTTP и HTTPS различаются используемыми портами: HTTP обычно работает на порту 80, а HTTPS — на порту 443. Хотя сисадмин может переназначить порты, эти значения остаются стандартными для данных протоколов.
Зачем нужен SSL-сертификат для сайта?
Когда вы посещаете сайт без SSL-сертификата, вся передаваемая информация остается в незашифрованном виде, что делает её уязвимой для перехвата.
С SSL-сертификатом данные передаются в зашифрованном виде, и даже если трафик будет перехвачен, он останется недоступным для злоумышленников.
SSL
Secure Sockets Layer (уровень защищенных сокетов) — является стандартным протоколом безопасности, а SSL-сертификаты выдаются доверенными центрами сертификации, которые обеспечивают, что данные, передаваемые между пользователем и сервером, останутся конфиденциальными и недоступными для чтения без соответствующих ключей шифрования и дешифрования.
- Использует MAC-коды для защиты сообщений.
TLS
Transport Layer Security (протокол транспортного уровня безопасности) — является более усовершенствованной версией протокола SSL. Сейчас большинство веб-сайтов предпочитают использовать TLS, так как он предлагает более высокий уровень защиты по сравнению с SSL. TLS применяет шифрование для защиты сообщений.
- Использует шифрование для защиты сообщений.
На практике используется в основном TLS, в то время как SSL стал скорее торговой маркой или брендом, который включает в себя и TLS.
Протоколы SSL 3, SSL 2 по умолчанию отключены в настройках серверов у современных хостеров.
Пошаговая работа TLS протокола:
1-й шаг. Запрос пользователя
Пользователь начинает процесс соединения, отправляя сообщение ClientHello.
Это сообщение содержит:
- тип TLS / Type TLS
- наборы шифров, которые поддерживает пользователь.
- Строку произвольных байтов, называемых «случайными клиентскими / Client Random».
2-й шаг: Ответ сервера
В своем ответе сервер отправляет ответ ServerHello:
Это сообщение содержит:
- текст со своим сертификатом SSL
- наборы шифров, выбранный для этого процесса.
- Строку произвольных байтов, называемых сгенерированных сервером, называемую «случайными серверными / Server Random»
3-й шаг: Проверка браузером подлинность SSL-сертификата
Браузер пользователя проверяет подлинность SSL-сертификата, предоставленного сервером, и центра сертификации, который его выдал.
Это доказывает, что сервер является тем, за кого себя выдает, и клиент взаимодействует с владельцем лицензии.
4-й шаг: Premaster Secret
Клиент отправляет еще одно сообщение (Premaster Secret), зашифрованное с помощью открытого ключа SSL-сертификата, который может быть расшифрован только с помощью закрытого ключа, хранящегося на сервере.
5-й шаг: Сервер расшифровывает сообщение закрытым ключом
Сервер считывает сообщение, используя свой закрытый ключ.
6-й шаг: Создание уникального ключа для данного сеанса
После этого создается сеансовый ключ с использованием «случайных клиентских / Client Random» чисел, «случайных серверных / Server Random» чисел и Premaster Secret.
7-й шаг: Обмен закодированными сообщениями о завершении
И сервер, и клиент отправляют сообщение о завершении, закодированное с помощью сеансового ключа.
8-й шаг: Complete
SSL-подключение успешно завершено. Клиент и сервер могут безопасно продолжать общение, без риска доступа к данным от третьих лиц.
Основные типы SSL-сертификатов
Самый продвинутый сертификат, доступный без регистрации юридического лица, — это DV SSL, и он относительно недорогой, если вы ищете сертификат на домен, а не группу доменов.
Однако, на мой взгляд, пока особой необходимости в нём нет. Лучше начать с полностью бесплатных SSL-сертификатов от центра сертификации Let’s Encrypt, которые можно настроить на максимальный уровень безопасности и которые работают стабильно и подтверждают, что ваш сайта защищен.
Тип сертификата |
Характеристика |
Плюсы |
Минусы |
---|---|---|---|
EV SSL |
Сертификаты с серьезной проверкой юридического лица. |
Высокий уровень доверия; |
Потеря видимой идентификации (символ замка в URL, название компании и страны) |
Защита конфиденциальных данных, более сложное шифрование; |
Высокая стоимость и сложность получения; |
||
EV SSL-сертификата на сайте свидетельствует о том, что организация существует легально и прошла проверку. |
Нет преимуществ перед другими типами SSL-сертификатов для большинства задач. |
||
OV SSL |
Сертификаты подтверждающие организацию |
Высокий уровень доверия; |
Высокая стоимость и сложность получения; |
Защита конфиденциальных данных, более сложное шифрование; |
Нет преимуществ перед другими типами SSL-сертификатов для большинства задач; |
||
OV SSL-сертификата на сайте свидетельствует о том, что организация существует легально и прошла проверку. |
Практически нет разницы между OV SSL и DV SSL. |
||
DV SSL |
Сертификаты подтверждающие домен |
Быстрое и простое получение; |
Базовое шифрование, которое уступает более дорогим сертификатам. Но это не является серьезной проблемой для большинства проектов. |
Низкая стоимость. |
— |
||
Wildcard-сертификаты |
Сертификаты для поддоменов |
Экономия средств, за счет одного сертификата можно покрыть сразу множество поддоменов; |
Если закрытый ключ Wildcard-сертификата будет скомпрометирован, все поддомены окажутся под угрозой, в отличие от сценария с отдельными сертификатами на каждый поддомен. |
Упрощение управления настройками для всех доменов; |
Обычно покрывают только поддомены первого уровня (например, sub.domain.com), но не распространяются на более глубокие уровни (например, sub.sub.domain.com), что может ограничить применение. |
||
Позволяет легко добавлять новые поддомены без необходимости получения новых сертификатов, что упрощает развитие и масштабирование веб-сервиса. |
Обеспечивают защиту доменов, но не содержат специфической информации о каждом поддомене, что может затруднять диагностику и выявление проблем на уровне отдельных поддоменов. |
||
MDC |
Мультидоменные сертификаты |
Эти сертификаты позволяют защитить несколько доменных и поддоменных имен, включая полностью различные домены и домены разных уровней, что особенно полезно для компании или организации, управляющей множеством веб-ресурсов; |
Несмотря на упрощение администрирования за счет единого сертификата для множества доменов, управление списком доменов может стать сложным и запутанным, особенно если домены принадлежат разным отделам или подразделениям; |
Использование одного сертификата для нескольких доменов и поддоменов снижает затраты на покупку и управление несколькими сертификатами, а также упрощает администрирование; |
Как и в случае с Wildcard-сертификатами, компрометация одного общего сертификата может поставить под угрозу все домены и поддомены, защищенные им; |
||
Гибкость в управлении. |
MDC не поддерживают локальные или внутренние домены, что может ограничить их применение для внутренних корпоративных сетей или специфических сценариев внутри организаций. |
||
UCC |
Сертификаты унифицированных коммуникаций |
UCC позволяют защитить несколько доменных имен с помощью одного сертификата, что удобно для организаций, управляющих несколькими веб-сайтами или сервисами; |
Хотя UCC изначально предназначались для Microsoft-экосистемы, их интеграция и использование в других платформах может потребовать дополнительной настройки и поддержки; |
Изначально разработанные для серверов Microsoft Exchange и Live Communications, UCC-sertificates хорошо интегрированы с этими системами, обеспечивая оптимизированную защиту для их пользователей; |
Как и в случае с другими мультидоменными сертификатами, компрометация одного сертификата может поставить под угрозу все домены, защищенные этим сертификатом; |
||
Использование одного сертификата для нескольких доменов снижает затраты на управление и упрощает администрирование сертификатов, что удобно для компаний с большими IT-инфраструктурами. |
Для предприятий, не использующих Microsoft Exchange или Live Communications, может потребоваться дополнительная настройка и тестирование для оптимального использования UCC, что может увеличить затраты на его внедрение. |
Где можно получить бесплатные сертификаты:
Основной поставщик бесплатных сертификатов это компания Let’s Encrypt, сертификат от неё можно заказать почти на любом хостинге, но также можно получить сертификат при подключении CDN CLoudFlare, то есть есть два способа получить бесплатных SSL-сертификат:
- Выпуск сертификат от letsencrypt.org
- Подключение и настройка SSL-сертификата от cloudflare.com
Список регистраторов:
- GlobalSign;
- Let’s Encrypt;
- Comodo;
- DigiCert;
- GeoTrust;
- WoSign;
- EnTrust;
- Izenpe;
- Symantec;
- Thawte.
Российские сертификаты:
С 2022 года Минцифры разрешило выдачу внутренних сертификатов. На портале Госуслуг, можно бесплатно получить OV или базовый DV сертификаты.
Как проверить настройку SSL-сертификата?
Чтобы получить развернутую информацию о настройках SSL-сертификата лучше всего подойдет сервис по оценке от SSL Labs.
Ссылка на анализатор: https://www.ssllabs.com/ssltest/
Повышения оценки сертификата
По умолчанию большая часть серверов настроена таким образом, что SSL-сертификат работает с уязвимостями и нужно дополнительно его дорабатывать через настройки сервера и DNS, самые частые ошибки, которые влияют на сертификат:
1. Устаревшие протоколы, по которым до сих пор работает много серверов:
TSL 1.0, TSL 1.1 — оба протокола уязвимы к различного рода атакам и по умолчанию их лучше отключать в настройках сервера, оставляя TSL 1.2 и TSL 1.3, оба протокола поддерживаются достаточно, это значит, что лучше отказаться от старых версий.
Делается это через настройку сервера (если вы настраиваете сервер) или через запрос к техподдержке хостинга, можно попросить у них отключить сертификаты (на beget.ru я так и договорился):
Но нужно подробно объяснить проблему, обычный агент поддержки по умолчанию проверяет стандартным образом работает SSL или нет и пишет, что всё нормально. Чтобы сэкономить время нужно подробно описать задачу:
Если бы я сразу подробно написал, то все настроили бы первый день, а не через несколько дней общения.
2. DNS CAA:
DNS CAA — это DNS-записи, которые вы можете сделать самим и указать там важную информацию о вашем сертификате и т.д. По сути это просто тип DNS-записи, которую можно настроить через админку (нужно учитывать при проверке, что DNS-записи обновляются не в режиме онлайн, а от нескольких часов до нескольких суток).
Без записей:
Добавил записи:
Про это есть подробная статья,по ней я сформировал себе нужные DNS-записи через онлайн-генератор, но можно и самому написать.
На хостинге beget.ru можно добавить DNS-записи самому, через их админку:
В целом DNS-CAA значительно не улучшает оценку сертификата сервисом, но тем не менее они делаются за пару минут и почему бы их не настроить.
3. Цепочки сертификатов
Сертификаты связываются цепочкой от сертификата домена вашего сайта до корневого сертификата организации выдавшей вам SSL-сертификат:
Server Key and Certificate (сертификат для вашего домена) #1 -> Промежуточный сертификат #2 -> Корневой сертификат центра сертификации #3
3.1 Лишнее упоминание корневого сертификата
В данном случае ошибка, в том что можно было обойтись меньшим количеством сертификатов в цепочке, так как у клиента уже будут данные о корневом сертификате в цепочке и можно было бы обойтись без его дополнительного упоминания.
Проблема в том, что дополнительный сертификат (который бесполезен) увеличивает задержку связи.
3.2 Также может быть нарушен порядок цепочки сертификатов
Когда сначала в цепочке идет сертификат сайта, потом корневой и потом промежуточный, что является некорректной реализацией. Так как нелогично, что корневой идет между сертификатом сайта и промежуточным.
4. Alternative names MISMATCH / Несоответствие имен
Проверка: https://globalsign.ssllabs.com/
Пример: в примере первый сертификат настроен с хорошим грейдом, ошибка относится именно ко второму дополнительному сертификату.
Из-за данной проблемы при посещении сайта можно увидеть подобный тип сообщения от современных браузеров:
Chrome: «Этот сервер не смог доказать, что он example.com; его сертификат безопасности от example.com. Это может привести к неправильной настройке или перехвату вашего соединения злоумышленником»
Ошибка несоответствия имен возникает, когда общее имя или SAN вашего SSL/TLS-сертификата не соответствует домену или адресной строке браузера. Это может произойти, если вы просто посетите https://example.com вместо https://www.example.com , если в SAN сертификата они оба не указаны.
SSL-сертификат с функцией SAN (Subject Alternative Names) — позволяет обеспечить защиту для множества доменов или поддоменов, в том числе в различных доменных зонах. При оформлении такого сертификата можно включить до 100 различных доменных имен, каждое из которых будет защищено.
Существует три типа SAN-сертификатов:
- SAN Subdomain — предназначен для защиты основного домена и его поддоменов любого уровня, которые были указаны при заказе.
Основной домен:
- example.com
Поддомены:
- sub1.example.com
- sub2.sub1.example.com
- sub3.sub2.sub1.example.com
- и другие.
- SAN FQDN (Fully Qualified Domain Name) — позволяет защитить основной домен и дополнительные домены.
Основной домен и дополнительные:
- example.com
- example.ru
- example.net
- и другие.
- SAN FQDN + Wildcard — дает возможность защитить основной и дополнительные домены, а также их прямые поддомены.
SSL-сертификат с опцией SAN (Subject Alternative Names) — это тип сертификата, с помощью которого можно защитить сразу несколько доменов или поддоменов любого уровня, в том числе в разных зонах. При заказе вы можете добавить до 100 различных доменных имен — сертификат будет защищать каждый из них.
Существует 3 вида SAN-сертификатов:
1. SAN Subdomain — позволяет защитить основной домен и его поддомены любого уровня, указанные при заказе. .
Например:
- Основной домен: example.com
- Его поддомены: sub1.example.com, sub2.sub1.example.com, sub3.sub2.sub1.example.com и другие.
2. SAN FQDN (Fully Qualified Domain Name) — позволяет защитить основной домен и любые дополнительные домены.
Например: example.com и дополнительные домены example.ru, example.net и другие.
3. SAN FQDN + Wildcard — позволяет защитить основной и дополнительные домены, а также их прямые поддомены.
Возможные причины ошибки:
- При подключении используется лишний сертификат, который и создает данную ошибку;
- Адрес веб-сайта по ошибке не был включен в ваше общее имя.
Вы приобрели сертификат с общим именем www.example.com , но не добавили example.com в качестве SAN к сертификату. - Веб-сайт не использует SSL, но имеет общий IP-адрес с сайтом, который использует SSL.
Если ваш сайт использует тот же IP-адрес, что и другие сайты, это может повлиять на данный тип ошибки.
Если один из сайтов, разделяющих ваш IP-адрес, установил сертификат SSL/TLS на этом общем IP-адресе, это может помешать работе других сайтов.
Также может быть, что подключающийся клиент или сервер хостинга (или оба) не поддерживают индикацию имени сервера (SNI).
- Конкретно в данном случае сертификат от timeweb для тестового домена перешел на основной домен сайта и также участвует при SSL-соединении, его нужно отключить через техподдержку и настройку сервера. (причины разные, DNS A запись стоит на домен хостера, нет выделенного айпи, а у хостер нет SNI).
-
-
2. В DNS A записи, указан айпи хостинга, у которого нет SNI на данном айпи. Оптимально, либо использовать хостинг со SNI, либо подключить выделенный айпи адрес и поменять айпи в DNS A записи.
-
Меняем на другой айпи:
Обновились DNS-сервера и после повторного теста второго сертификата нет. Просто нужно было указать с какого айпи оптимально заходить на сайт.
5. NOT TRUSTED / SSL-сертификат выдан не достоверным центром сертификации
Ошибка подразумевает то, что данный сертификат сгенерированный без верификации одним из доверенных центров SSL-сертификации. То есть, это какой-то рандомный сертификат.
Чтобы её исправить, нужно, либо, чтобы сервер поддерживал SNI (разные домены на одном айпи), либо использовать выделенный айпи, чтобы к вашему сайту не имел отношения сертификат выданный недоверенным центром сертификации.
В данном случае это сертификат для тестовой версии на поддомене timeweb и его просто полностью нужно отключить от основного домена.
Проблема с недоверенным сертификатом связана с его происхождением и необходимостью получения сертификата от доверенного центра сертификации, а не с поддержкой SNI или выделенного IP.
6. No SNI / This site works only in browsers with SNI support.
SNI (Server Name Indication) — это расширение для протокола SSL/TLS. Расширение позволяет клиенту распознавать подключающееся имя хоста во время процесса установления связи.
6.1 Он сравнивает имя сертификата отправленного сервером и доменное имя сайта, на который он подключается:
сертификат: site.ru IP: 5.182.133.253
доменное имя: site.ru IP: 5.182.133.253
В данной конфигурации произойдет подключение, без ошибок.
6.2 Если имя в сертификате и доменное имя отличаются, но IP совпадают:
сертификат: site.ru IP: 5.182.133.253
доменное имя: scam.ru IP: 5.182.133.253
Если имя в сертификате и доменное имя клиента не совпадают, это приведет к предупреждению о безопасности, но не обязательно к разрыву соединения. Браузер может предупредить о возможной атаке «человек посередине» (man-in-the-middle), а пользователь проигнорировать предупреждение и продолжить подключение.
Ошибка происходит из-за того, что на одном IP адресе находятся разные домены и при стандартной проверке непонятно ошибка в данном случае это или какая-то проблема, которая может привести к потере данных.
Чтобы исправить эту ситуацию и позволить на одном ip-адресе держать множество доменов создали расширение для протокола SSL/TSL под названием SNI.
Например, если вам нужны поддомены, то без SNI каждый поддомен будет выдавать такую ошибку. То есть, SNI позволяет сравнивать имя сертификата с именем хоста, без привязки к IP.
Браузеры будут иметь дело с точным доменным именем, к которому посетитель хочет подключиться во время защищенного SSL-соединения. Поэтому сервер очень хорошо знает, какой сертификат он должен отправить обратно клиенту. В этом случае сервер, использующий один IP-адрес, может обслуживать несколько доменных имен, для которых покупка одного сертификата недостаточна.
Использование SNI зависит от клиентов и их обновленного статуса устройства. Без SNI один IP-адрес может управлять одним именем хоста.
7. Опасность подключения CloudFlare из-за РКН
По умолчанию при настройке CDN CloudFlare включен протокол TSL 1.3 с ECH [SNI] из-за чего РКН закроет доступ к вашему сайту, так как данная технология запрещена в России.
Чтобы этого избежать нужно в настройках CloudFlare отключить протокол TLS 1.3:
8. HTTP Strict Transport Security (HSTS) with long duration deployed on this server
На этом сервере развернут протокол HTTP Strict Transport Security (HSTS) с длительным сроком действия.
Также есть такая метрика в рамках аналитики от ssllabs, они ссылаются на страницу википедии по данной теме.
По сути это принудительная директива для любого клиента работать только по TLS соединению определенному сервером. Подробнее можно прочесть тут.
Цитата с выводом из статьи:
«Не включайте потенциально опасные функции без понимания принципов их работы. Оценку «A» в тесте от SSL Labs вы получите и без HSTS, а включить его можно после проверки всего функционала через TLS. Со статическим листом в браузере пути назад уже не будет, поэтому лучше сразу приобрести сертификат с wildcard.»
Результат корректной настройки SSL-сертификата.
При стандартных настройках сервера, поднять грейд сертификата можно очень быстро.
По умолчанию при создании сайта на хостинге beget.ru я получил B грейд SSL-сертификата, но просто отключив через техподдержку TSL 1.0 и 1.1 я поднял его грейд до A.
update: после настройки HSTS получен грейд A+