Доверенный сертификат: для чего это нужно? / Блог компании REG.RU / Хабр

Разница между Корневыми и Промежуточными Сертификатами

Доброго времени суток, Уважаемые Гости! В данной статье мы хотели бы вспомнить про доверие сертификатов в Браузерах, благодаря Корневому сертификату и Промежуточным сертификатам.

Многие люди не понимают, что сертификат SSL пользователя является только одной частью всей «цепочки сертификатов». Давайте поговорим о промежуточных и корневых сертификатах. SSL (точнее, TLS) — это технология, о которой большинство пользователей практически ничего не знают. Даже люди, приобретающие его, как правило, не знают многого, кроме того, что им нужен сертификат SSL и они должны установить его на своем сервере, чтобы обеспечить HTTPS на своём сайте . Итак, начнём!

Что такое корневой сертификат?

Корневой сертификат, часто называемый доверенным корневым сертификатом, находится в центре модели доверия, которая поддерживает SSL / TLS. Каждый браузер содержит корневое хранилище. Некоторые браузеры работают самостоятельно, в то время, как другие используют стороннее хранилище сертификатов. Хранилище корневых сертификатов — это набор предварительно загруженных корневых сертификатов, которые находятся на устройстве. Корневой сертификат бесценен, поскольку браузеры автоматически доверяют сертификату, подписанному с доверенным корневым сертификатом. Доверенные корни принадлежат Центрам Сертификации (например Comodo, Thawte, Geotrust, GlobalSign, Symantec и так далее) — организациям, которые проверяют и выдают сертификаты SSL.

Что такое промежуточный сертификат?

Центры сертификации не выдают сертификаты SSL конечного пользователя непосредственно от их Корневого сертификата. Это было бы опасно, потому что, при неправильной выдаче или ошибке, Root (Корневой сертификат) был бы отозван и каждый выпущенный сертификат, который был подписан с использованием данного Корневого сертификата, станет сразу же «Недоверенным». Таким образом, чтобы обезопасить себя, CA обычно выдает то, что называется «промежуточным сертификатом». Центр Сертификации подписывает промежуточный сертификат с его закрытым ключом, который делает его «Доверенным». Затем Центр сертификации использует закрытый ключ промежуточного сертификата для подписи сертификатов SSL конечного пользователя. Этот процесс может играть несколько раз, где промежуточный корень подписывает другое промежуточное звено, и затем CA использует это для подписания сертификата. Вот визуализация цепочки сертификатов.

В нашем примере, мы будем использовать только один промежуточный элемент, чтобы упростить её. В основном «Цепочки сертификатов» сложнее.

Какую роль играет цифровая подпись?

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

Когда ваш браузер аутентифицирует сертификат SSL конечного пользователя на веб-сайте, он использует открытый ключ, который установлен на веб-сайте, чтобы расшифровать подпись и переместиться далее вверх по цепочке сертификатов. Он продолжает повторять этот процесс – расшифровывая подпись и следуя по цепочке к сертификату, который ее подписал — до тех пор, пока в конечном итоге он не достигнет одного из Корневых сертификатов в доверенном хранилище браузера. Если он не может связать сертификат с одним из своих доверенных корней, он не будет доверять этому сертификату.

Итак, в чем разница между Корневым ЦС и Промежуточным ЦС?

Корневой центр сертификации — это центр сертификации, владеющий одним или несколькими доверенными корнями. Это означает, что они имеют корни в хранилищах доверия основных браузеров. Промежуточные сертификаты не имеют корней в Доверенных хранилищах сертификатов браузера. Как мы обсуждали ранее, Центры Сертификации не выдают сертификаты подписывая их своим Корневым сертификатом. Они добавляют уровни безопасности, подписывая «промежуточные звенья», а затем подписывая ими сертификаты. Это помогает свести к минимуму и ограничить ущерб в случае неправильной выдачи или ошибки. Вместо отзыва Корневого сертификата и буквально каждого сертификата, подписанного этим сертификатов, Они просто отзывают «промежуточное звено», что вызывает только недоверие группы выпущенных сертификатов этим «промежуточным звеном». Вот практический пример: Google и другие браузеры недавно перестали доверять сертификатам Symantec CA SSL. Чтобы не отзывать миллионы сертификатов выданных Центром Сертификации, они просто удалили все корни Symantec CA из своих хранилищ доверия и заменили Центром Сертификации DigiCert.

То, что мы только, что описали – модель доверия с участием Центров Сертификации, Цепочек Сертификатов и Криптографических подписей – по существу это — PKI или Инфраструктура Открытых Ключей.  

Добавление сертификатов в хранилище доверенных корневых центров сертификации для локального компьютера

Чтобы добавить сертификаты в хранилище доверенных корневых центров сертификации локального компьютера, выполните следующие действия.

1. Первый шаг. Откройте мастер импорта сертификатов одним из описанных далее способом и нажмите «Далее >».

Установка через Internet Explorer:

• Запустите iexplorer. В главном меню выберите Сервис / Свойства обозревателя.
• Откройте «Свойства обозревателя» через Пуск / Панель управления.
• Переключитесь на вкладку «Содержание».
• Откроется окно «Сертификаты». Переключитесь на вкладку «Доверенные корневые центры сертификации».
• Нажмите кнопку «Импорт».
• Запустите файл сертификата как программу. Появится окно «Сертификат».
• Нажмите кнопку «Установить сертификат».

Через консоль MS Windows

Внимание! Данный вариант — ЕДИНСТВЕННЫЙ работоспособный для Windows 7!

1. • Запустите консоль mmc, для этого выполните следующие действия: Войти в «Пуск / Выполнить», в строке «Найти программы и файлы» пропишите mmc, Разрешите внести изменения — кнопка Да.
   • Появится окно консоли. В главном меню выберите Консоль / Добавить или удалить оснастку
   • Появится окно «Добавить или удалить оснастку». Нажмите кнопку «Добавить…»
   • В списке оснастки выберите «Сертификаты» и нажмите «Добавить».
   • В окне «Оснастка диспетчера сертификатов» оставьте значения по умолчанию и нажмите «Готово»
   • Закройте окно «Добавить изолированную оснастку» (кнопка «Закрыть»)
   • В окне «Добавить или удалить оснастку» нажмите «ОК»
   • В дереве консоли появится запись «Сертификаты». Раскройте ее и найдите раздел «Доверенные корневые центры сертификации», «Сертификаты»
   • На строке «Сертификаты» нажмите правую кнопку мыши и в контекстном меню выберите Все задачи / Импорт
2. На шаге «Импортируемый файл» (Шаг может быть пропущен, в зависимости от варианта запуска мастера) с помощью кнопки «Обзор…» выберите корневой сертификат и нажмите «Далее >».
3. На шаге «Хранилище сертификатов» установите опцию «Поместить все сертификаты в следующее хранилище» и нажмите кнопку «Обзор».
4. В окне выбора хранилища установите флаг «Показать физические хранилища», раскройте «ветку» (+) «Доверенные корневые центры сертификации» и выберите место хранения сертификата:
   • «Реестр» — для пользования корневым сертификатом только текущим пользователем под данной операционной системой.
   • «Локальный компьютер» — для пользования корневым сертификатом всеми пользователями операционной системой.

5. После нажатия кнопок «Ок», «Далее >» и «Готово» может появиться предупреждение о безопасности (зависит от внутренних настроек операционной системы) с вопросом «Установить данный сертификат?», нажмите «Да».
6. Появится сообщение — «Импорт успешно выполнен», корневой сертификат добавлен в доверенные корневые центры сертификации для вашей или для всех учетных записей.

Какой выбрать и как получить / Блог компании 1cloud.ru / Хабр

20 июля компания Google объявила о том, что браузер Chrome перестает считать доверенными SSL-сертификаты, выданные центром сертификации (CA) WoSign и его дочерним предприятием StartCom. Как пояснили в компании, решение связано с рядом инцидентов, не соответствующим высоким стандартам CA, — в частности, выдаче сертификатов без авторизации со стороны ИТ-гиганта.

Чуть ранее в этом году также стало известно, что организации, ответственные за выдачу сертификатов, должны будут начать учитывать специальные DNS-записи. Эти записи позволят владельцам доменов определять «круг лиц», которым будет дозволено выдавать SSL/TLS-сертификаты для их домена.

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

/ Flickr / montillon.a / CC

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

Первый тип сертификатов — это сертификаты с проверкой домена (Domain Validated). Они подходят для некоммерческих сайтов, поскольку подтверждают только обслуживающий сайт веб-сервер, на который осуществлён переход. DV-сертификат не содержит идентифицирующей информации в поле имени организации. Обычно там числится значение «Persona Not Validated» или «Unknown».

Для проверки лица запросившего сертификат центр сертификации высылает письмо на электронный адрес, связанный с доменным именем (например, [email protected]). Это делается для того, чтобы удостовериться, что лицо, запросившее сертификат, действительно является владельцем доменного имени. Компании Google не нужно доказывать общественности, что www.google.com принадлежит ей, поэтому она вполне может использовать простые сертификаты с проверкой домена (однако ИТ-гигант все равно использует OV-сертификаты, о которых далее).

Другие варианты верификации — добавление TXT-записи в DNS или размещение на сервере специального файла, который может быть прочитан CA. Этот вид сертификата самый дешевый и популярный, но не считается полностью безопасным, поскольку содержит информацию лишь о зарегистрированном доменном имени. Поэтому они часто используются для защиты во внутренних сетях или на небольших веб-сайтах.

Второй тип сертификатов носит название Organization Validated, или сертификаты с проверкой организации. Они более надежны, по сравнению с DV, поскольку дополнительно подтверждают регистрационные данные компании-владельца онлайн-ресурса. Всю необходимую информацию компания предоставляет при покупке сертификата, а CA затем напрямую связывается с представителями организации для её подтверждения.

Третий тип — это Extended Validation, или сертификат с расширенной проверкой, который считается самым надежным. Впервые появился в 2007 году и нужен веб-сайтам, которые проводят финансовые транзакции с высоким уровнем конфиденциальности. В этом случае целая адресная строка браузера будет выделяться зеленым цветом (поэтому их и называют «с зеленой строкой»). Плюс в зеленой области будет указано название компании.

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

Отметим, что если для совершения платежей и обработки транзакций пользователь перенаправляется на сторонний сайт, подтверждённый сертификатом с расширенной проверкой, то в этом случае хватит обычных сертификатов OV.

EV-сертификаты полезны, если необходимо «жестко» связать домен с физической организацией. Например, Bank of America и домен bankofamerica.com. В этом случае сертификат с проверкой организации гарантирует, что ресурс действительно принадлежит банку, куда пользователь может физически занести свои деньги — это как минимум удобно для пользователей.

Более того, EV-сертификаты защищают от атак с использованием фишинговых сайтов, как это было в случае с Mountain America Credit Union. Злоумышленники сумели получить легальный SSL-сертификат для копии сайта кредитной организации. Дело в том, что банк использовал доменное имя macu.com, а атакующие использовали имя mountain-america.net и при подаче заявки «вывесили» невинно выглядящий сайт. После получения сертификата сайт был заменен на фишинговый ресурс. EV-сертификаты серьезно затрудняют выполнение подобного «фокуса» — как минимум адрес виновника становится сразу известен.

Выдавая сертификаты типа OV или EV, сертификационный центр должен убедиться, что компания, получающая сертификат, действительно существует, официально зарегистрирована, имеет офис, а все указанные контакты — рабочие. Оценка организации начинается с проверки её официальной государственной регистрации. На территории России это выполняется с помощью реестра юридических лиц, представленного на сайте ФНС.

После получения заявки на сертификат, CA присылает бланки с вопросами об организации, которые нужно заполнить и подписать. Свои подписи и печати ставят руководитель компании и главный бухгалтер. После чего отсканированные документы отправляются обратно в центр сертификации, где их проверяют по идентификаторам ЕГРЮЛ и ИНН.

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

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

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

При этом отметим, что также существуют международные агентства, которые могут проверять официальные документы компании и выступать удостоверителем её законного существования. Наиболее известным из таких агентств является Dun & Bradstreet. После проверки организации D&B выдаёт цифровой идентификатор — DUNS (Digital Universal Numbering System) — на который можно ссылаться для подтверждения легальности организации.

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

Цепочки сертификатов

Вообще, чтобы зашифровать данные, пересылаемые между веб-сервером и браузером пользователя, достаточно одного сертификата. Однако, если посмотреть на путь сертификации ресурса google.ru, можно увидеть, что их целых три.
При посещении многих сайтов, например, банков или железнодорожных касс, пользователи хотят уверенными не только в том, что соединение защищено, но и в том, что открывшийся сайт — правильный. Для удостоверения этого факта одного сертификата недостаточно. Нужно, чтобы третья сторона (центр сертификации) подтвердила, что для защиты соединения используется сертификат, выпущенный именно для этого сайта.

Если некто «Б» удостоверил личность «А», и вы доверяете «Б», то проблема решена.

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

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

Другие виды сертификатов

Напоследок хотелось бы сказать, что помимо обозначенной градации сертификатов — DV, OV, EV — существуют и другие типы сертификатов. Например, сертификаты могут отличаться по количеству доменов, на которые они выдаются. Однодоменные сертификаты (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. Несколько материалов по теме из нашего блога:

Что такое корневой сертификат SSL и зачем он нужен?

Корневой сертификат SSL – одна из частей схемы PKI (инфраструктуры публичных ключей), которая идентифицирует корневой центр сертификации. Важность SSL сертификации и преимущества защищенного https соединения оценили многие пользователи. Использование SSL гарантирует:

• шифрованную передачу данных между сервером и клиентом;
• подлинность сайта, с которым происходит обмен информацией (защита от фишинга).

Но возникает вопрос: откуда берутся цифровые сертификаты безопасности и кто отвечает за их надежность? Есть несколько основных доверенных центров сертификации, которые выдают сертификаты SSL и Code Signing. Они проверяют, действительно ли клиент, запросивший SSL имеет доступ к домену или является представителем запрашивающей организации. Кроме того, именно центры сертификации несут ответственность за конфиденциальность передаваемой информации. Массовое применение сертификатов SSL привело к большому количеству сертификационных центров, каждый из которых подписывает предоставляемые решения своим именем. Чтобы браузер пользователя мог отличать поставщиков SSL друг от друга, а также определить их надежность, в нем применяется список доверенных центров сертификации.

Cтруктура SSL сертификатов

Сертификационные центры могут выдавать множество SSL сертификатов, связанных по принципу древовидной структуры. Так, корневой сертификат является корнем дерева, секретным ключом которого подписываются другие сертификаты. Все промежуточные сертификаты (intermediate), находящиеся сразу под корневым, перенимают степень доверия к нему, так как подпись корневым сертификатом является чем-то вроде нотариального удостоверения личности. SSL сертификаты, находящиеся далее по структуре, таким же образом зависят от уровня доверия к промежуточным (intermediate). На примере сертификационного центра Comodo, структуру SSL сертификатов можно изобразить следующим образом:

• Корневой сертификат ЦС Comodo: AddTrustExternalCARoot
• Промежуточные сертификаты: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA
• В самом низу изображены SSL сертификаты для отдельных доменов.

Для чего нужен корневой сертификат SSL?

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

Что же касается таких доверительных центров сертификации, как Comodo, Symantec, Thawte, GeoTrust и GlobalSign, то данные об их корневых сертификатах в обязательном порядке добавляются во все современные браузеры. Их список в настройках обозревателя выглядит следующим образом:

Но для правильного распознавания SSL для Вашего личного доменного имени, необходимо создать так называемую цепочку доверия (trust chain) из доменного, промежуточного и корневого сертификатов SSL. Для этого необходимо установить корневой, а также промежуточный сертификаты на своем сервере. Процесс установки производится по разному, в зависимости от Вашего программного обеспечения. Для наиболее известного ПО на нашем сайте можно найти инструкции по установке SSL. Заметьте, что в отдельных случаях для правильного распознавания необходимо создать ca-bundle – файл, в котором содержится информация корневого и промежуточного сертификатов.

Как получить корневой сертификат SSL?

Купив SSL сертификат на нашем сайте, Вы получите архив, содержащий 3 файла сертификатов:

• Ваш личный (с номером заказа)
• корневой
• промежуточный.

Кроме того, его можно скачать на официальных сайтах сертификационных центров.

Можно ли создать корневой сертификат самому?

Для этого необходимо зарегистрироваться в качестве центра сертификации, что требует больших временных и финансовых затрат. Поэтому рациональнее воспользоваться услугами всем известных доверенных центров сертификации, например, Thawte, Comodo, Verisign, GeoTrust, GlobalSign, которые без проблем распознаются практически всеми браузерами.

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

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

Что такое цепочка сертификатов и корневой сертификат и как их установить?

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

Центры сертификации с двадцатилетней историей: GlobalSign, Comodo, Symantec, TrustWave, GeoTrust. Они используют «именные» корневые сертификаты, которые распознаются большинством современных браузеров.

Это значит: если на сайт установлен корневой сертификат GlobalSign, браузер идентифицирует его как выпущенный доверенным «поручителем» и приступает к частной проверке сайта.

Если информация о корневом сертификате центра отсутствует в браузере, у сайта нет «поручителя», и браузер считает его недостоверным. Так иногда происходит с самоподписанными сертификатами безопасности (например, Let’s Encrypt):

Читайте об этом в статье Браузер пишет, что подключение не защищено или соединение является недоверенным.

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

Где взять корневой сертификат?

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

Также вы можете воспользоваться специальным предложением REG.RU и получить бесплатный SSL-сертификат на 1 год при заказе домена или хостинга. Читайте об этом в статье: Как заказать бесплатный SSL-сертификат?

После заказа SSL и его активации на указанную контактную почту придет письмо с необходимыми данными для установки сертификата на сайт (в частности, корневой сертификат). Подробнее о содержимом письма в статье Где взять данные для установки SSL-сертификата.

Могу ли я создать корневой сертификат самостоятельно?

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

Установка цепочки сертификатов

Список доверенных сертификатов, использующихся для создания цепочки, приходит в информационном письме после выпуска и активации SSL. Для установки цепочки сертификатов (в том числе, корневого) воспользуйтесь подробными инструкциями справочного раздела: Установка SSL-сертификата.

Помогла ли вам статья?

14
раз уже
помогла

Корневые и промежуточные сертификаты уполномоченных Удостоверяющих Центров России

Как и многие другие страны, Россия для официального электронного документооборота использует x509 сертификаты, выпускаемые уполномоченными Российскими Удостоверяющими Центрами (УЦ). И в отличие от многих других стран, использует свои собственные шифры.

Я давно хотел автоматизировать проверку подписей ответов органов власти (я много переписываюсь) и проверку «выгрузок» Роскомнадзора на подлинность (по роду общественной деятельности). Самой большой проблемой было достать промежуточные сертификаты из цепочки. Потому что существовал невнятный Excel-файл корневых УЦ на сайте Минсвязи и всё. А промежуточные надо было искать по сайтам соответствующих УЦ. Жизнь — боль.

Что такое «промежуточные сертификаты». Напомню как это работает. Допустим, мы хотим проверить некое подписанное письмо. Письмо подписано ключом. Есть сертификат, который удостоверяет этот ключ. Сертификат кем-то выдан и тоже подписан каким-то ключом с прилагаемым сертификатом. И тот сертификат точно также. И так до момента, когда сертификат выдан сам себе. При проверке мы имеем (принесли, поставили из пакета, нам выдали на флешке) некий набор вот этих конечных сертификатов, которым мы верим. Верим потому что мы верим тому, кто нам их выдал. В мире веба мы верим браузеру и их набору корневых сертификатов. В мире веба при соединении по HTTPS передаются от сервера к клиенту также и промежуточные сертификаты. Поэтому в мире веба у нас всегда есть вся цепочка.

Внезапно (я не знаю точно когда) и незаметно на сайте Госуслуг появилась вот такая ссылочка:
e-trust.gosuslugi.ru/CA

Я наскоро написал программку, которая превращает XML-файл со списком УЦ и сертификатами с этого сайта в привычный PEM формат.

Затем я автоматизировал её и получил постоянно поддерживаемый репозиторий сертификатов в привычном для *NIX мира виде.

Шифрование ГОСТ

Шифрование ГОСТ поддерживается в LibreSSL не помню с какой версии. Но в Alpine Linux от 3.5 уже поддерживается. С OpenSSL всё сложнее. Шифрование ГОСТ идёт с OpenSSL от версии 1.0.0 до версии 1.0.2 включительно. Но например в CentOS шифрования ГОСТ нет. Пользователи CentOS должны страдать. Для Debian, Mint, Ubuntu с OpenSSL версии 1.1.0 и выше требуется установка пакета libengine-gost-openssl1.1, поддерживаемого криптоэнтузиастом Вартаном Хачатуровым (кстати, можно ему помочь).

Ну и в 2018 году у нас есть Docker, а в Alpine Linux, как я уже упоминал, всё работает.

Как это использовать

Короткие примеры для проверки «выгрузки» Роскомнадзора с открепленной подписью. Файл «выгрузки» — dump.xml, открепленной подписи — dump.xml.sig. Даже я проверял их раньше только на целостность подписи, но не на соответствие источнику.

Используя OpenSSL:

git clone https://github.com/schors/gost-russian-ca.git ./
openssl smime -verify -engine gost \
        -CAfile gost-russian-ca.git/certs/ca-certificates.pem \
        -in dump.xml.sig -inform DER -content dump.xml  -out /dev/null

Используя LibreSSL:

git clone https://github.com/schors/gost-russian-ca.git ./
openssl smime -verify -CAfile gost-russian-ca.git/certs/ca-certificates.pem \
        -in dump.xml.sig -inform DER -content dump.xml  -out /dev/null

И, конечно, можно применить утилиту c_rehash в папке certs, а затем использовать опцию -CAdir вместо -CAfile.

И с этого момента можно не пользоваться сайтом Госуслуг, Контура и странными программами вроде КриптоПро для простой задачи проверки подписи. А главное, что теперь можно и автоматизировать.

валидные HTTPS-сертификаты для localhost / Блог компании GlobalSign / Хабр

В наше время использование HTTPS становится обязательным для всех сайтов и веб-приложений. Но в процессе разработки возникает проблема корректного тестирования. Естественно, Let’s Encrypt и другие CA не выдают сертификаты для localhost.

Традиционно есть два решения.

1. Самоподписанные сертификаты, сгенерированные через openssl или др. Вот самый простой способ сгенерировать приватный ключ и самоподписанный сертификат для localhost:

   openssl req -x509 -out localhost.crt -keyout localhost.key \
     -newkey rsa:2048 -nodes -sha256 \
     -subj '/CN=localhost' -extensions EXT -config <( \
      printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

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

2. Трюк с регистрацией нового домена типа localhost.example.com, который локально ресолвится в 127.0.0.1 (в /etc/hosts), с получением обычного сертификата для данного домена. Но такая махинация сомнительна с точки зрения безопасности — по крайней мере, для публичных сервисов подобный ресолвинг делать крайне не рекомендуется из-за возможной MiTM-атаки со сменой на враждебный IP-адрес. Если ограничиться только локальной машиной, то может это и подходящий вариант, хотя тоже возникают некоторые сомнения. К тому же, такой сертификат могут отозвать. В любом случае, есть вариант проще и безопаснее (см. ниже).

Речь идёт о mkcert — простой утилите для генерации локально-доверенных сертификатов с собственным центром сертификации. Она работает под всеми ОС и не требует какой-то конфигурации.

Версия для Linux

Сначала нужно установить certutil.

sudo apt install libnss3-tools
    -или-
sudo yum install nss-tools
    -или-
sudo pacman -S nss

затем

brew install mkcert

или собрать из исходников:

go get -u github.com/FiloSottile/mkcert
$(go env GOPATH)/bin/mkcert

Версия для macOS

brew install mkcert
brew install nss # if you use Firefox

Версия для Windows

Под Windows можно скачать собранные бинарники либо воспользоваться одним из пакетных менеджеров: Chocolatey или Scoop.

choco install mkcert
    -или-
scoop install mkcert

Наличие локального центра сертификации — самое важное принципиальное отличие mkcert от openssl и самоподписанных сертификатов, потому что при запуске такого CA локально не возникает никаких ошибок доверия.

В принципе, запустить и настроить собственный CA можно и другими средствами, но это требует нетривиальных знаний и навыков. Здесь всё делает само собой, без всяких дополнительных ключей и настроек. Просто устанавливаем программу — и она автоматически создаёт локальный центр сертификации и прописывает его в доверенное хранилище системы и доверенное хранилище Firefox.

$ mkcert -install
Created a new local CA at "/Users/filippo/Library/Application Support/mkcert" 
The local CA is now installed in the system trust store! ️
The local CA is now installed in the Firefox trust store (requires restart)!

Сертификат SSL

не является доверенным — qaru

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

.

nginx ssl_trusted_certificate директива не работает

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

ssl — Как установить доверенный сертификат ЦС на Android-устройство?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

.Сертификат

— доверяйте самоподписанному сертификату из IIS

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

No related posts.