Что такое цепочка сертификатов
Что такое корневой сертификат (СА)
Термин «корневой сертификат» хорошо знаком тем, кто занимается продвижением веб-ресурсов. Это объясняется легко – попадают в топ-10 поисковых систем преимущественно «доверенные» сайты, с подключенным SSL-сертификатом (протокол HTTPS). Без него тот же Google Chrome ставит в адресной строке метку с открытым замком, а то и вовсе блокирует вход на страницу.
Что представляет собой корневой сертификат (CA)
Защищенное соединение гарантирует шифрование информации, передаваемой между сервером и клиентом. Кроме того, оно подтверждает подлинность ресурса, обеспечивая тем самым защиту от фишинга с целью кражи персональных данных (от ФИО до номера банковской карты вместе с секретным CVC-кодом). Шифрование «обесценивает» перехват, который возможен как локально, на уровне роутера в квартире, так и на удаленном сервере.
Корневой сертификат (CA) представляет собой часть ключа SSL, которым центр сертификации подписывает выпускаемые сертификаты. Наличие CA гарантирует, что выдавшая его организация верифицирована и легальна.
Именные сертификаты, выдаваемые центрами вроде Comodo или Symantec, ценятся больше.
Ценность сертификата очень важна, потому что распространенные браузеры умеют идентифицировать лицо, выпускающее CA, и проверять его легитимность. Если у сайта нет «поручителя», он будет считаться недостоверным, даже несмотря на полную безопасность для конечного пользователя. Такое иногда происходит с бесплатными сертификатами типа Let’s Encrypt (генерируются автоматически после регистрации домена в панели управления хостингом).
Корневой сертификат зависит от остальных «частей» SSL – промежуточной и индивидуальной. Они выдаются одновременно и вносятся в соответствующие поля при ручной настройке безопасности. Фактически создается цепочка взаимной проверки, когда корневой сертификат подтверждает иные части ключа. Если ответ на запрос верен, браузер помечает веб-ресурс как защищенный (замочек в адресной строке) и открывает его без каких-либо предупреждений.
Где взять корневой сертификат
SSL-сертификат (вместе с CA) выдается удостоверяющими центрами. К наиболее популярным центрам сертификации относятся Let’s Encrypt, Comodo, Symantec, Digicert, GeoTrust. Купить сертификат можно на сайте одного из центров или воспользоваться панелью управления хостинг-провайдера.
Разновидности сертификатов (на примере провайдера Timeweb):
Сертификаты из трех последних пунктов высылаются в виде ZIP-архива или текстового сообщения с указанием всех «частей» SSL, в том числе корневого. То же происходит при продлении услуги (после оплаты) – за 30 дней до завершения периода ранее купленного сертификата обычно становится доступной функция продления.
Можно ли создать корневой сертификат самостоятельно?
Рядовому пользователю выпустить корневой сертификат нереально. Все существующие варианты для этого применяются только на период локального тестирования веб-ресурса, когда нет разницы, как воспринимает браузер такой CA. Чтобы создать легитимный ключ безопасности, понадобится самому стать «центром сертификации». Это хлопотное и затратное дело, поэтому проще обратиться к одной из существующих организаций.
Технология создания простейшего CA в ОС Windows:
Последнее выполняется выбором нужного доменного имени в подразделе «Подключения» раздела «Сертификаты сервера». В столбце «Действия» нужно нажать на «Привязки…», в открывшемся окне «Добавление привязки сайта» ввести сведения о привязке и нажать «ОК». После создания сертификата остается экспортировать приватный ключ и задать пароль на выполнение изменений.
Немного о SSL-сертификатах: Какой выбрать и как получить
20 июля компания Google объявила о том, что браузер Chrome перестает считать доверенными SSL-сертификаты, выданные центром сертификации (CA) WoSign и его дочерним предприятием StartCom. Как пояснили в компании, решение связано с рядом инцидентов, не соответствующим высоким стандартам CA, — в частности, выдаче сертификатов без авторизации со стороны ИТ-гиганта.
Чуть ранее в этом году также стало известно, что организации, ответственные за выдачу сертификатов, должны будут начать учитывать специальные DNS-записи. Эти записи позволят владельцам доменов определять «круг лиц», которым будет дозволено выдавать SSL/TLS-сертификаты для их домена.
Все эти решения в какой-то степени связаны с увеличением числа хакерских атак и фишинговых сайтов. Зашифрованные соединения с веб-сайтами по HTTPS приобретают всё большее распространение в интернете. Сертификаты не только позволяют зашифровать данные, пересылаемые между браузером и веб-сервером, но и удостоверить организацию, которой принадлежит сайт. В сегодняшнем материале мы посмотрим, какие виды сертификатов бывают и коснемся вопросов их получения.
Все SSL-сертификаты используют одинаковые методы защиты данных. Для аутентификации применяются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Однако при этом они различаются по методу проверки: любой сертификат должен быть верифицирован центром сертификации, дабы удостовериться, что он принадлежит корректному и авторизованному сайту. Выделяют несколько видов сертификатов.
Первый тип сертификатов — это сертификаты с проверкой домена (Domain Validated). Они подходят для некоммерческих сайтов, поскольку подтверждают только обслуживающий сайт веб-сервер, на который осуществлён переход. DV-сертификат не содержит идентифицирующей информации в поле имени организации. Обычно там числится значение «Persona Not Validated» или «Unknown».
Для проверки лица запросившего сертификат центр сертификации высылает письмо на электронный адрес, связанный с доменным именем (например, admin@yourdomainname.com). Это делается для того, чтобы удостовериться, что лицо, запросившее сертификат, действительно является владельцем доменного имени. Компании 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. Такие защищенные каналы связи можно с легкостью использовать для внутренних нужд компании: для обмена между устройствами сети или приложениями. Однако для использования на внешнем веб-сайте необходимо покупать официальный сертификат. В этом случае браузеры не будут показывать сообщения о небезопасном соединении, а будут спокойны за пересылаемые данные.
Цепочка сертификатов: корневой, промежуточные
Comodo
Корневой (Root) и промежуточный (Intermediate) сертификаты отправляются одним файлом вместе с основным сертификатом. В зависимости от типа сертификата, цепочка выглядит следующим образом:
InstantSSL
EssentialSSL
PositiveSSL
Скачать архив с цепочкой сертификатов можно на сайте Comodo. По умолчанию, начиная с 2014 года, новые сертификаты от данного центра выпускаются в алгоритме шифрования SHA-2, который является более безопасным. Так как не все клиентские программы поддерживают новый алгоритм, еще остается возможность получить цепочку сертификата в алгоритме SHA-1.
Примечание: Архивы с префиксом [OLD] относятся к сертификатам, выпущенным ранее 2012 гогда.
GeoTrust
Центр сертификации присылает сертификат не архивом, а в теле письма. Он расположен под заголовком INTERMEDIATE CA.
Скачать полную цепочку сертификата можно на следующих страницах официального сайта GeoTrust:
RapidSSL – на этой странице.
QuickSSL, QuickSSL Premium – здесь.
True BusinessID / True BusinessID Wildcard / True BusinessID with EV – здесь.
Thawte
VerySign
Предлагает скачать Root и Intermediate сертификаты на странице.
Примечание: Каждый центр сертификации может предлагать для скачивания промежуточные сертификаты в зависимости от года выпуска сертификата, длины ключа шифрования, алгоритма шифрования. Пожалуйста, обращайте внимание на эти параметры, иначе соединение в случае установки несоответствующего сертификата не будет доверенным.
Если же не установить промежуточный сертификат, шифрованное соединение может и вовсе не работать.
У нас вы можете купить разные типы сертификатов (DV, OV, EV, Wildcard SSL). При возникновении вопросов обращайтесь в поддержку.
Читайте здесь, зачем нужен SSL-сертификат.
Что такое корневой сертификат (СА)
Корневой сертификат (СА) — часть ключа, которым центры сертификации подписывают выпущенные SSL-сертификаты. Выдавая корневой сертификат, каждый такой центр гарантирует, что пользователи или организации, запросившие SSL, верифицированы и действия с доменом легальны.
Центры сертификации с двадцатилетней историей: GlobalSign, Comodo, Symantec, TrustWave, GeoTrust. Они используют «именные» корневые сертификаты, которые распознаются большинством современных браузеров.
Это значит: если на сайт установлен корневой сертификат GlobalSign, браузер идентифицирует его как выпущенный доверенным «поручителем» и приступает к частной проверке сайта.
Если информация о корневом сертификате центра отсутствует в браузере, у сайта нет «поручителя», и браузер считает его недостоверным. Так иногда происходит с самоподписанными сертификатами безопасности (например, Let’s Encrypt):
Однако одного корневого сертификата недостаточно. Чтобы конкретный домен считался защищенным, помимо корневого сертификата необходимы промежуточный сертификат и индивидуальный сертификат домена, которые так же выдаются центром сертификации при выпуске SSL. Достоверность промежуточных и «индивидуальных» сертификатов подтверждается корневым сертификатом. Цепочка сертификатов, установленных на сайт, дает основание считать его «защищенным SSL-сертификатом» в сети Интернет.
Данные вашего сайта под защитой
Установите SSL-сертификат, и ваш сайт будет работать по безопасному соединению HTTPS
Где взять корневой сертификат?
Корневые сертификаты выдают сертификационные центры. REG.RU сотрудничает с шестью сертификационными центрами. Выберите SSL-сертификат, который подходит для ваших целей, и закажите его со страницы SSL-сертификаты.
Также вы можете воспользоваться специальным предложением REG.RU и получить бесплатный SSL-сертификат на 1 год при заказе домена или хостинга. Читайте об этом в статье: Как заказать бесплатный SSL-сертификат?
После заказа SSL и его активации на указанную контактную почту придет письмо с необходимыми данными для установки сертификата на сайт (в частности, корневой сертификат). Подробнее о содержимом письма в статье Где взять данные для установки SSL-сертификата.
Могу ли я создать корневой сертификат самостоятельно?
Чтобы создать корневой сертификат самому, нужно получить статус сертификационного центра. Эта процедура связана со значительными финансовыми затратами, поэтому в большинстве случаев мы рекомендуем обращаться к существующим центрам сертификации.
Установка цепочки сертификатов
Список доверенных сертификатов, использующихся для создания цепочки, приходит в информационном письме после выпуска и активации SSL. Для установки цепочки сертификатов (в том числе, корневого) воспользуйтесь подробными инструкциями справочного раздела: Установка SSL-сертификата.
Построение цепочки доверия в PKI, так ли все просто
Инфраструктура открытых ключей (PKI) – достаточно популярная технология для обеспечения целостности и доказательства авторства в различных ИТ-системах. Порою о ее использовании человек, сидящий за компьютером, даже не подозревает, как и в случае проверки целостности программы при установке на компьютер.
Технология PKI не нова. Если считать от момента возникновения алгоритма Меркле по распределению ключа – то технологии уже 42 года, если считать от момента возникновения RSA – то 39 лет. Возраст в любом случае внушительный. За это время технология существенно эволюционировала и позволяет создать солидный список сервисов для других приложений и пользователей.
Сами сервисы регламентированы в ряде стандартов, в серии X.500 – это серия стандартов ITU-T (1993 г.) для службы распределенного каталога сети и серии RFC (Request for Comments) – документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и стандарты, широко используемые во Всемирной сети. Причем серия RFC первична. Основная масса RFC о PKI была выпущена компанией RSA, одной из отцов(мам)-основателей технологии PKI.
PKI и его стандарты
Результатом этого многообразия стало безобразие в национальных стандартах отдельных стран. Как результат – набор проблем по совместимости между различными решениями в отдельных странах и, очень часто, невозможность построения цепочки доверия между двумя пользователями технологии PKI в разных странах.
Цепочка сертификации и цепочка доверия
Прежде чем рассматривать вопрос методики построения трансграничного доверия, хотелось бы разобрать вопрос построения цепочки доверия внутри страны, взяв за пример РФ.
Для этого кратко опишу, как вообще строится базовая инфраструктура PKI и какие есть методы обеспечения доверия в PKI.
Доверие в PKI строится по принципу поручительства – например, если два человека не знают друг друга, но хотят вступить в отношения, которые требуют взаимного доверия, они ищут третьего, кому бы могли доверять они оба и кто бы поручился за каждого из них перед другим. Аналог такого человека в PKI называется третья доверенная сторона.
Одной из областей применения PKI является обеспечение юридической значимости электронного документооборота. То есть обеспечение возможности доверять электронной подписи под электронным документом. Но, следует уточнить обеспечение юридической значимости требует выполнения целого ряда условий, одним из которых является построение цепочки сертификации. В рамках данной статьи, я хотел бы детально рассмотреть только саму процедуру построения цепочки сертификации и ее взаимосвязи с цепочкой доверия.
И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ. Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван. В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США. Федеральный мостообразующий УЦ (бридж) США содержит несколько базовых служб функции которых следует разобрать в отдельной статье.
Сложности
В этот момент начинаются сложности. Сложность первая. Случается, что сертификат пользователя заполнен неправильно, не соответствует требованиям законодательства, в этом случае он должен быть перевыпущен. Как правило, подобную проблему порождает работник УЦ, который неправильно его заполнил, а проблемы получает пользователь, когда не может его нормально использовать.
Сложность вторая. Законодательство говорит о том, что УЦ – это юридическое лицо, и ГУЦ должен подписать сертификат этого УЦ. Ситуация, когда у одного юридического лица несколько комплексов УЦ и несколько сертификатов этих УЦ, толком в законах не прописана. УЦ этим пользуются, часть сертификатов не подписывают с помощью сертификата ГУЦ и делают их в лучшем случае самовыпущенными – когда цепочку к ГУЦ можно построить только по имени УЦ в сертификате – или вообще самоподписанными – когда связи между сертификатами одного УЦ технически не существует, она есть только на бумаге.
Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ. В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев. Или же СОС подписывается ключом, который не имеет отношения к сертификату УЦ, что тоже сводит шанс построить цепочку доверия к нулю. Потихоньку возникает проблема с обработкой самих СОС, за время существования УЦ они уже стали достаточно большого размера, но дельта СОС не выпускает почти никто.
Сложность четвертая, связная. Построение цепочки доверия в PKI так или иначе требует наличия связи с УЦ и ГУЦ и работу в онлайне. Работа в офлайне не предусмотрена. Существует ряд мест и приложений, где работа с подписями и сертификатами в офлайне очень бы пригодилась. Далеко не вся территория РФ охвачена качественным интернетом и каждый лишний передаваемый байт воспринимается болезненно, так как бьет по кошельку.
Сложность пятая, техническая. Иногда в программно-аппаратных комплексах УЦ все-таки находятся ошибки в логике и реализации, это также может влиять на построение цепочки доверия.
И только если на пути пользователя эти проблемы не встретились, цепочка доверия должна построится. В случае использования OCSP/TSP-служб проблемы тоже существуют, но это тема для отдельной статьи.