stringtranslate.com

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

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

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

Обзор

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

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

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

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

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

Браузеры и другие виды клиентов характерно позволяют пользователям добавлять или удалять сертификаты 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) отвечают за три четверти всех выпущенных сертификатов [TLS] на общедоступных веб-серверах. Первое место удерживает Symantec (или VeriSign до того, как он был куплен Symantec) с самого начала [нашего] опроса, и в настоящее время на него приходится чуть менее трети всех сертификатов. Чтобы проиллюстрировать влияние различных методологий, среди миллиона самых загруженных сайтов Symantec выдала 44% действительных, доверенных используемых сертификатов — значительно больше, чем ее общая доля на рынке». [16]

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

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

Стандарты проверки

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

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

Недостатки проверки

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

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

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

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

Выдача сертификата

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

  1. ^ Чиен, Хун-Ю (19 августа 2021 г.). «Динамические сертификаты открытых ключей с прямой секретностью». Электроника . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN  2079-9292.
  2. ^ «Что такое центр сертификации (ЦС)?».
  3. ^ Вильянуэва, Джон Карл. «Как работают цифровые сертификаты — обзор». www.jscape.com . Получено 05.09.2021 .
  4. ^ "Mozilla Included CA Certificate List — Mozilla". Mozilla.org. Архивировано из оригинала 2013-08-04 . Получено 2014-06-11 .
  5. ^ "EMV CA". EMV Certificate Authority Worldwide. 2 октября 2010 г. Получено 17 февраля 2019 г.
  6. ^ Закир Дурумерик; Джеймс Кастен; Майкл Бейли; Дж. Алекс Халдерман (12 сентября 2013 г.). "Анализ экосистемы сертификатов HTTPS" (PDF) . Конференция по измерению Интернета . SIGCOMM . Архивировано (PDF) из оригинала 22 декабря 2013 г. . Получено 20 декабря 2013 г. .
  7. ^ "Что такое SSL-сертификат?". Архивировано из оригинала 2015-11-03 . Получено 2022-03-19 .
  8. ^ "webtrust". webtrust. Архивировано из оригинала 2013-08-18 . Получено 2013-03-02 .
  9. ^ Кирк Холл (апрель 2013 г.). «Стандарты и отраслевые правила, применимые к органам сертификации» (PDF) . Trend Micro. Архивировано (PDF) из оригинала 2016-03-04 . Получено 2014-06-11 .
  10. ^ "CA:IncludedCAs - MozillaWiki". wiki.mozilla.org . Архивировано из оригинала 2017-03-25 . Получено 2017-03-18 .
  11. ^ "Список доступных доверенных корневых сертификатов в macOS High Sierra". Поддержка Apple . Получено 24.08.2020 .
  12. ^ "Список сертификатов ЦС, включенных Microsoft". ccadb-public.secure.force.com . Получено 24.08.2020 .
  13. ^ "Безопасность с HTTPS и SSL". developer.android.com . Архивировано из оригинала 2017-07-08 . Получено 2017-06-09 .
  14. ^ "Let's Encrypt: Delivering SSL/TLS Everywhere" (пресс-релиз). Let's Encrypt. Архивировано из оригинала 2014-11-18 . Получено 2014-11-20 .
  15. ^ "About". Let's Encrypt. Архивировано из оригинала 2015-06-10 . Получено 2015-06-07 .
  16. ^ "Подсчет сертификатов SSL - Netcraft". news.netcraft.com . 13 мая 2015 г. Архивировано из оригинала 2015-05-16.
  17. ^ "DigiCert — крупнейший в мире центр сертификации с высокой степенью надежности | Netcraft". trends.netcraft.com .
  18. ^ «Статистика использования центров сертификации SSL для веб-сайтов, август 2024 г. — W3Techs». w3techs.com .
  19. ^ "Базовые требования к выпуску и управлению публично-доверенными сертификатами, v.1.2.3" (PDF) . Архивировано (PDF) из оригинала 2015-03-23 ​​. Получено 2015-03-20 .
  20. ^ "CA/Запрещенные или проблемные практики - MozillaWiki". wiki.mozilla.org . Архивировано из оригинала 2017-07-21 . Получено 2017-07-06 .
  21. ^ "SSL FAQ - Часто задаваемые вопросы - Rapid SSL". www.rapidssl.com . Архивировано из оригинала 2015-02-06.
  22. ^ Зусман, Майк (2009). Уголовные обвинения не выдвигаются: Взлом PKI (PDF) . DEF CON 17. Лас-Вегас. Архивировано (PDF) из оригинала 2013-04-15.
  23. ^ "Финн создал эту простую учетную запись электронной почты и получил сертификат безопасности Microsoft". tivi.fi . Архивировано из оригинала 2015-08-08.
  24. ^ "Обязанности центра сертификации". Архивировано из оригинала 2015-02-12 . Получено 2015-02-12 .
  25. ^ "Network World". 17 января 2000 г.
  26. ^ Прикладная криптография и сетевая безопасность: Вторая международная конференция, ACNS 2004, Желтая гора, Китай, 8-11 июня 2004 г. Труды. Springer. Июнь 2004 г. ISBN 9783540222170.
  27. ^ Краткое руководство по управлению жизненными циклами сертификатов. Realtimepublishers.com. 2006. ISBN 9781931491594.
  28. ^ "Электронные подписи и записи" (PDF) . Архивировано (PDF) из оригинала 2016-03-04 . Получено 2014-08-28 .
  29. ^ "Прозрачность сертификата". Архивировано из оригинала 2013-11-01 . Получено 2013-11-03 .
  30. ^ Лори, Бен; Лэнгли, Адам; Каспер, Эмилия (июнь 2013 г.). Прозрачность сертификатов. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6962 . ISSN  2070-1721. RFC 6962. Экспериментальный. |- |6963 |Лучшая текущая практика | P. Saint-Andre (май 2013 г.). Пространство имен унифицированных имен ресурсов (URN) для примеров. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6963 . ISSN  2070-1721. RFC 6963.|Обновления RFC 1930. |- |6979 |Информационные | T. Pornin (август 2013 г.). Детерминированное использование алгоритма цифровой подписи (DSA) и алгоритма цифровой подписи на эллиптических кривых (ECDSA). Независимая подача. doi : 10.17487/RFC6979 . ISSN  2070-1721. RFC 6979.| |- |6980 |Предлагаемый стандарт | Ф. Гонт (август 2013 г.). Последствия фрагментации IPv6 для безопасности с обнаружением соседей IPv6. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6980 . ISSN  2070-1721. RFC 6980.|Обновления RFC 3971 и 4861. |- |6996 |Лучшая текущая практика | Дж. Митчелл (июль 2013 г.). Резервирование автономных систем (AS) для частного использования. Internet Engineering Task Force (IETF). doi : 10.17487/RFC6996 . ISSN  2070-1721. BCP 6. RFC 6996.|Обновляет RFC 1930. |}
  31. ^ Смит, Дикинсон и Симонс 2020, стр. 1.
  32. ^ ab Sheffer, Saint-Andre & Fossati 2022, 7.5. Отзыв сертификата.
  33. ^ Чунг и др. 2018, стр. 3.
  34. ^ Смит, Дикинсон и Симонс 2020, стр. 10.
  35. ^ Лариш и др. 2017, с. 542.
  36. ^ Смит, Дикинсон и Симонс 2020, стр. 1-2.
  37. ^ "Сформирован многоотраслевой совет по вопросам цифровых сертификатов". Network World . 14 февраля 2013 г. Архивировано из оригинала 28 июля 2013 г.
  38. ^ "Основные центры сертификации объединяются во имя безопасности SSL". Dark Reading . 14 февраля 2013 г. Архивировано из оригинала 10 апреля 2013 г.
  39. ^ "CA/Browser Forum Founder". Архивировано из оригинала 2014-08-23 . Получено 2014-08-23 .
  40. ^ "CA/Browser Forum". Архивировано из оригинала 2013-05-12 . Получено 2013-04-23 .
  41. ^ Уилсон, Уилсон. "История форума CA/Browser" (PDF) . DigiCert. Архивировано (PDF) из оригинала 2013-05-12 . Получено 2013-04-23 .
  42. ^ "Baseline Requirements". Форум CAB. 4 сентября 2013 г. Архивировано из оригинала 7 января 2014 г. Получено 14 апреля 2017 г.
  43. ^ "Mozilla Root Store Policy". Mozilla. Архивировано из оригинала 15 апреля 2017 г. Получено 14 апреля 2017 г.
  44. ^ "Apple Root Certificate Program". Apple. Архивировано из оригинала 20 марта 2017 года . Получено 14 апреля 2017 года .
  45. ^ "CA-2001-04". Cert.org. 31 декабря 2001 г. Архивировано из оригинала 2013-11-02 . Получено 2014-06-11 .
  46. ^ Microsoft, Inc. (21.02.2007). "Бюллетень безопасности Microsoft MS01-017: Ошибочные цифровые сертификаты VeriSign представляют опасность подделки". Архивировано из оригинала 26.10.2011 . Получено 09.11.2011 .
  47. ^ Сельцер, Ларри. «Продавец сертификата SSL продает сертификат CSSL Mozilla.com какому-то парню». eWeek . Получено 5 декабря 2021 г.
  48. ↑ Bright, Peter (28 марта 2011 г.). «Независимый иранский хакер берет на себя ответственность за взлом Comodo». Ars Technica. Архивировано из оригинала 29 августа 2011 г. Получено 01.09.2011 .
  49. ^ Брайт, Питер (2011-08-30). «Еще один мошеннический сертификат поднимает те же старые вопросы о центрах сертификации». Ars Technica. Архивировано из оригинала 2011-09-12 . Получено 2011-09-01 .
  50. ^ Лейден, Джон (06.09.2011). «Внутри операции «Черный тюльпан»: анализ взлома DigiNotar». The Register . Архивировано из оригинала 03.07.2017.
  51. ^ "Trustwave выпустил сертификат man-in-the-middle". The H Security . 2012-02-07. Архивировано из оригинала 2012-03-13 . Получено 2012-03-14 .
  52. ^ "Объяснение атаки столкновений вредоносного ПО Flame | Блог MSRC | Центр реагирования на безопасность Microsoft". msrc.microsoft.com . Получено 13 октября 2023 г.
  53. ^ Гудин, Дэн (2012-06-07). «Прорыв в области криптографии показывает, что Flame был разработан учеными мирового класса». Ars Technica . Получено 2023-10-13 .
  54. ^ Фишер, Деннис (2015-03-23). ​​«CA, связанный с китайским регистратором, выдал несанкционированные сертификаты Google». ThreatPost . Получено 2023-09-27 .
  55. ^ Лэнгли, Адам (23.03.2015). «Поддержание безопасности цифровых сертификатов». Блог безопасности Google . Получено 27.09.2023 .
  56. ^ Ловенталь, Том (2015-03-31). «CNNIC Китая выпускает поддельные сертификаты, серьезно нарушая доверие к криптовалютам». Комитет по защите журналистов . Получено 2023-10-13 .
  57. ^ Осборн, Чарли. "Symantec увольняет сотрудников за выдачу несанкционированных сертификатов Google - ZDNet". ZDNet . Архивировано из оригинала 2016-10-02.
  58. ^ «Обнаружены несанкционированные цифровые сертификаты Google». linkedin.com . 12 августа 2014 г.
  59. ^ «В связи с несанкционированной выдачей сертификатов индийским CA NIC могут ли государственные CA по-прежнему считаться «доверенными третьими сторонами»?». casecurity.org . 24 июля 2014 г. Архивировано из оригинала 3 октября 2016 г.

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

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