В чём фишка HTTPS, или зачем мне SSL-сертификат?

Как обновить SSL-сертификат сайта

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

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

• Chrome помечает все сайты на HTTP как небезопасные
• Перевод сайта на HTTPS
• Чем отличаются SSL-сертификаты: самоподписанные, Let’ Encrypt, от центров сертификации
• Чем отличается HTTP от HTTPS

Зачем нужна проверка SSL-сертификата

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

В зависимости от уровня проверки, выделяют соответствующие типы сертификатов. Они отличаются длительностью выпуска, ценой и уровнем надёжности. Рассмотрим каждый вид отдельно.

Валидация домена (DV)

Валидация домена (DV) — базовый уровень проверки SSL-сертификата. Сертификаты с DV-проверкой подходят для простых информационных сайтов, которые не принимают оплату online. Сертификационный центр проверяет, что у заказчика есть доступ к доменному имени.

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

Сертификат, ограниченный DV-проверкой, дешевле прочих, а получить его можно за 10 минут.

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

Расширенная проверка (EV)

Расширенная проверка (EV), как и OV-проверка, нужна, чтобы убедиться в подлинности организации, которая запросила сертификат. Перед тем, как выдать ЕV-сертификат, сертификационный центр выполняет дополнительную проверку: он может запросить учредительные документы или позвонить по номеру телефону организации, указанному в одном из публичных справочников. Поэтому получение сертификата EV занимает до 14 дней и обходится дороже. Но и доверия к нему больше. Этот вариант подходит для крупных организаций, которым важна респектабельность, например, банкам, известным брендам или государственным учреждениям.

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

Принцип работы TLS[править]

Протокол TLS делится на два слоя: TLS Record и TLS Handshake.

Подтверждение связи (handshake)править

1. Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (англ. CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
2. Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
3. Клиент проверяет сертификат сервера.
4. Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
5. Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
6. Сервер проверяет сертификат клиента.
7. Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
8. Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
9. Аналогичные действия производит сервер.
10. На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.

Возобновление сессииправить

1. Клиент посылает сообщение ClientHello, используя ID сессии, которую нужно возобновить.
2. Сервер проверяет, есть ли у него в кэше соответствующий идентификатор. Если есть и сервер способен возобновить сессию, он отсылает клиенту сообщение ServerHello с этим же ID сессии. Если нет, сервер генерирует новый ID сессии и выполняет процедуру handshake с клиентом.
3. Клиент и сервер обмениваются сообщениями ChangeCipherSpec, а затем Finished.
4. Передача данных по защищенному каналу возобновляется.

Протокол записи (TLS Record)править

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

• Разбиение исходящих сообщений на блоки нужного размера и «склеивание» входящих сообщений.
• Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
• Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
• Шифрование исходящих сообщений и дешифровку входящих.

После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

• Content type: тип сообщения — подтверждение связи (22), обычное сообщение (23) или оповещение (21).
• Version: версия SSL/TLS.
• Length: длина оставшейся части сообщения.
• Payload: собственно зашифрованные данные.
• MAC: код аутентификации.
• Padding: «отступ» для получения нужного размера сообщения.

Обычно люди пользуются такими сертификатами как:

SSL-сертификаты с проверкой домена, или как их некоторые называют, сертификаты начального уровня, являются самыми распространёнными в мире, и это не удивительно, ведь скорость выдачи таких сертификатов варьируется от 2-10 минут, зависит от бренда. Что бы получить такой сертификат не требуются какие либо документы, весь процесс предельно прост, Вам нужно подтвердить владение доменом, а для этого существует 3 способа, один основной и два альтернативных.
SSL-сертификаты начального уровня с проверкой домена один из самых быстро-выдаваемых типов сертификатов, т.к. не требуют каких либо документов. Мы рекомендуем данные сертификаты для небольших сайтов и маленьких проектов, когда у Вас нет необходимости в большом доверии со стороны клиентов и посетителей сайта, проекта. С таким сертификатом чаще идут статичные логотипы безопасности, однако есть некоторые которые предлагают и динамические, например: Thawte SSL 123, Comodo SSL Certificate Данный метод описан на многих сайтах и блогах, вся суть в том, что центр сертификации вышлет Вам верификационное письмо, в котором будет ссылка для подтверждения владением домена. Выслать такое письмо могут либо на э-почту указанную во Whois вашего домена, либо на один из золотой пятёрки: admin@, administrator@, hostmaster@, postmaster@,webmaster@
Достаточно популярный метод, для тех у кого может не быть настроен майл-сервер, а э-почта во Whois закрыты приватной регистрацией. Суть проста, вы должны сделать особую запись в Вашем DNS, и центр сертификации его проверит. Метод полностью автоматический.
Ещё более простой метод, Вам будет предоставлен специальный .txt файл, который вы должны будите загрузить на Ваш сервер, центр сертификации убедится в его наличии и сертификат будет выдан. Метод полностью автоматический.

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

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

Он может защитить любое кол-во субдоменов, на неограниченном кол-ве серверов. Больше не нужно устанавливать 5-10-20 разных сертификатов, иметь столько же IP адресов (если не использовать технологию SNI), всё в рамках одного продукта. Часто их так же используют для обеспечения безопасности хостинг панелей, таких как Plesk, cPanel.
Единые сертификаты связи (UCC), Мульт-доменные сертификаты, SAN SSL-сертификаты, как их только не называют, но всех их объединяет одно свойство, способность защищать множество доменов, субдоменов, локальных доменов (.local), сервера (server name: ‘myserver01’), они идеальны для продуктов Microsoft Exchange. Данные сертификаты работают как с внешними, так и внутренними доменными именами.
Сегодня, о данных сертификатах уже можно забыть, хотя их продолжают использовать, т.к. они принудительно увеличивают уровень шифрования для старых браузеров с 40-бит до полноценных 256-бит. Ваш сайт или онлайн система будет защищена и получит высочайшее доверие от всех Ваших пользователей. Лучшие сайты используют 128/256-битное шифрование.
Этот сертификат Вам понадобится, когда ваши пользователи получают предупреждения и ошибки при скачивании программного кода с ваших ресурсов.Идеальный продукт для разработчиков программного обеспечения (ПО), он используется для защиты программных продуктов распространяемых в сети. Ваши пользователи будут уверены что код скачанный на вашем сайте действительно принадлежит Вам, а не является умышленно испорченным или изменённым

SSL-СЕРТИФИКАТЫ

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

С 2018 года большинство современных браузеров помечают интернет-сайты, которые не передают данные, зашифрованные с помощью SSL-сертификатов, красным значком опасности. Требования к стойкости шифрования постепенно ужесточаются, и современными стандартами шифрования являются использование протокола TLS 1.2.

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

Чем грозит истекший срок действия SSL-сертификата?

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

Браузер Chrome выдаст вот такую заставку и не пропустит пользователя дальше:

Предупреждение про устаревший сертификат в браузере Chrome

Согласитесь, не самое желанное предупреждение для пользователей.

А у браузера Firefox заставка будет еще более мрачной:

Попытка зайти на сайт с устаревшим сертификатом в браузере Firefox

Мало кто из пользователей начнет разбираться в серьезности таких предупреждений. Скорее всего, они просто не посетят ресурс.

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

Как следствие двух первых пунктов, на сайте упадет уровень продаж и/или конверсия рекламы.

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

Сертификаты SSL и TLS: зачем они нужны

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

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

SSL расшифровывается как Secure Socket Layer, что означает «уровень защищенных сокетов». TLS же обозначается как Transport Layer Security, «безопасность транспортного уровня». По своей сути обе технологии занимаются одним делом – защитой пользовательской информации от злоумышленников. 

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

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

Как пользоваться s_client

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

Выполнив SSL/TLS подключение, s_client позволяет вводить данные, например, отправлять заголовки HTTP протокола, команды SMTP, FTP и т.д.

Для подключения к удалённому хосту укажите адрес домена и порт (обычно это 443) с опцией -connect:

openssl s_client -connect yandex.ru:443

Вы увидите:

1. верификацию и цепочку сертификатов

2. сертификат сайта

3. данные текущей сессии — SSL/TLS (ассиметричное шифрование) используются для обмена ключом для симметричного шифрования, поскольку ассиметричное слишком «затратное». И фактический шифрование данных будет выполняться «паролем» (ключами сессии, а не сертификатом). Эти ключи меняются при каждой новой сессии.

То есть, компрометация приватного ключа сервера ≠ расшифровка трафика. Поскольку необходимо знать все ключи сессии. Раньше, зная приватный ключ сервера, можно было расшифровать SSL трафик — сначала расшифровывались ключи сессии, а затем они использовались для расшифровки данных. Но теперь используется Perfect Forward Secrecy (которая применяет Diffie-Hellman key exchange (DH)), что привело к тому, что третья сторона, даже зная приватный ключ RSA (приватный ключ сервера), не сможет расшифровать TLS трафик.

Решение со стороны клиента

Внимание! Тут далее по тексту размещаются сертификаты безопасности и предложения их импортировать в систему. Это референс! Не надо бездумно импортировать их в 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, которые легко ищутся по ключевым словам или схожим в большинстве поисковиков.

Вот примерно всё так

Спасибо за внимание

Файловая проверка SSL-сертификата сайта

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

Пример содержимого файла сертификата безопасности

Даже если сталкивались с подобной кодировкой (base64), пытаться раскодировать не стоит — внутри закодирована бинарная структура, разбор которой потребует весьма нетривиальных усилий.

Решается эта задача весьма просто: обычным двойным кликом по файлу. CRT формат далеко не новое изобретение и многие операционные системы его поддерживают и позволяют просмотреть данные. Вот такой результат будет на MS Windows:

Окно свойств файла сертификата безопасности в MS Windows 10

На Ubuntu Linux будет похожее окно с детализацией свойств сертификата:

Просмотр свойств сертификата в Ubuntu Linux

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

Проверка сертификата SSL

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

Данные об SSL

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

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

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

Как видеть все сертификаты, которые отправляет HTTPS сервер

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

Чтобы увидеть все сертификаты, которые отправил сервер, используйте опцию -showcerts:

openssl s_client -showcerts -connect yandex.ru:443

Для yandex.ru будет выведено 3 сертификата: 1 сертификат сайта и 2 промежуточных.

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

openssl s_client -showcerts -connect yandex.ru:443 </dev/null

Чтобы сохранить сертификат сайта в файл используйте следующую команду (дважды замените w-e-b.site на интересующий вас домен):

echo | openssl s_client -connect w-e-b.site:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > w-e-b.site.crt

Если вы хотите сохранить всю присылаемую цепочку сертификатов, то сделайте так (дважды замените w-e-b.site на интересующий вас домен):

echo | openssl s_client -showcerts -connect w-e-b.site:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > w-e-b.site.ca-bundle

Процедура проверки сертификата

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

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

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