Бесплатный HTTPS-сертификат: инструкция по получению
Если вы собираете любую важную информацию на своем веб-сайте (включая электронную почту и пароль), то вам нужно быть в безопасности. Один из лучших способов обезопасить себя – включить HTTPS сертификат, также известный как SSL (уровни защищенных сокетов), чтобы вся информация, поступающая на ваш сервер и исходящая из него, автоматически шифровалась. HTTPS сертификат предотвращает взлом хакерами конфиденциальной информации ваших пользователей при хранении оной в интернете. Они будут чувствовать себя в безопасности, когда увидят HTTPS сертификат при доступе к вашему сайту, – зная, что он защищен сертификатом безопасности.
Преимущества HTTPS сертификата
Самое лучшее в SSL сертификате, как и в HTTPS – это то, что его просто настроить, и как только это будет сделано, вам нужно будет направить людей на использование сертификата HTTPS вместо HTTP. Если вы попытаетесь получить доступ к своему сайту, разместив https: // перед вашими URL прямо сейчас, вы получите сообщение об ошибку HTTPS сертификата. Это потому, что вы не установили SSL сертификат HTTPS. Но не волнуйтесь – мы проведем настройку прямо сейчас!
Ваши посетители будут чувствовать себя безопаснее на вашем сайте, когда они увидят HTTPS сертификат при доступе к вашему сайту — зная, что он защищен сертификатом безопасности.
Что такое HTTPS?
HTTP или HTTPS отображаются в начале каждого URL-адреса веб-сайта в веб-браузере. HTTP – это протокол передачи гипертекста, а S в HTTPS – Secure. В общем, это описывает протокол, по которому данные отправляются между вашим браузером и веб-сайтом, который вы просматриваете.
Сертификат HTTPS гарантирует, что вся связь между вашим браузером и веб-сайтом, который вы просматриваете, зашифрована. Это означает, что это безопасно. Только принимающие и отправляющие компьютеры могут видеть информацию при передаче данных (другие могут получить к ней доступ, но не смогут ее прочитать). На защищенных сайтах веб-браузер отображает значок замка в области URL-адреса, чтобы уведомить вас.
HTTPS должен быть на любом веб-сайте, который собирает пароли, платежи, медицинскую информацию или другие конфиденциальные данные. Но что, если вы можете получить бесплатный и действительный сертификат SSL для своего домена?
Как работает защита веб-сайта?
Чтобы включить сертификат безопасности HTTPS, вам необходимо установить SSL (Secure Socket Layer). Он содержит открытый ключ, который необходим для безопасного начала сеанса. Когда запрашивается HTTPS-соединение с веб-страницей, сайт отправляет сертификат SSL в ваш браузер. Затем они инициируют «рукопожатие SSL», которое включает в себя разделение «секретов» для установления безопасного соединения между вашим браузером и веб-сайтом.
Стандартный и расширенный SSL
Если сайт использует стандартный сертификат SSL, вы увидите значок замка в области URL-адреса браузера. Если используется сертификат расширенной проверки (EV), адресная строка или URL-адрес будут зелеными. Стандарты EV SSL превосходят стандарты SSL. EV SSL обеспечивает удостоверение личности владельца домена. Получение сертификата EV SSL также требует от претендентов пройти строгий процесс оценки, чтобы подтвердить их подлинность и право собственности.
Что будет если использовать HTTPS без сертификата?
Даже если ваш веб-сайт не принимает и не передает конфиденциальные данные, существует несколько причин, по которым вы можете захотеть иметь защищенный веб-сайт и использовать бесплатный и действительный сертификат SSL для своего домена.
Представление. SSL может улучшить время, необходимое для загрузки страницы.
Поисковая оптимизация (SEO). Цель Google заключается в том, чтобы интернет был безопасным и безопасным для всех, а не только для тех, кто использует Google Chrome, Gmail и Диск, например. Компания заявила, что безопасность будет фактором того, как они ранжируют сайты в результатах поиска. Пока этого мало. Однако, если у вас есть защищенный веб-сайт, а ваши конкуренты этого не делают, ваш сайт может получить более высокий ранг, что может быть необходимо для увеличения его популярности со страницы результатов поиска.
Если ваш сайт не защищен и он собирает пароли или кредитные карты, то пользователи Chrome 56 (выпущенного в январе 2017 года) будут видеть предупреждение о том, что сайт небезопасен. Посетители, не знакомые с технологией, (большинство пользователей веб-сайта) могут быть встревожены, увидев окно «ошибка HTTPS сертификата», и покинуть ваш сайт, просто потому, что не понимают, что это значит. С другой стороны, если ваш сайт защищен, это может сделать посетителей более непринужденными, что повысит вероятность того, что они заполнят регистрационную форму или оставят комментарий на вашем сайте. У Google есть долгосрочный план, чтобы показать все HTTP-сайты как небезопасные в Chrome.
Где можно получить бесплатный HTTPS сертификат?
Вы получаете SSL-сертификат от центра сертификации. Такие сертификаты действительны в течение 90 дней, но рекомендуется продление на 60 дней. Некоторые надежные бесплатные источники:
- Cloudflare: бесплатный для личных сайтов и блогов.
- FreeSSL: бесплатный для некоммерческих организаций и стартапов на данный момент; не может быть клиентом Symantec, Thawte, GeoTrust или RapidSSL.
- StartSSL: сертификаты действительны в течение от 1 до 3 лет.
- GoDaddy: сертификаты для проектов с открытым исходным кодом, действительны в течение 1 года.
Тип сертификата и срок его действия зависят от источника. Большинство органов власти предлагают стандартные сертификаты SSL бесплатно и взимают плату за сертификаты EV SSL, если они их предоставляют. Cloudflare предлагает бесплатные и платные планы и различные дополнительные опции.
Что нужно учитывать при получении сертификата SSL?
Здесь Google рекомендует сертификат с 2048-битным ключом. Если у вас уже есть 1024-битный сертификат, который слабее, он рекомендует его обновить.
Вам нужно будет решить, нужен ли вам один, несколько доменов или групповой сертификат:
- Один сертификат будет использоваться для одного домена (например, www.example.com).
- Многодоменный сертификат будет использоваться для нескольких хорошо известных доменов (например, www.example.com, cdn.example.com, example.co.uk).
- Сертификат подстановочного знака будет использоваться для безопасного домена со многими динамическими субдоменами (например, a.example.com, b.example.com).
Как установить сертификат SSL?
Ваш веб-хостинг может установить сертификат бесплатно или за отдельную плату. У некоторых хостов фактически есть опция установки Let’s Encrypt в своём личном кабинете cPanel, что упрощает работу. Запросите у своего текущего хоста или найдите тот, который предлагает прямую поддержку Let’s Encrypt. Если хост не предоставляет эту услугу, ваша компания по обслуживанию веб-сайта или разработчик могут установить сертификат для вас. Вы должны быть готовы к тому, что вам придется обновлять сертификат очень часто. Проверьте таймфрейм с сертификатом.
Что еще нужно сделать?
После получения и установки SSL-сертификата вам необходимо принудительно применить SSL на сайте. Опять же, вы можете попросить ваш веб-хост, компанию по обслуживанию или разработчика выполнить данное действие. Однако если вы предпочитаете делать это самостоятельно, и ваш сайт работает на WordPress, вы можете сделать это путем загрузки, установки и использования плагина. При последнем варианте обязательно проверяйте совместимость с вашей версией WordPress.
Два популярных плагина для принудительного использования SSL: простой SSLWP, принудительный SSLSSL-плагин. Обязательно создайте резервную копию своего сайта и будьте очень осторожны при выполнении этого. Если вы неверно настроите что-то, это может иметь плачевные последствия: посетители не смогут увидеть ваш сайт, изображения не отображаются, скрипты не загружаются, что повлияет на то, как некоторые вещи на вашем сайте функционируют, например, типографика и цвета не отображаются должным образом.
Вам нужно перенаправить пользователей и поисковые системы на HTTPS-страницы с помощью 301 переадресации в файле .htaccess в корневой папке на сервере. Файл .htaccess является невидимым файлом, поэтому убедитесь, что ваша программа FTP настроена на показ скрытых файлов. В FileZilla, например, перейдите в раздел Сервер> Принудительный просмотр скрытых файлов. FileZillaBefore, прежде чем добавлять переадресации, было бы неплохо создать резервную копию файла .htaccess. На сервере временно переименуйте файл, удалив период (что и делает его невидимым в первую очередь), скачайте файл (который теперь будет виден на вашем компьютере в результате удаления периода), затем добавьте период назад в том, что на сервере.
Изменение настроек Google Analytics
После выполнения этих действий вам необходимо изменить предпочтительный URL-адрес в своей учетной записи Google Analytics, чтобы отобразить HTTPS-версию вашего домена. В противном случае статистика вашего трафика будет отключена, потому что версия URL-адреса HTTP воспринимается как совершенно другой сайт из версии HTTPS сертификата. Консоль Google Search Console рассматривает HTTP и HTTPS также как отдельные домены, поэтому добавьте в нее учетную запись домена HTTPS. Помните, когда вы переключаетесь с HTTP на HTTPS сертификат, если на вашем сайте есть кнопки специального доступа, счетчик будет сброшен.
fb.ru
типы, выбор, приемущества. / Habr
Многие задавали себе вопрос, чем различаются разные SSL-сертификаты, зачем его получать и почему нельзя использовать самоподписанный.Здесь я попытаюсь ответить на эти вопросы, рассмотрев:
- Причемущества от наличия SSL вообще, и подписанного сертификата в частности.
- Типы SSL-сертификатов.
- Пути их получения.
Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте 🙂
SSL — Secure Sockets Layer — стандарт передачи защифрованных данных через сеть. Касательно web-индустрии это протокол HTTPS.
О сертификатах вообще и зачем их нужно подписывать.
Для начала разберемся, что такое SSL-сертификат.
Здесь и далее речь пойдет приемущественно о web-сайтах. Вопросы SSL + FTP, Email, цифровых подписей исходного кода и пр. до поры оставим в стороне.
SSL-сертификат, это индивидуальная цифровая подпись вашего домена. Он может быть:
- Самоподписанным. Это значит, что вы сами выдали себе сертификат, и сами его подписали.
- Подписанный недоверенным центром сертификации. Это значит, что сертификат сайта проверен, но сам «проверяющий» доверия не удостоен.
- Подписанный доверенным ЦС. Это значит, что данные сертификата проверены компанией, которая имеет на это право, они как минимум существуют.
Разберем их более подробно.
Самоподписанный сертификат не гарантирует ничего. Любой человек может взять и выдать себе такой сертификат. Все браузеры выдают клиенту предпреждение о том, что сертификат не надежен.
Подписанный не доверенным ЦС сертификат тоже не подтверждает ничего, т.к. существуют ЦС, продающие сертификаты всем желающим и без проверок. Большинство браузеров реагирует на такие сертификаты аналогично самоподписанным.
Сертификат, подписанный доверенным источником (как пример — Thawte или VerySign) подтверждает, что:
- Данный сайт действительно принадлежит компании, за которую себя выдает, а не Васе-фишеру из соседнего подъезда.
- Компания, которую представляет сайт — действительно существует в жизни, а не в мыслях Васи из соседнего подъезда.
- Данные этой компании проверены и зарегистрированы центром сертификации.
На доверенные сертификаты браузеры ошибку не выдают.
Но это технически. А теперь о том, что показывает доверенный сертификат посетителю вашего сайта.
- Это действительно тот сайт, на который мы шли, а не дефейс или фишинг.
- Сайт создан в серьез и надолго. В общем случае, желающие «поиграть недельку» не готовы выложить деньги за сертификат.
- Сайт принадлежит компании, либо зарегистрированному физ. лицу, а не неведомому анониму. Плюсы понятны — желающие обмануть или украсть редко стремятся удостоверить свою личность.
- Компанию волнует защищенность информации и подтверждение своей подлинности.
- Если что-то случится, эту компанию можно найти через сертификатора.
Многих пользователей (особенно зарубежных — наши пока к этому не привыкли) самоподписанный сертификат (или отсутствие SSL в вещах, касающихся услуг\финансов\privacy) может если и не отпугнуть, то поставить жирный минус в вашу пользу.
Мой личный вывод: на всех сайтах, связанных с онлайн-коммерцией, платежами, личной информацией SSL должен быть.
Типы сертификатов.
Допустим, руководствуясь соображениями из 1 части статьи вы решили купить подписанный сертификат. Каково же будет ваше удивление, когда на сайте ЦС вы узнаеете, что они бывают разные 🙂
Типы сертификатов:
Esential SSL — самый не дорогой и быстро оформляемый сертификат. Доступен как для юридических, так и для физических лиц. Проверяется только право владения доменным именем, личные данные или регистрация компании не проверяются. Выдается на 1 домен.
Instant SSL — доступен и для физ. лиц, и для юр. лиц. Проверяется право владения доменом, регистрационные данные компании либо личность физ. лица. Выдается на 1 домен.
SGC SSL-сертификат. — Аналогично Instant SSL, но с поддержкой 40-битных расширений (актуально для старых ОС и браузеров). Выдается на 1 домен, либо wildcard (см. ниже).
Обычный Wildcard. — тоже самое, что и обычный сертификат, но выдается не на 1 домен, а на все поддомены корневого домена. Т.е. не только на domain.com, a и на www.domain.com, bill.domain.com и т.д. Стоит на порядок дороже.
EV (Extended Validation) сертификат. — сертификат расширенной проверки, доступен только юридическим лицам. Проверяется владение доменом, компания, нотариально заверенные переводы документов на английский язык, требует подтверждения данных третьей стороной. Позволяет установить на сайте картинку-подтверждение владением и отображается в браузерах как гарантированно доверенный (зеленым цветом), против желтого у обычных сертификатов. Стоит в 2-3 раза дороже обычного, регистрация занимает продолжительное время.
В браузере выглядит так:
EV Wildcard и EV SGC. — аналогично Wildcard и SGC, но с расширенной проверкой.
Instant и Essential сертификаты позиционируются как продукт для сайтов частных лиц и органзаций, не связанных с электронной коммерцией.
В следующей статье я напишу, как выбрать регистратора и получить сертификат.
habr.com
знакомство с SSL/TLS / 1cloud.ru corporate blog / Habr
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
/ Flickr / David Goehring / CC-BY
SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.
Цель протокола — обеспечить защищенную передачу данных. При этом для аутентификации используются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Первый тип шифрования более ресурсоемкий, поэтому его комбинация с симметричным алгоритмом помогает сохранить высокую скорость обработки данных.
Рукопожатие
Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.
Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.
Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.
Алгоритмы шифрования
Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.
Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.
Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.
Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.
Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.
DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.
Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.
Хеш и MAC
Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.
Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.
В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.
Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.
Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.
Сертификаты бывают разные
Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.
Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.
Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.
Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.
Он нужен веб-сайтам, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтвержденные сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей.
Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:
habr.com
SSL-сертификат, что это такое и для чего нужен? Что дает ssl и https для сайта?
HTTPS — что за зверь?
Если вы уже сталкивались с созданием собственного сайта, то наверняка краем уха слышали бессвязный набор фраз «сертификат ssl https что это». В статье мы расскажем, что, как и почему. И эти слова перестанут быть для вас пустым звуком.
Невероятно, но факт: любое действие в Интернете — это обмен данными. Когда вы открываете любимый сайт, ищете видеоролик на «YouTube» или загружаете картинку в инстаграм, ваш поисковый браузер и сервер обмениваются информацией. Каждый вбитый в поисковую строку запрос проходит путь от вас (пользователя) к серверу и обратно. Такая коммуникация возможна благодаря работе протокола HTTP. Он был изобретён ещё в начале 90-х. Всем HTTP хорош, кроме одного: не шифрует данные. Следовательно, их без труда может перехватить третья сторона, личная информация (пароль, номер банковской карты, реквизиты, паспортные данные) может быть украдена злоумышленниками.
В современном мире защита данных имеет принципиальное значение. Поэтому внедрили HTTPS, который расшифровывается как протокол безопасного соединения. Принципом работы защищённого протокола HTTPS является обмен ключами шифрования. Прежде чем ответить на запрос от браузера, сервер предъявляет ключ — SSL-сертификат. Браузер проверяет подлинность ключа в Центре сертификации. Если ключ «подошёл», браузер и сервер доверяют друг другу и договариваются о разовом шифре. Так происходит каждую сессию, то есть каждый раз при обмене запросами и ответами. Вот таким хитрым способом и обеспечивается сохранность данных и конфиденциальность при обмене информацией.
Зачем нужен SSL-сертификат?
Чтобы сайт стал работать по протоколу безопасного соединения HТТPS, нужен SSL-сертификат. Это виртуальный документ, который содержит данные об организации, её владельце и подтверждает их существование. SSL позволяет узнать сервер и подтвердить безопасность сайта.
Использование SSL-сертификата гарантирует:
- Подлинность ресурса, к которому обращается пользователь. Это повышает у посетителей уровень доверия.
- Целостность передаваемой информации. При транспортировке от сервера к браузеру данные не изменятся и не потеряются.
- Конфиденциальность. 256-разрядное шифрование исключает доступ злоумышленников к информации.
Что дает SSL-сертификат для сайта кроме защиты данных? Он также помогает в SEO-продвижении проекта — позволяет занять более высокую позицию в поисковой выдаче. Поисковые системы (Google, Яндекс и пр.) дорожат доверием аудитории и выше ранжируют сайты, которые работают через безопасное соединение.
HTTP или HTTPS? Вот в чём вопрос!
Защита сайта протоколом HTTPS уже давно не просто признак хорошего тона, а необходимость. Несмотря на то, что некоторые сайты ещё работают по HTTP-соединению, очень скоро HTTPS станет обязательным требованием «экологии» Интернета.
Решать, конечно, вам. Но имейте в виду, что с июля 2018 года Google считает небезопасным каждый веб-сайт, не использующий протокол HTTPS. Также WordPress и другие популярные CMS заявили, что некоторые функции теперь будут доступны только для веб-сайтов с протоколом HTTPS.
У меня до сих пор HTTP, что делать?
Если ваш сайт обслуживается на хостинге REG.RU, достаточно заказать SSL-сертификат и перейти с HTTP протокола на HTTPS. Полный цикл:
Готово. Теперь ваш сайт будет работать по HTTPS.
Помогла ли вам статья? 1611
раз уже
помогла
www.reg.ru
что должен знать каждый Web-разработчик / Habr
Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.
Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.
Как данные защищаются? Как клиент и сервер могут установить безопасное соединение, если кто-то уже прослушивает их канал? Что такое сертификат безопасности и почему я должен кому-то платить, чтобы получить его?
Трубопровод
Перед тем как мы погрузимся в то, как это работает, давайте коротко поговорим о том, почему так важно защищать Интернет-соединения и от чего защищает HTTPS.
Когда браузер делает запрос к Вашему любимому веб-сайту, этот запрос должен пройти через множество различных сетей, любая из которых может быть потенциально использована для прослушивания или для вмешательства в установленное соединение.
С вашего собственного компьютера на другие компьютеры вашей локальной сети, через роутеры и свитчи, через вашего провайдера и через множество других промежуточных провайдеров – огромное количество организаций ретранслирует ваши данные. Если злоумышленник окажется хотя бы в одной из них — у него есть возможность посмотреть, какие данные передаются.
Как правило, запросы передаются посредством обычного HTTP, в котором и запрос клиента, и ответ сервера передаются в открытом виде. И есть множество весомых аргументов, почему HTTP не использует шифрование по умолчанию:
• Для этого требуется больше вычислительных мощностей
• Передается больше данных
• Нельзя использовать кеширование
Но в некоторых случаях, когда по каналу связи передается исключительно важная информация (такая как, пароли или данные кредитных карт), необходимо обеспечить дополнительные меры, предотвращающие прослушивание таких соединений.
Transport Layer Security (TLS)
Сейчас мы собираемся погрузиться в мир криптографии, но нам не потребуется для этого какого-то особенного опыта — мы рассмотрим только самые общие вопросы. Итак, криптография позволяет защитить соединение от потенциальных злоумышленников, которые хотят воздействовать на соединение или просто прослушивать его.
TLS — наследник SSL — это такой протокол, наиболее часто применяемый для обеспечения безопасного HTTP соединения (так называемого HTTPS). TLS расположен на уровень ниже протокола HTTP в модели OSI. Объясняя на пальцах, это означает, что в процессе выполнения запроса сперва происходят все “вещи”, связанные с TLS-соединением и уже потом, все что связано с HTTP-соединением.
TLS – гибридная криптографическая система. Это означает, что она использует несколько криптографических подходов, которые мы и рассмотрим далее:
1) Асиметричное шифрование (криптосистема с открытым ключом) для генерации общего секретного ключа и аутентификации (то есть удостоверения в том, что вы – тот за кого себя выдаете).
2) Симметричное шифрование, использующее секретный ключ для дальнейшего шифрования запросов и ответов.
Криптосистема с открытым ключом
Криптосистема с открытым ключом – это разновидность криптографической системы, когда у каждой стороны есть и открытый, и закрытый ключ, математически связанные между собой. Открытый ключ используется для шифрования текста сообщения в “тарабарщину”, в то время как закрытый ключ используется для дешифрования и получения исходного текста.
С тех пор как сообщение было зашифровано с помощью открытого ключа, оно может быть расшифровано только соответствующим ему закрытым ключом. Ни один из ключей не может выполнять обе функции. Открытый ключ публикуется в открытом доступе без риска подвергнуть систему угрозам, но закрытый ключ не должен попасть к кому-либо, не имеющему прав на дешифровку данных. Итак, мы имеем ключи – открытый и закрытый. Одним из наиболее впечатляющих достоинств ассиметричного шифрования является то, что две стороны, ранее совершенно не знающие друг друга, могут установить защищенное соединение, изначально обмениваясь данными по открытому, незащищенному соединению.
Клиент и сервер используют свои собственные закрытые ключи (каждый – свой) и опубликованный открытый ключ для создания общего секретного ключа на сессию.
Это означает, что если кто-нибудь находится между клиентом и сервером и наблюдает за соединением – он все равно не сможет узнать ни закрытый ключ клиента, ни закрытый ключ сервера, ни секретный ключ сессии.
Как это возможно? Математика!
Алгоритм Ди́ффи — Хе́ллмана
Одним из наиболее распространенных подходов является алгоритм обмена ключами Ди́ффи — Хе́ллмана (DH). Этот алгоритм позволяет клиенту и серверу договориться по поводу общего секретного ключа, без необходимости передачи секретного ключа по соединению. Таким образом, злоумышленники, прослушивающие канал, не смогу определить секретный ключ, даже если они будут перехватывать все пакеты данных без исключения.
Как только произошел обмен ключами по DH-алгоритму, полученный секретный ключ может использоваться для шифрования дальнейшего соединения в рамках данной сессии, используя намного более простое симметричное шифрование.
Немного математики…
Математические функции, лежащие в основе этого алгоритма, имею важную отличительную особенность — они относительно просто вычисляются в прямом направлении, но практически не вычисляются в обратном. Это именно та область, где в игру вступают очень большие простые числа.
Пусть Алиса и Боб – две стороны, осуществляющие обмен ключами по DH-алгоритму. Сперва они договариваются о некотором основании root (обычно маленьком числе, таком как 2,3 или 5 ) и об очень большом простом числе prime (больше чем 300 цифр). Оба значения пересылаются в открытом виде по каналу связи, без угрозы компрометировать соединение.
Напомним, что и у Алисы, и у Боба есть собственные закрытые ключи (из более чем 100 цифр), которые никогда не передаются по каналам связи.
По каналу связи же передается смесь mixture, полученная из закрытых ключей, а также значений prime и root.
Таким образом:
Alice’s mixture = (root ^ Alice’s Secret) % prime
Bob’s mixture = (root ^ Bob’s Secret) % prime
где % — остаток от деления
Таким образом, Алиса создает свою смесь mixture на основе утвержденных значений констант (root и prime), Боб делает то же самое. Как только они получили значения mixture друг друга, они производят дополнительные математические операции для получения закрытого ключа сессии. А именно:
Вычисления Алисы
(Bob’s mixture ^ Alice’s Secret) % prime
Вычисления Боба
(Alice’s mixture ^ Bob’s Secret) % prime
Результатом этих операций является одно и то же число, как для Алисы, так и для Боба, и это число и становится закрытым ключом на данную сессию. Обратите внимание, что ни одна из сторон не должна была пересылать свой закрытый ключ по каналу связи, и полученный секретный ключ так же не передавался по открытому соединению. Великолепно!
Для тех, кто меньше подкован в математическом плане, Wikipedia дает прекрасную картинку, объясняющую данный процесс на примере смешивания цветов:
Обратите внимание как начальный цвет (желтый) в итоге превращается в один и тот же “смешанный” цвет и у Боба, и у Алисы. Единственное, что передается по открытому каналу связи так это наполовину смешанные цвета, на самом деле бессмысленные для любого прослушивающего канал связи.
Симметричное шифрование
Обмен ключами происходит всего один раз за сессию, во время установления соединения. Когда же стороны уже договорились о секретном ключе, клиент-серверное взаимодействие происходит с помощью симметричного шифрования, которое намного эффективнее для передачи информации, поскольку не требуется дополнительные издержки на подтверждения.
Используя секретный ключ, полученный ранее, а также договорившись по поводу режима шифрования, клиент и сервер могут безопасно обмениваться данными, шифруя и дешифруя сообщения, полученные друг от друга с использованием секретного ключа. Злоумышленник, подключившийся каналу, будет видеть лишь “мусор”, гуляющий по сети взад-вперед.
Аутентификация
Алгоритм Диффи-Хеллмана позволяет двум сторонам получить закрытый секретный ключ. Но откуда обе стороны могут уверены, что разговаривают действительно друг с другом? Мы еще не говорили об аутентификации.
Что если я позвоню своему приятелю, мы осуществим DH-обмен ключами, но вдруг окажется, что мой звонок был перехвачен и на самом деле я общался с кем-то другим?! Я по прежнему смогу безопасно общаться с этим человеком – никто больше не сможет нас прослушать – но это будет совсем не тот, с кем я думаю, что общаюсь. Это не слишком безопасно!
Для решения проблемы аутентификации, нам нужна Инфраструктура открытых ключей, позволяющая быть уверенным, что субъекты являются теми за кого себя выдают. Эта инфраструктура создана для создания, управления, распространения и отзыва цифровых сертификатов. Сертификаты – это те раздражающие штуки, за которые нужно платить, чтобы сайт работал по HTTPS.
Но, на самом деле, что это за сертификат, и как он предоставляет нам безопасность?
Сертификаты
В самом грубом приближении, цифровой сертификат – это файл, использующий электронной-цифровую подпись (подробнее об этом через минуту) и связывающий открытый (публичный) ключ компьютера с его принадлежностью. Цифровая подпись на сертификате означает, что некто удостоверяет тот факт, что данный открытый ключ принадлежит определенному лицу или организации.
По сути, сертификаты связывают доменные имена с определенным публичным ключом. Это предотвращает возможность того, что злоумышленник предоставит свой публичный ключ, выдавая себя за сервер, к которому обращается клиент.
В примере с телефоном, приведенном выше, хакер может попытаться предъявить мне свой публичный ключ, выдавая себя за моего друга – но подпись на его сертификате не будет принадлежать тому, кому я доверяю.
Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (центром сертификации, Certificate Authority, CA). CA – это компании, выполняющие ручную проверку, того что лицо, пытающееся получить сертификат, удовлетворяет следующим двум условиям:
1. является реально существующим;
2. имеет доступ к домену, сертификат для которого оно пытается получить.
Как только CA удостоверяется в том, что заявитель – реальный и он реально контролирует домен, CA подписывает сертификат для этого сайта, по сути, устанавливая штамп подтверждения на том факте, что публичный ключ сайта действительно принадлежит ему и ему можно доверять.
В ваш браузер уже изначально предзагружен список аккредитованных CA. Если сервер возвращает сертификат, не подписанный аккредитованным CA, то появится большое красное предупреждение. В противном случае, каждый мог бы подписывать фиктивные сертификаты.
Так что даже если хакер взял открытый ключ своего сервера и сгенерировал цифровой сертификат, подтверждающий что этот публичный ключ, ассоциирован с сайтом facebook.com, браузер не поверит в это, поскольку сертификат не подписан аккредитованным CA.
Прочие вещи которые нужно знать о сертификатах
Расширенная валидация
В дополнение к обычным X.509 сертификатам, существуют Extended validation сертификаты, обеспечивающие более высокий уровень доверия. Выдавая такой сертификат, CA совершает еще больше проверок в отношении лица, получающего сертификат (обычно используя паспортные данные или счета).
При получение такого сертификата, браузер отображает в адресной строке зеленую плашку, в дополнение к обычной иконке с замочком.
Обслуживание множества веб-сайтов на одном сервере
Поскольку обмен данными по протоколу TLS происходит еще до начала HTTP соединения, могут возникать проблемы в случае, если несколько веб-сайтов расположены на одном и том же веб-сервере, по тому же IP-адресу. Роутинг виртуальных хостов осуществляется веб-сервером, но TLS-соединение возникает еще раньше. Единый сертификат на весь сервер будет использоваться при запросе к любому сайту, расположенному на сервере, что может вызвать проблемы на серверах с множеством хостов.
Если вы пользуетесь услугами веб-хостинга, то скорее всего вам потребуется приобрести выделенный IP-адрес, для того чтобы вы могли использовать у себя HTTPS. В противном случае вам придется постоянно получать новые сертификаты (и верифицировать их) при каждом обновлении сайта.
По этой теме много данных есть в википедии, есть курс на Coursera. Отдельное спасибо ребятам из чата на security.stackexchange.com, которые отвечали на мои вопросы сегодня утром.
Примечания переводчика:
1)Спасибо хабраюзеру wowkin за отличную ссылку по теме (видео переведено и озвученно хабраюзером freetonik):
2) По результатам развернувшейся в коменатариях дискуссии (спасибо за участие хабраюзерам a5b, Foggy4 и Allen) дополняю основную статью следующей информацией:
По данным netcraft на базе свежего SSL survey (2.4 млн SSL сайтов, июнь 2013), большинство SSL соединений не используют Perfect forward secrecy алгоритмы: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
Особенно ситуация плоха в случае с IE (даже 10 версии), который поддерживает Диффи-Хеллмана только на эллиптических кривых (RSA и ECDSA сертификаты), либо классический Диффи-Хеллман с более редкими сертификатами DSS (DSA).
По подсчетам netcraft 99,7 % соединений с IE и по 66% — с Chrome, Opera и Firefox не будут использовать Диффи-Хеллмана.
На Hacker News в обсуждении это тоже заметили.
Also (and I made the same mistake in my talk…), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don’t work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server’s public key. (RFC 5246: 7.4.7.1, 8.1.1)это важно и интересно, но не все понимают что он в реальности применяется не так часто. В большинстве сеансов SSL и TLS действительно обмен ключей происходит путем их шифрования с помощью RSA.
habr.com
Возможные пути решения ошибки «Сертификат безопасности сайта не является доверенным»
Здравствуйте. В связи с повышением курса доллара и евро, я думаю у народа всё чаще будет появляться данная ошибка и поэтому решил написать о ней. Как это связано? По ходу статьи узнаете:)
Итак, это прекрасная ошибка чаще всего появляется в Google Chrome и является следствием неправильной работы корневых сертификатов. Самое неприятное видеть данную ошибку когда открываешь проверенный временем и миллионами человек Яндекс или Google. А вот причин может быть несколько, постараюсь как можно проще описать их варианты и способы решения проблемы.
1. Сбилось системное время или дата
Да, такая мелочь, может оказаться единственной причиной данной проблемы. И так как мало кто догадается связать данные, да и вообще всё внимание идёт на экран и поиск решения данной проблемы, мало кто замечает что время или дата сбилась. Поэтому жмём правой клавишей мыши по трею и выбираем «Настройка даты и времени».
В Windows 10 рекомендую установить автоматическое обновление времени и даты, это решит очень много проблем)
На Windows 8.1 и более старших переходим на вкладку «Время по Интернету» → «Изменить параметры» → ставим галочку «Синхронизировать с сервером времени В Интернете«, выбираем какой-нибудь из серверов и жмём «Обновить сейчас«. Если выдаст ошибку меняем сервер и снова жмём, пока всё не будет хорошо, потом жмём ОК.
Если время сбивается после каждого запуска компьютера, значит у вас разрядилась батарейка на материнское плате и её стоит поменять (Смело выдергиваете и идёте с ней покупать новую, компьютер может работать и без неё). Именно из-за батарейки я и написал о курсе рубля, теперь не каждый может позволить обновить рабочую машинку и батарейки будут сажаться.
2. Ошибка в настройках групповых политик (на предприятии)
Здесь сложнее, по-хорошему это системному администратору нужно ковырять настройки групповых политик, но это трудоемко и большинство просто забивают на это дело.
Отличный вариант для решения этой проблемы — это установки обновлений корневых сертификатов. Они доступны как и для серверных, так и для клиентских ОС.
К примеру для клиентских ОС можно выбрать отсюда: обновление kb3004394
Но вообще поиск по https://support.microsoft.com по запросу корневые сертификаты здесь очень сильно помогает.
3. Когда больше ничего не помогает
Не могу рекомендовать данный способ, как он вполне способен организовать дыру в безопасности вашего компьютера, но раз любимый сайт дороже, то переходим по ссылке (к примеру GeoTrust Primary Certification Authority должен помочь вылечить сайты Google) и качаем корневые сертификаты, которые сейчас мы будем устанавливать (Cпециально разместил их на Яндекс.Диске, чтобы ссылки не могли подменить злоумышленики, владелец каталога должен быть Skesov). Там есть файл original links, где указаны ссылки на источники файлов. При желании можно скачать оттуда.
Скачали? Теперь жмём Win+R и вводим команду certmgr.msc
Кликаем правой клавишей мыши по каталогу «Доверенные корневые центры сертификации»
Откроется «Мастер импорта сертификатов». Жмём далее.
Жмём кнопку «Обзор», откроется окно поиска файлов, выбираем справа внизу «Все файлы», идём в папку со скаченным файлом и открываем файл.
Проверяем чтобы было выбрано «Доверенные корневые центры сертификации» и жмём далее.
Жмём «Готово» и сертификат добавится в систему.
По идеи уже всё должно работать, но можно повторить всё тоже самое, добавляя этот же сертификат в «Сторонние корневые центре сертификации«. После добавления страницы должны открываться, максимум что потребуется — это перезапуск системы.
Вроде всё. Надеюсь эта статья оказалась вам полезной, обязательно нажмите одну из кнопок ниже, чтобы рассказать о ней друзьям. Также подпишитесь на обновления сайта, введя свой e-mail в поле справа или подписавшись на группу во Вконтакте и канал YouTube.
Спасибо за внимание
Материал сайта geekteam.pro
geekteam.pro
Теперь ваш HTTPS будет прослушиваться, а сертификат для MitM вы должны поставить сами
Пока не Россия. Но уже Казахстан. Как писал ValdikSS в своем посте Казахстан внедряет свой CA для прослушивания всего TLS-трафика:
Государственный провайдер Казахтелеком, в связи с нововведениями закона Республики Казахстан «О связи», намерен с 1 января 2016 года прослушивать весь зашифрованный TLS-трафик, подменяя сертификаты сайтов национальным сертификатом безопасности, выпущенным Комитетом связи, информатизации и информации Министерства по инвестициям и развитию Республики Казахстан.
Что нового произошло с тех пор? Beeline и Telecom.kz (основной провайдер-монополист) выкатили обновленные инструкции по установке государственного сертификата, который позволит осуществлять атаку man-in-the-middle с подменой сертификата. Ссылка на государственный сертификат.
Коротко о сертификатах
Как известно, современный интернет во многом опирается на сильную криптографию. Множество протоколов шифрования и областей их применения. Несколько десятилетий назад сильная криптография была исключительной прерогативой спецслужб и военных. Им можно хранить информацию зашифрованной надежно, остальным нельзя. До сих пор слышны отголоски этих времен в странных законах и подзаконных актах, которые де-факто уже не работают. Что же изменилось?
Пришел open-source, который дал в руки любого желающего алгоритмы, позволяющего сохранить приватность переписки и быть уверенным в том, что данные не утекут каким-то личностям по дороге к пункту назначения. Пока неповоротливая государственная машина раздумывала, что же делать с новой угрозой, внезапно сильные алгоритмы шифрования стали аппаратно поддерживаться каждым утюгом и стали доступны каждому. Более того, с каждым годом, несмотря на давление властей и спецслужб всех стран безопасность продолжала усиливаться. Протокол HTTPS стал стандартом для любых более или менее значимых соединений. Появился HSTS (HTTP Strict Transport Security) — механизм, активирующий форсированное защищённое соединение через протокол HTTPS.
Появился Certificate pinning (хранение списка разрешенных для домена сертификатов или CA в исходных текстах браузера) и HTTP Public Key Pinning. Эти методы позволяют избежать незаметной подмены сертификата за счет сравнения с эталонными в защищенном хранилище браузера. Благодаря тому, что браузеры стали преимущественно открытым ПО, повлиять на государственном уровне стало очень сложно. Особенно с учетом того, что любая страна не допустит наличие бекдоров от другой стороны.
Безопасность сертификатов строится на сертификационных центрах и иерархической структуре проверки его валидности. Сертификационный центр (CA) — центр, которому все доверяют как надежной третьей стороне, подтверждающей подлинность ключей шифрования с помощью сертификатов электронной подписи. При этом, единственный актив такого центра по торговле «воздухом» — это его репутация. Так как удостоверяющих центров много, то в случае, если CA будет замечен за сливом сертификатов для MitM, он будет немедленно добавлен в черные списки всех операционных систем и браузеров. Поэтому CA ведут себя крайне осмотрительно. Более того, махинации с подменой сертификата будут немедленно замечены браузерами, которые автоматически выбрасывают сообщение об угрозе и часто совсем не пускают пользователя дальше, если конечный ресурс активировал HSTS и Certificate pinning.
Что хочет государство?
Как обычно государство хочет контролировать своих граждан под любыми предлогами. Новый закон, принятый в Казахстане, по сути обязывает провайдеров осуществлять атаку man-in-the-middle. При этом варианте, вместо сертификата Gmail, выданного Google Inc, вы увидите Gamma Technologies Certificate Authority, который честно будет перепаковывать ваш TLS-шифрованный трафик, попутно прослушивая все что нужно, просматривая личную переписку, собирая ваши логины и пароли от любых сервисов. Разумеется, исключительно ради вашей безопасности. Как уже говорилось, браузеры такой беспредел незамеченным не пропустят и просто не пустят вас на целевой ресурс во избежание утечки данных. Однако, в данной ситуации и не ставится задача быть незаметным. Вас ставят перед фактом: либо вы устанавливаете государственный сертификат как доверенный и разрешаете MitM, либо вы лишаетесь всех сервисов, использующих TLS-шифрование. Апплодисменты, занавес. Особенно умиляет цинизм подачи необходимости установки данных сертификатов:
Сертификат безопасности обеспечивает защиту транзакций в сети Интернет и совершенно бесплатен. Просто благодетели. Как раньше без них жили.
Кто пострадает?
Помимо самого вопиющего факта государственной цензуры и возможности просмотра личной переписки, будут большие проблемы с устройствами и софтом, которые не позволяют добавить левый сертификат. Они превратятся в тыкву. Но это никого не волнует. Не менее важным фактором является потенциальная утечка личных данных, паролей к сервисам, которые наверняка будут централизованно собираться. Иначе смысла нет этот цирк с конями устраивать изначально.
Что с этим делать?
Паниковать и бегать кругами. Это уже очень-очень серьезно и техническими средствами почти не решается. Можно поднять VPN-канал на сервер извне страны, чтобы избежать перехвата сертификата. Однако тот же OpenVPN с TLS-шифрованием превратится в тыкву. Вероятнее всего, следующим этапом будут дропать шифрованные соединения VPN. Более того, если вам надо получить «чистый доступ» к Gmail или Twitter, то проблем нет. Однако, если сервис находится внутри страны с подменой сертификата, то ничего не поможет. Останется только смириться с прослушкой.
P.S. Все грустно, господа. Хотелось бы услышать хотя бы предложения по техническим вариантам решения проблемы.
UPD После публикации Казахтелеком резко удалил страницу и сертификат
Теперь вместо страницы на скриношоте из поста отдается ошибка 404.
Страница Билайна пока жива, но ссылки перестали быть ссылками, а стали просто подчеркнутыми словами.
UPD Ссылки на багрепорты по поводу сертификата
Спасибо ibmpc.
Сообщение о проблеме в Mozilla:
bugzilla.mozilla.org/show_bug.cgi?id=1229827
mozilla.dev.security.policy:
groups.google.com/forum/#!topic/mozilla.dev.security.policy/wnuKAhACo3E
Просьба добавить сертификат (root.gov.kz) в доверенные:
bugzilla.mozilla.org/show_bug.cgi?id=1232689
habr.com