Центр сертификации - Certificate authority

В криптография, а центр сертификации или же Центр сертификации (CA) - это объект, который выдает цифровые сертификаты. Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата. Это позволяет другим (полагающимся сторонам) полагаться на подписи или утверждения о закрытом ключе, который соответствует сертифицированному открытому ключу. ЦС действует как доверенная третья сторона - доверенная как субъектом (владельцем) сертификата, так и стороной, полагающейся на сертификат. Формат этих сертификатов определяется стандартом X.509 или EMV.

Одним из наиболее распространенных способов использования центров сертификации является подписание сертификатов, используемых в HTTPS, протокол безопасного просмотра Интернет-страниц. Другое распространенное использование - это выдача удостоверений личности национальными правительствами для использования в документах с электронной подписью.[1]

Обзор

Надежные сертификаты можно использовать для создания безопасные соединения на сервер через Интернет. Сертификат необходим для обхода злоумышленника, который оказывается на пути к целевому серверу, который действует так, как если бы он был целью. Такой сценарий обычно называют атака "человек посередине". Клиент использует сертификат CA для проверки подлинности подписи CA на сертификате сервера как часть авторизации перед запуском безопасного соединения. Обычно клиентское программное обеспечение, например браузеры, включает набор доверенных сертификатов ЦС. Это имеет смысл, поскольку многие пользователи должны доверять своему клиентскому программному обеспечению. Злонамеренный или скомпрометированный клиент может пропустить любую проверку безопасности и по-прежнему заставить своих пользователей поверить в обратное.

Клиенты CA - это супервизоры серверов, которые запрашивают сертификат, который их серверы будут предоставлять пользователям. Коммерческие центры сертификации берут деньги за выдачу сертификатов, и их клиенты ожидают, что сертификат центра сертификации будет содержаться в большинстве веб-браузеров, так что безопасные соединения с сертифицированными серверами будут эффективно работать сразу после установки. Количество интернет-браузеров, других устройств и приложений, доверяющих определенному центру сертификации, называется повсеместностью. Mozilla, являющаяся некоммерческой организацией, выдает несколько коммерческих сертификатов ЦС вместе со своими продуктами.[2] Хотя Mozilla разработала свою собственную политику, CA / Форум браузеров разработали аналогичные руководящие принципы для доверия CA. Один сертификат CA может совместно использоваться несколькими CA или их реселлеры. А корень Сертификат CA может быть основой для выдачи нескольких средний Сертификаты ЦС с различными требованиями к проверке.

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

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

Коммерческие банки, выпускающие EMV платежные карты регулируются центром сертификации EMV,[3] схемы оплаты, которые направляют платежные транзакции, инициированные в терминалах точек продаж (POS ) в банк-эмитент карты для перевода средств с банковского счета держателя карты на банковский счет получателя платежа. Каждая платежная карта вместе с данными карты представляет в POS Сертификат эмитента карты. Сертификат эмитента подписан сертификатом ЦС EMV. POS извлекает открытый ключ EMV CA из своего хранилища, проверяет сертификат эмитента и подлинность платежной карты перед отправкой платежного запроса в схему оплаты.

Браузеры и другие виды клиентов, как правило, позволяют пользователям добавлять сертификаты CA или отменять их по своему усмотрению. В то время как сертификаты сервера обычно действуют в течение относительно короткого периода, сертификаты ЦС дополнительно расширяются,[4] Таким образом, для многократно посещаемых серверов импорт и доверие к выданному ЦС менее подвержены ошибкам, чем подтверждать исключение безопасности каждый раз, когда сертификат сервера обновляется.

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

Провайдеры

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

Однако рынок всемирно доверенных Сертификаты серверов TLS / SSL в основном принадлежит небольшому количеству транснациональных компаний. Этот рынок имеет значительные барьеры для входа из-за технических требований.[5] Хотя это не требуется по закону, новые поставщики могут выбрать ежегодный аудит безопасности (например, WebTrust[6] для центров сертификации в Северной Америке и ETSI в Европе[7]) для включения в качестве доверенного корня веб-браузером или операционной системой.

По состоянию на 24 августа 2020 г., 147 корневых сертификатов, представляющих 52 организации, доверяют Mozilla Firefox веб-браузер,[8] 168 корневых сертификатов, представляющих 60 организаций, доверяют macOS,[9] и 255 корневых сертификатов, представляющих 101 организацию, доверяют Майкрософт Виндоус.[10] Начиная с Android 4.2 (Jelly Bean), Android в настоящее время содержит более 100 центров сертификации, которые обновляются с каждым выпуском.[11]

18 ноября 2014 года группа компаний и некоммерческих организаций, включая Electronic Frontier Foundation, Mozilla, Cisco и Akamai, объявила Давайте зашифровать, некоммерческий центр сертификации, который бесплатно предоставляет проверенный домен Сертификаты X.509 а также программное обеспечение для установки и обслуживания сертификатов.[12] Let's Encrypt управляется недавно созданной Исследовательская группа по интернет-безопасности, калифорнийская некоммерческая организация, освобожденная от уплаты налогов.[13]

Согласно NetCraft в мае 2015 года, отраслевой стандарт для мониторинга активных сертификатов TLS гласит: «Хотя глобальная экосистема [TLS] является конкурентоспособной, в ней доминируют несколько основных центров сертификации - учетная запись трех центров сертификации (Symantec, Comodo, GoDaddy). для трех четвертей всех выданных сертификатов [TLS] на общедоступных веб-серверах. Первое место занимала Symantec (или VeriSign до того, как она была приобретена Symantec) с момента начала [нашего] исследования, и в настоящее время на нее приходится только менее одной трети всех сертификатов. Чтобы проиллюстрировать влияние различных методологий, среди миллиона наиболее загруженных сайтов Symantec выпустила 44% действующих и надежных сертификатов, что значительно превышает ее общую долю на рынке ».[14]

Обновленный опрос W3Techs показывает, что IdenTrust, лицо, подписывающее Давайте зашифровать промежуточные звенья,[15] остается самым популярным центром сертификации SSL, в то время как Symantec выпала из чарта из-за того, что его услуги безопасности были приобретены DigiCert. Sectigo (ранее Comodo CA) - третий по величине центр сертификации SSL с 17,7% рынка:[16][17] Digicert поддерживает GeoTrust, Digicert, Thawte, и бренды RapidSSL. [18]

КлассифицироватьЭмитентиспользованиеРыночная доля
1IdenTrust38.0%51.2%
2DigiCert14.6%19.7%
3Sectigo13.1%17.7%
4GoDaddy5.1%6.9%
5GlobalSign2.2%3.0%
6Certum0.4%0.7%
7Actalis0.2%0.3%
8Доверить0.2%0.3%
9Secom0.1%0.3%
10Давайте зашифровать0.1%0.2%
11Trustwave0.1%0.1%
12Группа WISeKey< 0.1%0.1%
13StartCom< 0.1%0.1%
14Сетевые решения< 0.1%0.1%

Стандарты валидации

Коммерческие центры сертификации, которые выдают большую часть сертификатов для серверов HTTPS, обычно используют метод, называемый "проверка домена "для аутентификации получателя сертификата. Методы, используемые для проверки домена, различаются в зависимости от центра сертификации, но в целом методы проверки домена предназначены для доказательства того, что заявитель сертификата контролирует данный доменное имя, а не какие-либо сведения о личности заявителя.

Многие центры сертификации также предлагают Расширенная проверка (EV) сертификаты как более строгая альтернатива сертификатам, подтвержденным доменом. Расширенная проверка предназначена для проверки не только контроля над доменным именем, но и дополнительной идентификационной информации, которая должна быть включена в сертификат. Некоторые браузеры отображают эту дополнительную идентификационную информацию в зеленом поле в строке URL. Одним из ограничений EV как решения слабых сторон валидации домена является то, что злоумышленники все еще могут получить подтвержденный доменом сертификат для домена жертвы и развернуть его во время атаки; если это произойдет, то различие, заметное для пользователя-жертвы, будет заключаться в отсутствии зеленой полосы с названием компании. Есть некоторый вопрос относительно того, будут ли пользователи, вероятно, распознавать это отсутствие как свидетельство того, что атака продолжается: тест с использованием Internet Explorer 7 в 2009 году показал, что отсутствие предупреждений IE7 о EV не было замечено пользователями, однако текущий браузер Microsoft, Край, показывает значительно большую разницу между сертификатами EV и сертификатами, подтвержденными доменом, при этом сертификаты, подтвержденные доменом, имеют пустой серый замок.

Слабые стороны валидации

Проверка домена страдает определенными структурными ограничениями безопасности. В частности, он всегда уязвим для атак, которые позволяют злоумышленнику наблюдать за проверками домена, которые отправляют центры сертификации. Сюда могут входить атаки на протоколы DNS, TCP или BGP (в которых отсутствует криптографическая защита TLS / SSL) или взлом маршрутизаторов. Такие атаки возможны как в сети рядом с центром сертификации, так и возле самого домена жертвы.

Один из наиболее распространенных методов проверки домена включает отправку электронного письма, содержащего токен аутентификации или ссылку на адрес электронной почты, который, вероятно, будет административно ответственным за домен. Это может быть технический контактный адрес электронной почты, указанный в доменном КТО запись или административный адрес электронной почты, например админ @, администратор @, веб-мастер@, hostmaster @ или же почтмейстер @ домен.[19][20] Некоторые центры сертификации могут принимать подтверждение, используя корень@,[нужна цитата ] Информация@, или же поддерживать@ в домене.[21] Теория, лежащая в основе проверки домена, заключается в том, что только законный владелец домена сможет читать электронные письма, отправленные на эти административные адреса.

Реализации проверки домена иногда были источником уязвимостей безопасности. В одном случае исследователи безопасности показали, что злоумышленники могут получить сертификаты для сайтов веб-почты, потому что ЦС был готов использовать адрес электронной почты, например [email protected] для domain.com, но не все системы веб-почты зарезервировали имя пользователя ssladmin, чтобы предотвратить его регистрацию злоумышленниками.[22]

До 2011 года не существовало стандартного списка адресов электронной почты, которые можно было бы использовать для проверки домена, поэтому администраторам электронной почты было непонятно, какие адреса необходимо зарезервировать. Первая версия CA / Форум браузеров Базовые требования, принятые в ноябре 2011 г., содержат перечень таких адресов. Это позволило почтовым хостам зарезервировать эти адреса для административного использования, хотя такие меры все еще не универсальны. В январе 2015 года финн зарегистрировал имя пользователя hostmaster в финской версии Microsoft Live и смог получить подтвержденный доменом сертификат для live.fi, несмотря на то, что не являлся владельцем доменного имени.[23]

Выдача справки

Процедура получения Сертификат открытого ключа

Проблемы с CA цифровые сертификаты которые содержат открытый ключ и личность владельца. Соответствующий закрытый ключ не является общедоступным, но хранится в секрете конечным пользователем, создавшим пару ключей. Сертификат также является подтверждением или подтверждением CA того, что открытый ключ, содержащийся в сертификате, принадлежит лицу, организации, серверу или другому объекту, указанному в сертификате. Обязанность ЦС в таких схемах заключается в проверке учетных данных заявителя, чтобы пользователи и доверяющие стороны могли доверять информации в сертификатах ЦС. Для этого центры сертификации используют различные стандарты и тесты. По сути, центр сертификации отвечает за то, чтобы сказать: «Да, этот человек является тем, кем они себя называют, и мы, ЦС, это подтверждаем».[24]

Если пользователь доверяет ЦС и может проверить подпись ЦС, то они также могут предположить, что определенный открытый ключ действительно принадлежит тому, кто указан в сертификате.[25]

Пример

Криптография с открытым ключом может использоваться для шифрования данных, передаваемых между двумя сторонами. Обычно это может произойти, когда пользователь входит на любой сайт, который реализует HTTP Secure протокол. В этом примере предположим, что пользователь входит на домашнюю страницу своего банка www.bank.example, чтобы выполнить онлайн-банкинг. Когда пользователь открывает домашнюю страницу www.bank.example, он получает открытый ключ вместе со всеми данными, которые отображает его веб-браузер. Открытый ключ может использоваться для шифрования данных от клиента к серверу, но безопасная процедура заключается в использовании его в протоколе, который определяет временный общий симметричный ключ шифрования; сообщения в таком протоколе обмена ключами могут быть зашифрованы открытым ключом банка таким образом, что только сервер банка имеет закрытый ключ для их чтения.[26]

Остальная часть связи затем продолжается с использованием нового (одноразового) симметричного ключа, поэтому, когда пользователь вводит некоторую информацию на страницу банка и отправляет страницу (отправляет информацию обратно в банк), тогда данные, которые пользователь ввел на страницу будут зашифрованы их веб-браузером. Следовательно, даже если кто-то может получить доступ к (зашифрованным) данным, которые были переданы пользователем на www.bank.example, такой перехватчик не сможет их прочитать или расшифровать.

Этот механизм безопасен только в том случае, если пользователь может быть уверен, что это банк, который он видит в своем веб-браузере. Если пользователь вводит www.bank.example, но его связь перехвачена и поддельный веб-сайт (который выдает себя за веб-сайт банка) отправляет информацию о странице обратно в браузер пользователя, поддельная веб-страница может отправить поддельный открытый ключ. пользователю (для которого поддельный сайт владеет соответствующим закрытым ключом). Пользователь заполнит форму своими личными данными и отправит страницу. Поддельная веб-страница получит доступ к данным пользователя.

Это то, что механизм центра сертификации призван предотвратить. Центр сертификации (ЦС) - это организация, которая хранит открытые ключи и их владельцев, и каждая сторона в коммуникации доверяет этой организации (и знает ее открытый ключ). Когда веб-браузер пользователя получает открытый ключ от www.bank.example, он также получает цифровую подпись ключа (с некоторой дополнительной информацией в так называемом X.509 сертификат). Браузер уже имеет открытый ключ CA и, следовательно, может проверить подпись, доверять сертификату и открытому ключу в нем: поскольку www.bank.example использует открытый ключ, который сертифицирует центр сертификации, поддельный www.bank.example может использовать только один и тот же открытый ключ. Поскольку поддельный www.bank.example не знает соответствующего закрытого ключа, он не может создать подпись, необходимую для проверки его подлинности.[27]

Безопасность

Трудно гарантировать правильность соответствия между данными и объектом, когда данные представлены в CA (возможно, через электронную сеть), и когда аналогичным образом представлены учетные данные человека / компании / программы, запрашивающей сертификат. Вот почему коммерческие центры сертификации часто используют комбинацию методов аутентификации, включая использование государственных бюро, платежной инфраструктуры, баз данных и сервисов третьих сторон, а также пользовательской эвристики. В некоторых корпоративных системах локальные формы аутентификации, такие как Kerberos может использоваться для получения сертификата, который, в свою очередь, может использоваться внешними полагающимися сторонами. Нотариусы в некоторых случаях требуется лично знать сторону, подпись которой нотариально удостоверяется; это более высокий стандарт, чем достигается многими центрами сертификации. Согласно Американская ассоциация адвокатов изложить в отношении управления онлайн-транзакциями основные положения федеральных законов и законодательных актов штата США, касающихся цифровые подписи был призван «предотвратить противоречивые и чрезмерно обременительные местные правила и установить, что электронные письма удовлетворяют традиционным требованиям, связанным с бумажными документами». Кроме того, закон США об электронной подписи и предлагаемый код UETA[28] помочь гарантировать, что:

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

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

В крупномасштабных развертываниях Алиса может быть не знакома с центром сертификации Боба (возможно, каждый из них имеет свой сервер CA), поэтому сертификат Боба может также включать открытый ключ его CA, подписанный другим CA2, который предположительно узнает Алиса. Этот процесс обычно приводит к иерархии или сети центров сертификации и сертификатов CA.

Списки отзыва полномочий

An список отозванных полномочий (ARL) - это форма список отзыва сертификатов (CRL) содержащие сертификаты, выданные центрам сертификации, в отличие от списков отзыва сертификатов, которые содержат отозванные сертификаты конечных объектов.

Отраслевые организации

  • Совет Безопасности Центра Сертификации (CASC) - В феврале 2013 года CASC была основана как отраслевая правозащитная организация, занимающаяся решением отраслевых проблем и обучением общественности вопросам безопасности в Интернете. Членами-основателями являются семь крупнейших центров сертификации.[31][32]
  • Форум по общим стандартам безопасности вычислений (CCSF) - В 2009 году CCSF была основана для продвижения отраслевых стандартов, защищающих конечных пользователей. Comodo Group Исполнительный директор Мелих Абдулхайоглу считается основателем CCSF.[33]
  • CA / Форум браузеров - В 2005 году был сформирован новый консорциум центров сертификации и поставщиков веб-браузеров для продвижения отраслевых стандартов и базовых требований к безопасности в Интернете. Comodo Group Исполнительный директор Мелих Абдулхайоглу организовал первую встречу и считается основателем CA / Browser Forum.[34][35]

Базовые требования

Форум CA / Browser публикует базовые требования,[36] список политик и технических требований, которым должны следовать центры сертификации. Это требование для включения в хранилища сертификатов Firefox.[37] и Safari.[38]

Компрометация CA

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

Например, предположим, что злоумышленник, Ева, сумел заставить ЦС выдать ей сертификат, который утверждает, что представляет Алису. То есть в сертификате будет публично заявлено, что он представляет Алису, и может быть включена другая информация об Алисе. Некоторая информация об Алисе, например имя ее работодателя, может быть правдой, что повышает надежность сертификата. Однако у Евы будет важнейший закрытый ключ, связанный с сертификатом. Затем Ева могла использовать сертификат для отправки Бобу электронной почты с цифровой подписью, обманывая Боба, заставляя его поверить в то, что письмо было от Алисы. Боб может даже ответить зашифрованным электронным письмом, полагая, что его может прочитать только Алиса, когда Ева действительно сможет расшифровать его, используя закрытый ключ.

Заметный случай подобной подрывной деятельности ЦС произошел в 2001 году, когда центр сертификации VeriSign выдал два сертификата лицу, заявляющему, что представляет Microsoft. Сертификаты носят название «Корпорация Microsoft», поэтому их можно использовать, чтобы заставить кого-то поверить в то, что обновления программного обеспечения Microsoft поступают от Microsoft, хотя на самом деле это не так. Мошенничество было обнаружено в начале 2001 года. Microsoft и VeriSign приняли меры, чтобы ограничить влияние проблемы.[39][40]

В 2011 году были получены поддельные сертификаты от Comodo и DigiNotar,[41][42] предположительно иранскими хакерами. Есть свидетельства того, что поддельные сертификаты DigiNotar использовались в атака "человек посередине" в Иране.[43]

В 2012 году стало известно, что Trustwave выпустила подчиненный корневой сертификат, который использовался для прозрачного управления трафиком (man-in-the-middle), что фактически позволяло предприятию прослушивать внутренний сетевой трафик SSL с использованием подчиненного сертификата.[44]

Хранение ключей

Злоумышленник, который крадет закрытые ключи центра сертификации, может подделать сертификаты, как если бы они были ЦС, без необходимости постоянного доступа к системам ЦС. Таким образом, кража ключей является одним из основных рисков, от которых защищаются центры сертификации. Публично доверенные центры сертификации почти всегда хранят свои ключи на аппаратный модуль безопасности (HSM), который позволяет им подписывать сертификаты с помощью ключа, но обычно предотвращает извлечение этого ключа с помощью физических и программных средств управления. Центры сертификации обычно принимают дополнительные меры предосторожности, сохраняя ключ на долгое время. корневые сертификаты в HSM, который хранится не в сети, за исключением случаев, когда необходимо подписывать более короткие промежуточные сертификаты. Промежуточные сертификаты, хранящиеся в онлайн-HSM, могут выполнять повседневную работу по подписанию сертификатов конечных объектов и обновлению информации об отзыве.

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

Слабость реализации доверенной сторонней схемы

Критическая слабость в реализации текущей схемы X.509 заключается в том, что любой CA, которому доверяет определенная сторона, может затем выдавать сертификаты для любого домена по своему выбору. Такие сертификаты будут приняты доверяющей стороной как действительные независимо от того, являются ли они законными и авторизованными или нет.[45] Это серьезный недостаток, учитывая, что наиболее часто встречающейся технологией, использующей X.509 и доверенные третьи стороны, является протокол HTTPS. Поскольку все основные веб-браузеры распространяются среди своих конечных пользователей с предварительно настроенным списком доверенных центров сертификации, который исчисляется десятками, это означает, что любой из этих предварительно утвержденных доверенных центров сертификации может выдать действительный сертификат для любого домена.[46] Реакция отрасли на это была приглушенной.[47] Учитывая, что содержимое предварительно настроенного списка доверенных центров сертификации браузера определяется независимо стороной, которая распространяет или вызывает установку приложения браузера, сами центры сертификации ничего не могут сделать.

Этот вопрос является движущей силой развития Аутентификация именованных объектов на основе DNS (DANE) протокол. Если принято вместе с Расширения безопасности системы доменных имен (DNSSEC) DANE значительно снизит, если не полностью устранит роль доверенных третьих сторон в PKI домена.

Смотрите также

Рекомендации

  1. ^ https://searchsecurity.techtarget.com/definition/certificate-authority
  2. ^ «Список сертификатов ЦС, включенных в Mozilla - Mozilla». Mozilla.org. В архиве из оригинала 2013-08-04. Получено 2014-06-11.
  3. ^ «EMV CA». Центр сертификации EMV по всему миру. 2 октября 2010 г.. Получено 17 февраля, 2019.
  4. ^ Закир Дурумерик; Джеймс Кастен; Майкл Бейли; Дж. Алекс Халдерман (12 сентября 2013 г.). «Анализ экосистемы сертификатов HTTPS» (PDF). Конференция по Интернет-измерениям. SIGCOMM. В архиве (PDF) из оригинала 22 декабря 2013 г.. Получено 20 декабря 2013.
  5. ^ "Что такое SSL-сертификат?". В архиве из оригинала от 03.11.2015. Получено 2015-10-16.
  6. ^ "веб-доверие". webtrust. В архиве из оригинала 18.08.2013. Получено 2013-03-02.
  7. ^ Кирк Холл (апрель 2013 г.). «Стандарты и отраслевые правила, применимые к органам сертификации» (PDF). Trend Micro. В архиве (PDF) из оригинала от 04.03.2016. Получено 2014-06-11.
  8. ^ "CA: IncludedCAs - MozillaWiki". wiki.mozilla.org. В архиве из оригинала на 2017-03-25. Получено 2017-03-18.
  9. ^ «Список доступных доверенных корневых сертификатов в macOS High Sierra». Служба поддержки Apple. Получено 2020-08-24.
  10. ^ «Список сертификатов ЦС, включенных Microsoft». ccadb-public.secure.force.com. Получено 2020-08-24.
  11. ^ «Безопасность с HTTPS и SSL». developer.android.com. В архиве из оригинала на 2017-07-08. Получено 2017-06-09.
  12. ^ «Let's Encrypt: доставка SSL / TLS везде» (Пресс-релиз). Давайте зашифровать. В архиве из оригинала 18.11.2014. Получено 2014-11-20.
  13. ^ "О". Давайте зашифровать. В архиве из оригинала от 10.06.2015. Получено 2015-06-07.
  14. ^ «Подсчет SSL-сертификатов - Netcraft». news.netcraft.com. В архиве из оригинала от 16.05.2015.
  15. ^ «Let's Encrypt - цепочка доверия». Давайте зашифровать. Получено 2018-06-08. ... промежуточное звено [Let's Encrypt] ... перекрестно подписано другим центром сертификации, IdenTrust, корень которого уже пользуется доверием во всех основных браузерах.
  16. ^ «DigiCert завершает приобретение подразделения Symantec по обеспечению безопасности веб-сайтов». Symantec (Пресс-релиз). 31 октября 2017 г.. Получено 2018-06-08.
  17. ^ «Использование центров сертификации SSL для веб-сайтов». 2018-05-28. Получено 2018-06-08.
  18. ^ https://www.eweek.com/security/symantec-selling-ssl-security-business-to-digicert-for-950m
  19. ^ «Архивная копия» (PDF). В архиве (PDF) из оригинала от 23.03.2015. Получено 2015-03-20.CS1 maint: заархивированная копия как заголовок (связь)
  20. ^ «CA / Запрещенные или проблемные методы - MozillaWiki». wiki.mozilla.org. В архиве из оригинала от 21.07.2017. Получено 2017-07-06.
  21. ^ «SSL FAQ - Часто задаваемые вопросы - Rapid SSL». www.rapidssl.com. В архиве из оригинала от 06.02.2015.
  22. ^ Зусман, Майк (2009). Уголовное дело не возбуждено: взлом PKI (PDF). DEF CON 17. Лас-Вегас. В архиве (PDF) из оригинала от 15.04.2013.
  23. ^ «Мужчина из Финляндии создал эту простую учетную запись электронной почты и получил сертификат безопасности Microsoft». tivi.fi. В архиве из оригинала от 08.08.2015.
  24. ^ «Обязанности центра сертификации». В архиве из оригинала от 12.02.2015. Получено 2015-02-12.
  25. ^ «Сетевой мир». 17 января 2000 г.
  26. ^ https://www.google.com/books/edition/Applied_Cryptography_and_Network_Securit/GggFlaVxyVQC?hl=en&gbpv=1&dq=applied+cryptography+certificate+issuance&pg=PA281&printsec=frontcover
  27. ^ https://www.google.com/books/edition/The_Shortcut_Guide_to_Managing_Certifica/BdJi5AQRzsIC?hl=en&gbpv=1&dq=digital+certificate+issuance&pg=PA40&printsec=frontcover
  28. ^ «Электронные подписи и записи» (PDF). В архиве (PDF) из оригинала от 04.03.2016. Получено 2014-08-28.
  29. ^ «Прозрачность сертификата». В архиве из оригинала 01.11.2013. Получено 2013-11-03.
  30. ^ «Прозрачность сертификата». Инженерная группа Интернета. В архиве из оригинала 22.11.2013. Получено 2013-11-03.
  31. ^ «Совет по многовендору сформирован для решения проблем с цифровыми сертификатами». Сетевой мир. 14 февраля 2013 г. Архивировано с оригинал 28 июля 2013 г.
  32. ^ «Основные центры сертификации объединяются во имя безопасности SSL». Темное чтение. 14 февраля 2013 г. Архивировано с оригинал 10 апреля 2013 г.
  33. ^ "Основатель CA / Browser Forum". В архиве из оригинала от 23.08.2014. Получено 2014-08-23.
  34. ^ "CA / Browser Forum". В архиве из оригинала на 2013-05-12. Получено 2013-04-23.
  35. ^ Уилсон, Уилсон. "История форума CA / браузера" (PDF). DigiCert. В архиве (PDF) из оригинала на 2013-05-12. Получено 2013-04-23.
  36. ^ «Базовые требования». CAB Forum. В архиве из оригинала 7 января 2014 г.. Получено 14 апреля 2017.
  37. ^ «Политика корневого хранилища Mozilla». Mozilla. В архиве с оригинала 15 апреля 2017 г.. Получено 14 апреля 2017.
  38. ^ «Программа корневых сертификатов Apple». Яблоко. В архиве из оригинала 20 марта 2017 г.. Получено 14 апреля 2017.
  39. ^ "СА-2001-04". Cert.org. В архиве из оригинала 2013-11-02. Получено 2014-06-11.
  40. ^ Microsoft, Inc. (21 февраля 2007 г.). «Бюллетень по безопасности Microsoft MS01-017: ошибочные цифровые сертификаты, выпущенные VeriSign, создают опасность спуфинга». В архиве из оригинала от 26.10.2011. Получено 2011-11-09.
  41. ^ Брайт, Питер (28 марта 2011 г.). «Независимый иранский хакер взял на себя ответственность за взлом Comodo». Ars Technica. В архиве из оригинала 29 августа 2011 г.. Получено 2011-09-01.
  42. ^ Брайт, Питер (30.08.2011). «Другой поддельный сертификат вызывает те же старые вопросы о центрах сертификации». Ars Technica. В архиве из оригинала от 12.09.2011. Получено 2011-09-01.
  43. ^ Лейден, Джон (06.09.2011). «Внутри операции« Черный тюльпан »: анализ взлома DigiNotar». Реестр. В архиве из оригинала от 03.07.2017.
  44. ^ «Trustwave выдал сертификат посредника». Безопасность H. 2012-02-07. В архиве из оригинала от 13.03.2012. Получено 2012-03-14.
  45. ^ Осборн, Чарли. "Symantec увольняет сотрудников за выдачу несанкционированных сертификатов Google - ZDNet". zdnet.com. В архиве из оригинала от 02.10.2016.
  46. ^ «Обнаружены неавторизованные цифровые сертификаты Google». linkedin.com. 12 августа 2014 г.
  47. ^ "Могут ли государственные ЦС по-прежнему считаться" надежными третьими сторонами "после несанкционированной выдачи сертификатов индийской сетевой картой CA?". casecurity.org. 24 июля 2014 г. В архиве из оригинала от 3 октября 2016 г.

внешняя ссылка