Sectigo rsa domain validation secure server ca что это
Сам себе РКН или родительский контроль с MikroTik (ч.2)
▍ 1. Firewall Mangle
Рассмотрим имеющиеся возможности по маркировке трафика в контексте родительского контроля. Firewall Mangle подробно изучается на курсе MikroTik Certified Traffic Control Engineer (MTCTCE), тема требует внимательности и сосредоточенности. Разметим проходящий через маршрутизатор трафик:
В текстовом варианте они плохо представляются, поэтому объясним их по скриншоту. Как видно, трафик пользователей размечается на входящий (WAN => LAN) и исходящий (LAN => WAN).
На самом деле, так делать не нужно, ведь достаточно маркировать только исходящий трафик, потому что входящий – это всегда ответ на исходящий, в контексте домашнего устройства. TCP соединение устанавливается по инициативе пользователя, так же как и UDP пакеты к нам идут в ответ на наши запросы.
Итого нам нужно пометить весь исходящий трафик. Сразу будем выделять только детские соединения. Весь трафик разделим на четыре категории: DNS, HTTPS, QUIC и остальные соединения. DNS будем отлавливать в цепочки prerouting, сначала помечая соединения, затем пакеты в этих соединениях:
Чтобы понять, почему это нужно делать именно в prerouting, следует обратиться к схеме прохождения трафика внутри маршрутизатора MikroTik. Например, можно воспользоваться рисунком от этой компании.
Если первичным DNS сервером (/ip dhcp-server network add address=10.0.0.0/24 dns-server=10.0.0.1 gateway=10.0.0.1 netmask=24) будет выступать ваш роутер, то запросы от клиентов пойдут именно к нему, т. е. в Input Interface. Далее уже будем работать с цепочкой Forward. Помечаем все детские соединения. Среди них выделяем соединения HTTPS и QUIC:
Одинаково помечаем пакеты в HTTPS и QUIC соединениях, так как к ним будет применена одинаковая логика обработки:
Для самоконтроля, рекомендую на каждом этапе проводить зеркалирование пакетов и их ручную обработку в Wireshark (как настроить прием трафика, рассмотрено ранее):
Трафик размечен, теперь прикрутим сюда параметры блокировки. В Firewall Mangle во вкладке Advanced имеются следующие интересующие нас возможности: Content и TLS Hosts.
Параметр Content позволяет задать текст, который будет искаться во всех проходящих через маршрутизатор пакетах. В первую очередь, это подойдет для HTTP соединений по понятным причинам. Для HTTPS и QUIC это тоже работает. В качестве примера рассмотрим соединение с одним из сайтов, о которых нельзя говорить вслух:
Видно, что его доменное имя несколько раз проходит в устанавливаемом соединении. Используем его в качестве фильтра, для всех типов размеченных пакетов: DNS и остального трафика Именно поэтому нужна была перемаркеровка пакетов, выполненная ранее в цепочке Forward:
Конечно, такой анализ сильно грузит процессор роутера. Как видно, при срабатывании хотя бы одно из правил ставится запрет на дальнейшую перемаркировку трафика, что разгрузит маршрутизатор (passthrough=no).
Параметр TLS Hosts позволяет задать SNI или Server Name Indication – расширение популярного широко используемого криптографического протокола TLS. Смысл SNI в том, что если в настройках web сервера включена поддержка технологии, то на одном IP адресе может размещаться неограниченное количество сайтов, работающих по HTTPS. Изначально HTTPS можно было использовать только при наличии выделенного IP адреса. Если возникала необходимость разместить на сервере второй сайт, работа с которым была бы возможна по защищенному соединению, нужно было использовать другой белый IP. В современном мире, конечно, на одном сервере хостится огромное количество сайтов.
Рассмотрим как проверить SNI на сервере:
Наличие в выводе строки TLS server extension «server name» (id=0), len=0 будет означать, что SNI используется, и на сервере с одним IP адресом можно разместить любое количество сайтов. Таким образом, можно помечать пакеты на основании параметра TLS Hosts:
Запретим дальнейшую перемаркеровку пакетов (passthrough=no) и поставим эти правила перед правилами с параметром Content. Говорят, таким же образом работает великий китайский firewall, но при этом он умеет лезть еще глубже. Жалко пока нет технических подробностей.
Во вкладке Mangle Extra для решения поставленной задачи нам ничего не подойдет, увы…
Теперь соберем все правила Mangle воедино по следующей схеме:
Пакеты, помеченные как Children Filter, будем дропать в Firewall Filter. Иллюстрация ниже, взятая опять же у этих ребят, объясняет почему это нужно делать именно там, а не в результате, например, роутинга:
Блокирующее правило придется поставить самым первым в цепочке Forward, иначе пакеты, подлежащие фильтрации, перескочат через Firewall:
В результате ограничиваемые соединения будут просто прибиваться, браузер ребенка не сможет загрузить ничего из запрещенного контента.
Упомяну еще про /ip firewall layer7-protocol. Данный фильтр позволяет искать совпадения в первых 2 KB трафика (или 10 первых пакетах) по регулярным выражениям в ICMP, TCP и UDP потоках. Не рекомендую его использовать, слишком вероятностно все там работает и очень сильно загружает процессор роутера.
▍ 2. Заключение
RouterOS обладает различными возможностями по организации родительского контроля. В статьях представлены различные подходы: работа с DNS протоколом, Firewall Filter, Firewall Mangle и Kid-Control. Последний является средством автоматизации от MikroTik и не несет самостоятельных инженерных решений. Что же лучше использовать: работу с DNS, Firewall Filter или Firewall Mangle?
Работа DNS протокола неизбежна связана с кешированием, как на промежуточных серверах, так и на вашем роутере и даже в операционной системе. Нельзя сказать, чтобы это прямо-таки был минус, но нужно учитывать. Чтобы вы, как родитель, не подставили в DNS ответ, но до него дело может даже не дойти. Устройство ребенка извлечет IP адрес запрашиваемого ресурса из своего собственного хранилища. А вот то, что рано или поздно шифрованный DNS прочно войдет в нашу жизнь, нужно понимать уже сейчас. Поэтому в будущем актуальность эксплуатации собственных DNS серверов или коммерческих аналогов, по моему мнению, сохранится. Для данного подхода придется задействовать дополнительные технические ресурсы и, самое главное, поддерживать всю эту инфраструктуру в исправном и актуальном состоянии, что, скорее всего ляжет на ваши сисадминские плечи.
Дропать пакеты по IP адресу в Firewall Filter – достаточно топорное решение. Автоматический резолвинг доменных имен работает хорошо. Однако поле TLS Hosts в Firewall Mangle имеет перед ним сильное преимущество, так как позволяет фильтровать и субдомены. Ведь забивать их все в address-list совсем не хочется. А если на одном IP адресе окажется несколько сайтов, что было достаточно частой проблемой в период известных блокировок Роскомнадзора, то ничего хорошего из подобного подхода не выйдет. Грамотно разметить трафик в Firewall Mangle – это хороший навык, который позволяет решать много инженерных задач, в том числе таких как, приоритезация трафика и балансировка. Поэтому он мне нравится больше других.
Параметр Content может показаться исключительно хорошим решением, однако прогон толстого трафика через не достаточно сильный MikroTik по множеству фильтров может перегрузить центральный процессор роутера. Поэтому это остается последней мерой качественной фильтрации трафика.
В статье не рассмотрены подходы к блокировкам различных VPN, которые позволят перепрыгнуть через все описанные фильтры, потому как, считаю, это не относится к родительскому контролю.
Получается, что все описанные технические возможности хороши с определенными оговорками. Выбираем, что нравится больше и используем, а лучше все сразу. И потолще и побольше. Если вы действительно хотите организовать родительский контроль за трафиком ребенка. Но это уже не тема нашей статьи.
Что произойдет, если у меня истек срок действия дополнительного сертификата в цепочке с альтернативным путем доверия?
У меня есть сертификат, выданный Sectigo (бывший продукт Comodo Positive SSL). Это в хорошем состоянии и истекает через 1 год и 7 месяцев. Этот сертификат выдан Sectigo RSA Domain Validation Secure Server CA. В цепочке ЦС имеется два промежуточных сертификата, предоставленных поставщиком: ближайший ЦС Sectigo RSA Validation Secure Server и следующий промежуточный центр сертификации USERTrust RSA, срок действия которого истекает 30 мая 2020 года.
Промежуточный центр сертификации USERTrust RSA имеет очень близкий срок действия и подписан доверенными браузерами AddTrust External CA Root.
Между тем ближайший к моему промежуточному сертификату домена Sectigo RSA Domain Validation Secure Server CA подписан другим корнем с тем же именем USERTrust RSA Certification Authority, но это сертификат CA, отличный от упомянутого ранее. И этому руту доверяют обычные браузеры.
Я пытался проверить это с помощью средства проверки ssllabs.com. и я вижу, что сегодня все в порядке. Но я не понимаю о будущем. Что произойдет после 30 мая в случае, если я оставлю просроченное промежуточное звено в цепочке? Или лучше заранее исключить это промежуточное звено из цепочки?
2 ответа
Это позволяет Sectigo представить USERTrust RSA Certification Authority в качестве нового центра сертификации, в то время как они работают со всеми поставщиками приложений проверяющей стороны (браузерами и операционными системами в целом), чтобы обеспечить его добавление в их хранилище привязки доверия. Если они уверены, что ему все доверяют, AddTrust External CA Root является избыточным и может быть выведен из эксплуатации, что, по-видимому, запланировано на май 2020 года.
Этот день наступил. 30 мая 2020 года срок действия USERTrust RSA Certification Authority истек, и я вижу, что современные браузеры работают правильно, но большинство автоматических систем этого не делает (например, curl из консоли Ubuntu 18.04 LTS и из сценариев PHP и Ruby).
Один из распространителей SSL сказал:
Ранее они [Sectigo] заверили всех, что никаких проблем не будет. Однако реальность такова, что это влияет на некоторые устаревшие серверы / устройства.
Это нелепая ситуация. Мы обратили их внимание на истекающий срок действия AddTrust RSA / ECC несколько раз в течение года, и каждый раз, когда Sectigo уверял нас, никаких проблем не будет.
Правильные цепочки в моем случае (продукт Sectigo DV / Positive SSL):
Проблема с сертификатами Sectigo после 30 мая 2020 года и метод решения
В субботу 30 мая 2020 года возникла не сразу понятная проблема с популярными SSL/TLS сертификатами от вендора Sectigo (бывший Comodo). Сами сертификаты продолжали оставаться в полном порядке, однако «протух» один из промежуточных CA-сертификатов в цепочках, с которыми поставлялись данные сертификаты. Ситуация не сказать, чтобы фатальная, но неприятная: актуальные версии браузеров ничего не заметили, однако большая часть автоматизаций и старых браузеров/ОС оказались не готовыми к такому повороту.
Хабр не стал исключением, поэтому и написан этот ликбез / postmortem.
TL;DR Решение в самом конце.
Опустим базовую теорию про PKI, SSL/TLS, https и прочее. Механика удостоверения сертификатом безопасности домена состоит в построении цепочки из ряда сертификатов до одного из доверенных браузером или операционной системой, которые хранятся в так называемом Trust Store. Этот список распространяется с операционной системой, экосистемой среды исполнения кода или с браузером. Любые сертификаты имеют срок действия, по истечении которого они считаются недоверенными, в том числе сертификаты в trust store. Как выглядела цепочка доверия до наступления рокового дня? Разобраться нам поможет web-утилита SSL Report от компании Qualys.
Итак, одним из самых популярных «коммерческих» сертификатов является Sectigo Positive SSL (ранее разывался Comodo Positive SSL, сертификаты с этим наименованием ещё в ходу), он является так называемым DV-сертификатом. DV — это самый примитивный уровень сертификации, означающий проверку доступа к управлению доменом у выпускающего такой сертификат. Собственно, DV и расшифровывается как «domain validation». Для справки: ещё есть OV (organization validation) и EV (extended validation), а бесплатный сертификат от Let’s Encrypt тоже DV. Для тех, кому по какой-либо причине не устраивает механизм ACME, продукт Positive SSL является самым подходящим по соотношению цена/возможности (однодоменный сертификат стоит около 5-7 долларов за год с суммарным сроком действия сертификата до 2 лет и 3 месяцев).
Типовой сертификат Sectigo DV (RSA) до недавнего времени поставлялся с такой цепочкой промежуточных CA:
Здесь отсутствует «третий сертификат», самоподписной от AddTrust AB, так как в какой-то момент времени стало считаться правилом плохого тона включать в цепочки самоподипсанные корневые сертификаты. Можно обратить внимание, что промежуточный CA, выданный UserTrust от AddTrust имеет срок действия 30 мая 2020 года. Это не спроста, так как для данного CA была запланирована процедура вывода из эксплуатации. Считалось, что к 30 мая 2020 года во всех trust store уже к этому времени появится кросс-подписанный сертификат от UserTrust (под капотом это один и тот же сертификат, вернее публичный ключ) и цепочка, даже с включенным недоверенным уже сертификатом будет иметь альтернативные пути построения и никто этого не заметит. Однако, планы разбились о реальность, а именно пространный термин «legacy systems». Действительно, владельцы актуальных версий браузеров ничего не заметили, однако сломалась гора автоматизаций, построенных на curl и ssl/tls-библиотеках ряда языков программирования и сред исполнения кода. Надо понимать, что многие продукты не руководствуются встроенными в ОС средствами построения цепочек, а «носят» свой trust store с собой. И не всегда они содержат то, что хотело бы видеть CA/Browser Forum. Да и в Linux далеко не всегда обновляются пакеты типа ca-certificates. В итоге всё вроде в порядке, но что-то не работает то там, то здесь.
По рисунку 1 понятно, что хоть и у подавляющего большинства всё выглядело как обычно, у кого-то что-то сломалось и трафик заметно просел (левая красная черта), потом он подрос, когда заменили один из ключевых сертификатов (правая черта). Были всплески и посередине, когда меняли иные сертификаты, от которых тоже что-то зависело. Так как у большинства визуально всё продолжало работать более-менее штатно (за исключением странных глюков типа невозможности загрузки картинок на Habrastorage), можно сделать косвенный вывод о количестве legacy-клиентов и ботов на Хабре.
Рисунок 1. График «трафика» на Хабре.
По рисунку 2 можно оценить, как строится в актуальных версиях браузеров «альтернативная» цепочка до доверенного CA-сертификата в браузере пользователя, даже при наличии «протухшего» сертификата в цепочке. Это, как считала сама Sectigo, тот самый повод не делать ничего.
Рисунок 2. Цепочка до доверенного сертификата современной версии браузера.
А вот на рисунке 3 можно заметить, как всё выглядит на самом деле, когда что-то пошло не так и у нас legacy система. В таком случае соединение HTTPS не устанавливается и мы видим ошибку типа «certificate validation failed» или подобную ей.
Рисунок 3. Цепочка инвалидировалась, так как корневой сертификат и подписанный им промежуточный «протухли».
На рисунке 4 мы уже видим «решение» для legacy систем: есть ещё один промежуточный сертификат, вернее «кросс-подпись» от иного CA, который как правило предустановлен в legacy системах. Это то, что нужно сделать: найти этот сертификат (который помечен как Extra download) и заменить им «протухший».
Рисунок 4. Альтернативная цепочка для legacy систем.
К слову: у проблемы не было широкой огласки и какого-то общественного обсуждения, в том числе из-за излишней самонадеянности Sectigo. Вот, например, мнение одного из поставщиков сертификатов в отношении к данной ситуации:
Previously they [Sectigo] assured everyone that no issues will be. However, the reality is that some legacy servers/devices are affected.
That is a ridiculous situation. We pointed their attention to the expiring AddTrust RSA/ECC multiple times within a year and each time Sectigo assured us no issues will be.
Я лично задавал вопрос на Stack Overflow на этот счёт месяц назад, но судя по всему, аудитория проекта не очень подходящая для таких вопросов, так что пришлось не него ответить самостоятельно по факту разбора.
Sectigo выпустил на этот счёт FAQ, но он настолько нечитабельный и пространный, что пользоваться им невозможно. Вот цитата, являющаяся квинтэссенцией всей публикации:
What You Need to Do
For most use cases, including certificates serving modern client or server systems, no action is required, whether or not you have issued certificates cross-chained to the AddTrust root.
As of April 30, 2020: For business processes that depend on very old systems, Sectigo has made available (by default in the certificate bundles) a new legacy root for cross-signing, the “AAA Certificate Services” root. However, please use extreme caution about any process that depends on very old legacy systems. Systems that have not received the updates necessary to support newer roots such as Sectigo’s COMODO root will inevitably be missing other essential security updates and should be considered insecure. If you would still like to cross-sign to the AAA Certificate Services root, please contact Sectigo directly.
Очень нравится тезис «very old», конечно. Например, curl в консоли Ubuntu Linux 18.04 LTS (нашей базовой ОС на данный момент) с последними обновлениями не старше месяца, сложно назвать very old, однако оно не работает.
Большинство дистрибьютеров сертификатов выпустили свои заметки с решениями ближе к вечеру 30 мая. Например, очень годная в техническом плане от NameCheap (с конкретным описанием что делать и с готовыми сборками CA-bundles в zip-архивах, но только RSA):
Рисунок 5. Семь шагов, чтобы быстро всё починить.
Есть неплохая статья от Redhat, но там всё более Legacy и нужно инсталлировать даже ещё более корневой legacy сертификат от Comodo, чтобы всё работало.
Решение со стороны сервера
Стоит продублировать решение ещё и тут. Ниже располагаются два набора цепочек для сертификатов DV Sectigo (не Comodo!), одна для привычных RSA сертификатов, другая для менее привычных ECC (ECDSA) сертификатов (мы используем две цепочки достаточно давно). С ECC было сложнее, так как большинство решений не учитывает наличие таких сертификатов в силу их малой распространённости. В итоге, нужный промежуточный сертификат был найден на crt.sh.
Цепочка для сертификатов, основанных на алгоритме ключа RSA. Сравните со своей цепочкой и обратите внимание, что заменился только нижний сертификат, а верхний остался прежним. Я их отличаю в бытовых условиях по последним трём символам блоков base64 не считая символа «равно» (в данном случае En8= и 1+V ):
Цепочка для сертификатов, основанных на алгоритме ключа ECC. Аналогично с цепочкой для RSA, заменился только нижний сертификат, а верхний остался прежним (в данном случае fmA== и v/c= ):
Решение со стороны клиента
Внимание! Тут далее по тексту размещаются сертификаты безопасности и предложения их импортировать в систему. Это референс! Не надо бездумно импортировать их в trust store и делать доверенными. Мы в Интернете и тут нельзя никому доверять (даже Хабру, sad but true)! Если просто импортировать промежуточные сертификаты, как правило, достаточно безопасно (не делая их вручную «доверенными», они наследуют доверие сами и без вас), то импортировать самоподписные руты надо строго включая мозг и сверяя отпечатки сертификатов с эталонными значениями, указанными на сайтах вендоров сертификатов. Praemonitus, praemunitus.
Как правило, если владелец сервера с проблемным сертификатом уже заменил цепочку, то на стороне клиента делать ничего не нужно, так как недостающий промежуточный сертификат имеет кросс-подпись от достаточно старого CA, который с большей долей вероятности уже был заботливо предустановлен в trust store даже сильно legacy-системы при царе Горохе. И всё должно работать.
Но бывают случаи, что владелец сервера либо не в курсе проблемы, либо не обладает должной компетенцией для её решения, либо решать проблему банально некому, ибо сервер на лютом аутсорсе, и всем в принципе наплевать (что-то на уровне проблемы индейцев и шерифа). А попасть на такой сервер надо из-под системы не первой свежести. Как показали комментарии, к сожалению, такие случаи определённо носят достаточно массовый характер.
Есть известная проблема реализации построения цепочек PKI в ряде старых крипто-библиотек (некотоорые версии OpenSSL и GnuTLS, например), которые банально не умеют строить множество цепочек от нескольких доверенных якорей к конечному сертификату. То есть, они воспринимают цепочку доверия как линейную сущность, а не направленный граф. Первой помощью в таких системах будет удаление из trust store или отключение почившего корневого сертификата AddTrust External CA Root. Выглядит он так:
Конечно, хорошим подспорьем будет обновить OpenSSL, например, в случае проблем именно с этой библиотекой. Но зачастую это практически невозможно, ибо мало заменить библиотеку с удовлетворением зависимостей, надо ещё и пересобрать софт, использующий эту библиотеку. Для большинства это непреодолимый квест и практически гарантированная возможность доломать систему до конца. В случае GnuTLS также гарантировано отдельное развлечение, местами даже пободрее, чем с OpenSSL. Весьма подробная заметка на OpenNET.
Далее, сделует проверить, что тот самый престарелый, но действительный сертификат AAA Certificate Services от Comodo, выпустивший в качестве подорожника кросс-подпись, наличествует в trust store ОС или браузера клиента. Идентифицировать его можно по следующим атрибутам:
Если такой сертификат отсутствует, то надо его импортировать в trust store и сделать доверенным. Без него не будет вообще работать ничего, даже если владелец сервера выполнит рекомендации. Но повторюсь: он должен быть в поодавляющем числе trust store систем и браузеров.
Далее, вторым шагом может стать импорт пачки промежуточных сертификатов, покрывающих большую часть случаев битой цепочки со стороны клиента. На самом деле, упомянутый выше «дедушка» сертификатов наплодил немало дочерних CA, с полным списком можно ознакомится внизу этой страницы. Но нам все не нужны, нам нужно только четыре. Два для продуктов под брендом Comodo и два для продуктов под брендом Sectigo, в каждой паре один для сертификатов, основанных на ключе RSA, а второй для ECDSA.
USERTrust RSA Certification Authority (под ним «ходят» разные промежуточные сертификаты RSA Sectigo):
USERTrust ECC Certification Authority (под ним «ходят» разные промежуточные сертификаты ECDSA Sectigo):
COMODO RSA Certification Authority (под ним «ходят» разные промежуточные сертификаты RSA Comodo, ещё не выведенные из эксплуатации):
COMODO ECC Certification Authority (под ним «ходят» разные промежуточные сертификаты ECDSA Comodo, ещё не выведенные из эксплуатации):
По идее, после таких манипуляций всё должно заработать. Разные операционные системы имеют разные механизмы шатания их trust store, в каждом конкретном случае надо обращаться к документации, как это делается. Надо отдать должное, этот случай достаточно сильно переполошил веб и большинство мэйнтейнеров ОС и иных систем выпустили свои FAQ, которые легко ищутся по ключевым словам fix sectigo certificate issue in << system_name >> или схожим в большинстве поисковиков.
Устанавливаем SSL: какой сертификат выбрать?
Каждый владелец сайта должен помнить о безопасности данных в интернете. От ваших действий напрямую зависит, будут ли ваши данные и данных ваших пользователей в сохранности, сможет ли мошенник получить доступ к вашему сайту, сможете ли вы обеспечить безопасную передачу информации.
Что такое SSL и HTTPS
SSL, или Secure Sockets Layer («уровень защищенных сокетов»), это протокол, который обеспечивает защищенный обмен данными. Благодаря шифрованию и аутентификации (проверки подлинности идентификатора) передача данных идет через безопасный канал, то есть пользователю не нужно волноваться о том, что информация, которую он передает, может попасть не в те руки.
Активное использование SSL привело к тому, что в 2000 году появился протокол Hypertext Transfer Protocol Secure («защищенный гипертекстовый протокол для передачи данных»), сокращенно HTTPS; он является расширением протокола передачи данных HTTP. 
Использование HTTPS на сайте позволяет безопасно передавать данные от одного компьютера к другому. Проще говоря, все данные, которые вы передадите, будут надежно защищены, и никто не сможет их «подслушать». Это особенно важно в ситуациях с онлайн-оплатой, когда пользователи вводят номера своих банковских карточек и, конечно же, не хотят, чтобы они попали к злоумышленникам.
Наличие SSL-сертификата на сайте – это гарантия того, что данные защищены и не попадут в чужие руки. Это важно как для пользователей, так и для владельцев сайтов.
Еще пару лет назад перевод сайта на HTTPS был скорее личным желанием, чем необходимостью, но сейчас, с развитием виртуальной сети, забота о безопасности данных все больше волнует глобальные корпорации – и теперь сайты, которые еще не перешли на защищенный протокол передачи данных, помечаются как небезопасные.
Что сделать, чтобы ваш сайт начал работать по безопасному протоколу? Установить специальный SSL-сертификат. Сейчас существует несколько компаний, которые выдают подобные сертификаты, о двух самых популярных расскажем ниже.
Seсtigo
Sectigo – один из самых крупных поставщиков SSL-сертификатов на сегодняшний день. Многие уже знакомы с продуктами этой компании: до ноября 2018 года они выпускались под названием Comodo. В результате ребрендинга изменилось название и логотип, но в техническом плане компания осталась одним из лидеров рынка сертификатов. За более чем 20 лет работы по всему миру было продано свыше 100 млн сертификатов. 
Наша компания предлагает 3 основных варианта сертификатов от Sectigo:
Функции у этих сертификатов разные, как и стоимость.
Начнем с самого бюджетного – Sectigo Positive SSL. Это стандартный SSL-сертификат, который можно смело рекомендовать всем, кто хочет перевести свой сайт на HTTPS. Sectigo Positive SSL предлагает проверку домена начального уровня. Это самый распространенный вид сертификата, он требует лишь подтверждение владения доменом, без предоставления других документов. Sectigo Positive SSL может заказать любое физическое или юридическое лицо, процесс получения сертификата и установки его на сайт занимает всего несколько часов.
Второй сертификат, который можно приобрести, – Sectigo EV SSL. Это сертификат расширенной проверки (EV сокращение от “extended validation”). В этом случае центры сертификации устанавливают владельца сайта и подтверждают, что домен действительно принадлежит этой компании или юридическому лицу. Браузеры отмечают такие сайты зеленым выделением, а также указывают название компании перед доменом. Если сайт принадлежит крупной компании, на нем каждый день происходит много финансовых операций, то есть смысл задуматься о приобретении именно этого SSL-сертификата.
Из-за расширенной проверки выпуск EV SSL-сертификатов занимает больше времени, чем приобретение других сертификатов, но в итоге вы получаете один из самых востребованных и надежных SSL-сертификатов, который повышает доверие пользователей и помогает увеличить продажи.
Наконец, есть третий вид сертификата, он называется Sectigo Postitive Wildcard SSL. Он используется в качестве единого сертификата для домена и нескольких поддоменов. То есть вместо того, чтобы устанавливать отдельный сертификат на каждый поддомен, вы можете просто купить Sectigo Postitive Wildcard SSL и установить его сразу и на домен, и на любое количество поддоменов. При этом оформление занимает примерно столько же времени, сколько и обычного Sectigo Positive SSL.
Sectigo Postitive Wildcard SSL – идеальный вариант для сайтов с большим количеством региональных поддоменов, а также проектов, которые размещают на поддоменах отдельные разделы своего сайта: блог, форум, личный кабинет и так далее.
Вне зависимости от того, какой вид SSL-сертификата Sectigo вы выберите в итоге, все они отличаются высокой степенью защиты данных, а также следующими важными моментами:
На сегодняшний день сертификаты Sectigo это одни из самых надежных сертификатов, предоставляющих высокий уровень защиты данных и обладающими всеми ключевыми чертами качественного SSL-сертификата.
Let’s Encrypt
Тем, кто ищет некоммерческую альтернативу, стоит обратить внимание на Let’s Encrypt. Этот центр сертификации начал свою работу в 2015 году и уже в 2017 похвастался выпуском своего 100-миллионного сертификата. Причина такой популярности проста: сертификаты Let’s Encrypt бесплатны, легко устанавливаются и не требуют сложных настроек.
Но есть несколько нюансов, о которых стоит знать перед установкой этого сертификата. Срок его действия составляет 90 дней; после этого сертификат необходимо продлевать.
Let’s Encrypt нормально работает в большинстве браузеров и систем, но с некоторыми системами этот сертификат не совместим.
Так как это бесплатный продукт, его создатели не предоставляют никаких гарантий в тех случаях, когда что-то может пойти не так.
В остальном это неплохой вариант бесплатного SSL-сертификата.
Как подключить SSL-сертификат
Самый приятный момент – подключить SSL-сертификат в компании Timeweb очень легко. Вы можете либо самостоятельно заказать его в панели управления аккаунтом, либо просто написать обращение в службу поддержки, а дальше все необходимые действия выполнят наши специалисты. Время создания сертификата зависит от его типа, но, как правило, занимает не более нескольких часов. Исключение – сертификат Sectigo EV SSL, который из-за проверки данных оформляется дольше.
Если после прочтения статьи вы все еще не определились, какой сертификат хотите приобрести, оставьте заявку на оформление SSL-сертификата в панели управления аккаунтом или в чате на нашем сайте Timeweb, мы с радостью вам поможем!