stringtranslate.com

Центр сертификации

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

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

Обзор

Доверенные сертификаты можно использовать для создания безопасных подключений к серверу через Интернет. Сертификат необходим для того, чтобы обойти злонамеренную сторону, которая находится на пути к целевому серверу, который действует так, как если бы он был целью. Такой сценарий обычно называют атакой «человек посередине» . Клиент использует сертификат ЦС для аутентификации подписи ЦС на сертификате сервера в рамках авторизации перед запуском безопасного соединения. [3] Обычно клиентское программное обеспечение, например браузеры, включает в себя набор доверенных сертификатов ЦС. Это имеет смысл, поскольку многим пользователям необходимо доверять своему клиентскому программному обеспечению. Вредоносный или скомпрометированный клиент может пропустить любую проверку безопасности и при этом обмануть своих пользователей, заставив их поверить в обратное.

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

Помимо коммерческих центров сертификации, некоторые некоммерческие организации бесплатно выдают общедоступные цифровые сертификаты, например Let's Encrypt . Некоторые крупные компании, занимающиеся облачными вычислениями и веб-хостингом, также являются общедоступными центрами сертификации и выдают сертификаты службам, размещенным в их инфраструктуре, например IBM Cloud , Amazon Web Services , Cloudflare и Google Cloud Platform .

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

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

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

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

Провайдеры

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

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

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

18 ноября 2014 года группа компаний и некоммерческих организаций, в том числе Electronic Frontier Foundation , Mozilla, Cisco и Akamai, объявила о создании Let's Encrypt , некоммерческого центра сертификации, который предоставляет бесплатные сертификаты X.509 с проверкой домена , а также программное обеспечение для обеспечения установка и обслуживание сертификатов. [14] Let's Encrypt управляется недавно созданной Internet Security Research Group , калифорнийской некоммерческой организацией, признанной освобожденной от федеральных налогов. [15]

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

По данным независимой исследовательской компании Netcraft , в 2020 году «DigiCert станет крупнейшим в мире центром сертификации с высокой степенью надежности, занимающим 60% рынка сертификатов расширенной проверки и 96% сертификатов, проверенных организациями во всем мире. [17]

По состоянию на апрель 2023 года исследовательская компания W3Techs, которая собирает статистику использования центров сертификации среди 10 миллионов крупнейших веб-сайтов Alexa и 1 миллиона лучших веб-сайтов Tranco, перечисляет шесть крупнейших центров сертификации по абсолютной доле использования, как показано ниже. [18]

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

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

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

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

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

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

Domain validation implementations have sometimes been a source of security vulnerabilities. In one instance, security researchers showed that attackers could obtain certificates for webmail sites because a CA was willing to use an email address like [email protected] for domain.com, but not all webmail systems had reserved the "ssladmin" username to prevent attackers from registering it.[22]

Prior to 2011, there was no standard list of email addresses that could be used for domain validation, so it was not clear to email administrators which addresses needed to be reserved. The first version of the CA/Browser Forum Baseline Requirements, adopted November 2011, specified a list of such addresses. This allowed mail hosts to reserve those addresses for administrative use, though such precautions are still not universal. In January 2015, a Finnish man registered the username "hostmaster" at the Finnish version of Microsoft Live and was able to obtain a domain-validated certificate for live.fi, despite not being the owner of the domain name.[23]

Issuing a certificate

The procedure of obtaining a Public key certificate

A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the issued certificate. CAs use a variety of standards and tests to do so. In essence, the certificate authority is responsible for saying "yes, this person is who they say they are, and we, the CA, certify that".[24]

If the user trusts the CA and can verify the CA's signature, then they can also assume that a certain public key does indeed belong to whoever is identified in the certificate.[25]

Example

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

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

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

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

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

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

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

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

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

Отзыв сертификата

Сертификат может быть отозван до истечения срока его действия, что означает, что он больше не действителен. Без отзыва злоумышленник сможет использовать такой скомпрометированный или неправильно выданный сертификат до истечения срока его действия. [31] Следовательно, отзыв является важной частью инфраструктуры открытых ключей . [32] Отзыв выполняется выдающим центром сертификации, который формирует криптографически заверенное заявление об отзыве. [33]

При распространении информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, возможность злоумышленнику использовать скомпрометированный сертификат) снижает использование ресурсов при запросе статусов отзыва и проблемы конфиденциальности. [34] Если информация об отзыве недоступна (из-за аварии или атаки), клиенты должны решить, следует ли использовать отказоустойчивый сертификат и рассматривать сертификат как отозванный (и, таким образом, ухудшать доступность ) или отказоустойчивый и рассматривать его как неотозванным (и позволяет злоумышленникам обойти отзыв). [35]

Из-за стоимости проверок отзыва и влияния на доступность потенциально ненадежных удаленных служб веб-браузеры ограничивают выполняемые ими проверки отзыва и работают без сбоев там, где они это делают. [36] Списки отзыва сертификатов слишком затратны для повседневного использования, а протокол статуса онлайн-сертификатов создает проблемы с задержкой соединения и конфиденциальностью. Были предложены и другие схемы, позволяющие обеспечить отказоустойчивую проверку, но они еще не были успешно реализованы. [32]

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

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

Форум CA/Browser публикует «Базовые требования» — [42] список политик и технических требований, которым должны следовать центры сертификации. Это требование для включения в хранилища сертификатов Firefox [43] и Safari. [44]

Компромисс CA

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

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

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

В 2008 году реселлер Comodo Certstar продал сертификат mozilla.com Эдди Ниггу, который не имел полномочий представлять Mozilla. [47]

В 2011 году поддельные сертификаты были получены от Comodo и DigiNotar , [48] [49] предположительно иранскими хакерами. Есть доказательства того, что поддельные сертификаты DigiNotar были использованы при атаке «человек посередине» в Иране. [50]

В 2012 году стало известно, что Trustwave выпустила подчиненный корневой сертификат, который использовался для прозрачного управления трафиком (человек посередине), что фактически позволяло предприятию перехватывать внутренний сетевой трафик SSL с использованием подчиненного сертификата. [51]

В 2012 году вредоносная программа Flame (также известная как SkyWiper) содержала модули, у которых была коллизия MD5 с действительным сертификатом, выданным лицензионным сертификатом Microsoft Terminal Server, который использовал сломанный алгоритм хеширования MD5. Таким образом, авторы смогли провести коллизионную атаку с хешем, указанным в сертификате. [52] [53]

В 2015 году китайский центр сертификации MCS Holdings, связанный с центральным реестром доменов Китая, выдал несанкционированные сертификаты для доменов Google. [54] [55] Таким образом, Google удалила MCS и корневой центр сертификации из Chrome и отозвала сертификаты. [56]

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

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

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

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

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

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

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

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

  1. ^ Чиен, Хун-Ю (19 августа 2021 г.). «Сертификаты динамического открытого ключа с прямой секретностью». Электроника . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN  2079-9292.
  2. ^ «Что такое центр сертификации (CA)?».
  3. ^ Вильянуэва, Джон Карл. «Как работают цифровые сертификаты — обзор». www.jscape.com . Проверено 05 сентября 2021 г.
  4. ^ «Список сертификатов ЦС, включенных в Mozilla — Mozilla» . Мозилла.орг. Архивировано из оригинала 4 августа 2013 г. Проверено 11 июня 2014 г.
  5. ^ "ЭМВ Калифорния". Центр сертификации EMV по всему миру. 2 октября 2010 г. Проверено 17 февраля 2019 г.
  6. ^ Закир Дурумерик; Джеймс Кастен; Майкл Бэйли; Дж. Алекс Халдерман (12 сентября 2013 г.). «Анализ экосистемы сертификатов HTTPS» (PDF) . Конференция по Интернет-измерениям . СИГКОММ . Архивировано (PDF) из оригинала 22 декабря 2013 года . Проверено 20 декабря 2013 г.
  7. ^ «Что такое сертификат SSL?». Архивировано из оригинала 03.11.2015 . Проверено 19 марта 2022 г.
  8. ^ "Веб-траст". вебтраст. Архивировано из оригинала 18 августа 2013 г. Проверено 2 марта 2013 г.
  9. ^ Кирк Холл (апрель 2013 г.). «Стандарты и отраслевые правила, применимые к органам сертификации» (PDF) . Тренд Микро. Архивировано (PDF) из оригинала 4 марта 2016 г. Проверено 11 июня 2014 г.
  10. ^ "CA:IncludedCAs - MozillaWiki" . Wiki.mozilla.org . Архивировано из оригинала 25 марта 2017 г. Проверено 18 марта 2017 г.
  11. ^ «Список доступных доверенных корневых сертификатов в macOS High Sierra» . Поддержка Apple . Проверено 24 августа 2020 г.
  12. ^ «Список сертификатов включенных центров сертификации Microsoft» . ccadb-public.secure.force.com . Проверено 24 августа 2020 г.
  13. ^ «Безопасность с помощью HTTPS и SSL». Developer.android.com . Архивировано из оригинала 8 июля 2017 г. Проверено 9 июня 2017 г.
  14. ^ «Давайте зашифруем: доставка SSL/TLS повсюду» (пресс-релиз). Давайте зашифруем. Архивировано из оригинала 18 ноября 2014 г. Проверено 20 ноября 2014 г.
  15. ^ «О» . Давайте зашифруем. Архивировано из оригинала 10 июня 2015 г. Проверено 7 июня 2015 г.
  16. ^ «Подсчет SSL-сертификатов - Netcraft» . news.netcraft.com . 13 мая 2015 г. Архивировано из оригинала 16 мая 2015 г.
  17. ^ «DigiCert - крупнейший в мире центр сертификации высокой надежности | Netcraft» . Trends.netcraft.com .
  18. ^ «Статистика использования центров сертификации SSL для веб-сайтов, апрель 2023 г. - W3Techs» . w3techs.com .
  19. ^ «Архивная копия» (PDF) . Архивировано (PDF) из оригинала 23 марта 2015 г. Проверено 20 марта 2015 г.{{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )
  20. ^ «CA/Запрещенные или проблемные действия — MozillaWiki». Wiki.mozilla.org . Архивировано из оригинала 21 июля 2017 г. Проверено 6 июля 2017 г.
  21. ^ «Часто задаваемые вопросы по SSL — Часто задаваемые вопросы — Rapid SSL» . www.rapidssl.com . Архивировано из оригинала 06 февраля 2015 г.
  22. ^ Зусман, Майк (2009). Уголовные обвинения не возбуждены: Взлом PKI (PDF) . DEF CON 17. Лас-Вегас. Архивировано (PDF) из оригинала 15 апреля 2013 г.
  23. ^ «Финн создал эту простую учетную запись электронной почты и получил сертификат безопасности Microsoft» . тиви.фи.​ Архивировано из оригинала 8 августа 2015 г.
  24. ^ «Обязанности центра сертификации» . Архивировано из оригинала 12 февраля 2015 г. Проверено 12 февраля 2015 г.
  25. ^ «Сетевой мир». 17 января 2000 г.
  26. ^ Прикладная криптография и сетевая безопасность: Вторая международная конференция, ACNS 2004, Желтая гора, Китай, 8–11 июня 2004 г. Материалы. Спрингер. Июнь 2004 г. ISBN. 9783540222170.
  27. ^ Краткое руководство по управлению жизненным циклом сертификатов. Realtimepublishers.com. 2006. ISBN 9781931491594.
  28. ^ «Электронные подписи и записи» (PDF) . Архивировано (PDF) из оригинала 4 марта 2016 г. Проверено 28 августа 2014 г.
  29. ^ «Прозрачность сертификата» . Архивировано из оригинала 1 ноября 2013 г. Проверено 3 ноября 2013 г.
  30. ^ Лори, Бен; Лэнгли, Адам; Каспер, Эмилия (июнь 2013 г.). «Прозрачность сертификата». Рабочая группа по интернет-инжинирингу . doi : 10.17487/RFC6962. Архивировано из оригинала 22 ноября 2013 г. Проверено 3 ноября 2013 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  31. ^ Смит, Дикинсон и Симонс 2020, стр. 1.
  32. ^ Аб Шеффер, Сен-Андре и Фоссати, 2022, 7.5. Отзыв сертификата.
  33. ^ Чунг и др. 2018, с. 3.
  34. ^ Смит, Дикинсон и Симонс 2020, стр. 10.
  35. ^ Лариш и др. 2017, с. 542.
  36. ^ Смит, Дикинсон и Симонс 2020, стр. 1-2.
  37. ^ «Создан мультивендорный силовой совет для решения проблем с цифровыми сертификатами» . Сетевой мир . 14 февраля 2013 г. Архивировано из оригинала 28 июля 2013 г.
  38. ^ «Основные центры сертификации объединяются во имя безопасности SSL» . Мрачное чтение . 14 февраля 2013 г. Архивировано из оригинала 10 апреля 2013 г.
  39. ^ «Основатель CA/браузерного форума» . Архивировано из оригинала 23 августа 2014 г. Проверено 23 августа 2014 г.
  40. ^ "Форум CA/браузера" . Архивировано из оригинала 12 мая 2013 г. Проверено 23 апреля 2013 г.
  41. ^ Уилсон, Уилсон. «История форума CA/браузера» (PDF) . ДигиСерт. Архивировано (PDF) из оригинала 12 мая 2013 г. Проверено 23 апреля 2013 г.
  42. ^ «Базовые требования». КАБ Форум. Архивировано из оригинала 7 января 2014 года . Проверено 14 апреля 2017 г.
  43. ^ «Политика корневого магазина Mozilla» . Мозилла. Архивировано из оригинала 15 апреля 2017 года . Проверено 14 апреля 2017 г.
  44. ^ «Программа корневых сертификатов Apple» . Яблоко. Архивировано из оригинала 20 марта 2017 года . Проверено 14 апреля 2017 г.
  45. ^ "CA-2001-04". Cert.org. 31 декабря 2001 г. Архивировано из оригинала 2 ноября 2013 г. Проверено 11 июня 2014 г.
  46. ^ Microsoft, Inc. (21 февраля 2007 г.). «Бюллетень по безопасности Microsoft MS01-017: Ошибочные цифровые сертификаты, выданные VeriSign, представляют опасность подделки» . Архивировано из оригинала 26 октября 2011 г. Проверено 9 ноября 2011 г.
  47. ^ Зельцер, Ларри. «Продавец SSL-сертификата продает CSSL-сертификат Mozilla.com какому-то парню» . электронная неделя . Проверено 5 декабря 2021 г.
  48. ↑ Брайт, Питер (28 марта 2011 г.). «Независимый иранский хакер взял на себя ответственность за взлом Comodo». Арс Техника. Архивировано из оригинала 29 августа 2011 года . Проверено 1 сентября 2011 г.
  49. ^ Брайт, Питер (30 августа 2011 г.). «Еще один поддельный сертификат поднимает те же старые вопросы о центрах сертификации». Арс Техника. Архивировано из оригинала 12 сентября 2011 г. Проверено 1 сентября 2011 г.
  50. ^ Лейден, Джон (6 сентября 2011 г.). «Внутри операции «Черный тюльпан»: анализ взлома DigiNotar». Регистр . Архивировано из оригинала 3 июля 2017 г.
  51. ^ «Trustwave выдала сертификат посредника» . Служба безопасности H. 07.02.2012. Архивировано из оригинала 13 марта 2012 г. Проверено 14 марта 2012 г.
  52. ^ «Описание атаки на столкновение вредоносных программ Flame | Блог MSRC | Центр реагирования на безопасность Microsoft» . msrc.microsoft.com . Проверено 13 октября 2023 г.
  53. ^ Гудин, Дэн (7 июня 2012 г.). «Криптовалютный прорыв показывает, что Flame был разработан учеными мирового уровня». Арс Техника . Проверено 13 октября 2023 г.
  54. ^ Фишер, Деннис (23 марта 2015 г.). «ЦС, связанный с китайским регистратором, выдал несанкционированные сертификаты Google». ThreatPost . Проверено 27 сентября 2023 г.
  55. ^ Лэнгли, Адам (23 марта 2015 г.). «Обеспечение безопасности цифровых сертификатов». Блог Google по безопасности . Проверено 27 сентября 2023 г.
  56. ^ Ловенталь, Том (31 марта 2015 г.). «Китайская CNNIC выдает фальшивые сертификаты, что является серьезным нарушением доверия к криптовалютам». Комитет по защите журналистов . Проверено 13 октября 2023 г.
  57. ^ Осборн, Чарли. «Symantec увольняет сотрудников за выдачу несанкционированных сертификатов Google – ZDNet». zdnet.com . Архивировано из оригинала 2 октября 2016 г.
  58. ^ «Обнаружены несанкционированные цифровые сертификаты Google» . linkedin.com . 12 августа 2014 г.
  59. ^ «После несанкционированной выдачи сертификатов индийским центром сертификации, могут ли государственные центры сертификации по-прежнему считаться «доверенными третьими сторонами»?». casecurity.org . 24 июля 2014 г. Архивировано из оригинала 3 октября 2016 г.

Цитируемые работы

Внешние ссылки