Стандарт X.509: Формат сертификатов открытых ключей

Введение

Стандарт, определяющий формат сертификатов открытого ключа. В криптографии X.509 — это стандарт Международного союза электросвязи (ITU), определяющий формат сертификатов открытого ключа. Сертификаты X.509 используются во многих интернет-протоколах, включая TLS/SSL, который лежит в основе HTTPS.

Сертификат X.509 связывает идентификатор с открытым ключом посредством цифровой подписи. Сертификат содержит идентификатор (имя хоста, организацию или отдельного лица) и открытый ключ (RSA, DSA, ECDSA, ed25519 и т.д.) и подписывается центром сертификации или самоподписан. Если сертификат подписан доверенным центром сертификации или проверен иным способом, то владелец этого сертификата может использовать содержащийся в нем открытый ключ для установления защищенной связи с другой стороной или для проверки цифровой подписи документов соответствующим закрытым ключом. X.509 также определяет списки отзыва сертификатов, которые служат для распространения информации о сертификатах, признанных недействительными центром сертификации, а также алгоритм проверки цепочки сертификатов, позволяющий подписывать сертификаты промежуточными сертификатами ЦС, которые, в свою очередь, подписываются другими сертификатами, в конечном итоге достигая доверенной точки. X.509 определяется "Сектором стандартизации" ITU (СГ17 ITU T) в Исследовательской группе 17 ITU T и основан на Abstract Syntax Notation One (ASN.1) — другом стандарте ITU T.

История и использование

X.509 был впервые выпущен 3 июля 1988 года и разрабатывался в связи со стандартом X.500. Первоначальными задачами были обеспечение пользователям безопасного доступа к информационным ресурсам и предотвращение атак типа «человек посередине». Он предполагает строгую иерархическую систему центров сертификации (CA) для выдачи сертификатов. Это отличается от моделей «сети доверия», таких как PGP, где любой (а не только специальные CA) может подписывать сертификаты и тем самым подтверждать действительность ключей других. Версия 3 X.509 обеспечивает гибкость для поддержки других топологий, таких как мосты и сети. Его можно использовать в одноранговых сетях, в «сети доверия», подобной OpenPGP, но по состоянию на 2004 год это делалось редко. Система X.500 была реализована только суверенными государствами для выполнения соглашений о совместном использовании информации о государственной идентификации, а рабочая группа IETF по инфраструктуре открытых ключей (X.509) (PKIX) адаптировала стандарт к более гибкой организации Интернета. Фактически, термин «сертификат X.509» обычно относится к профилю сертификатов и списков отзыва сертификатов (CRL) PKIX IETF для стандарта сертификатов X.509 v3, как указано в [ссылка], обычно называемому PKIX для инфраструктуры открытых ключей (X.509). Ранней проблемой для инфраструктуры открытых ключей (PKI) и сертификатов X.509 была хорошо известная проблема «какого каталога». Проблема заключалась в том, что клиент не знал, где получить недостающие промежуточные сертификаты, поскольку глобальный каталог X.500 так и не был создан. Проблема была смягчена путем включения всех промежуточных сертификатов в запрос. Например, ранние веб-серверы отправляли клиенту только сертификат веб-сервера. Клиенты, у которых не было промежуточного сертификата CA или информации о его местонахождении, не могли построить допустимый путь от CA к сертификату сервера. Чтобы обойти эту проблему, веб-серверы теперь отправляют все промежуточные сертификаты вместе с сертификатом веб-сервера. Хотя PKIX относится к стандарту PKI IETF или Интернета, существует множество других PKI с различными политиками. Например, правительство США имеет свою собственную PKI со своими политиками, а CA/Browser Forum имеет свою собственную PKI со своими политиками. Документация PKI правительства США представляет собой объемный документ, состоящий более чем из 2500 страниц. Если PKI организации слишком сильно отличается от PKI IETF или CA/Browser Forum, организация рискует потерять совместимость с распространенными инструментами, такими как веб-браузеры, cURL и Wget. Например, если PKI имеет политику выдачи сертификатов только по понедельникам, то распространенные инструменты, такие как cURL и Wget, не будут применять эту политику и разрешат выдачу сертификата во вторник. Тип = публичный. Сертификат x509

X.509 was initially issued on July 3, 1988, and was begun in association with the X.500 standard. The first tasks of it was providing users with secure access to information resources and avoiding a cryptographic man in the middle attack. It assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. This contrasts with web of trust models, like PGP, where anyone (not just special CAs) may sign and thus attest to the validity of others' key certificates. Version 3 of X.509 includes the flexibility to support other topologies like bridges and meshes. It can be used in a peer to peer, OpenPGP like web of trust, but was rarely used that way as of 2004. The X.500 system has only been implemented by sovereign nations for state identity information sharing treaty fulfillment purposes, and the IETF's Public Key Infrastructure (X.509) (PKIX) working group has adapted the standard to the more flexible organization of the Internet. In fact, the term X.509 certificate usually refers to the IETF's PKIX certificate and CRL profile of the X.509 v3 certificate standard, as specified in , commonly called PKIX for Public Key Infrastructure (X.509). An early issue with Public Key Infrastructure (PKI) and X.509 certificates was the well known "which directory" problem. The problem is the client does not know where to fetch missing intermediate certificates because the global X.500 directory never materialized. The problem was mitigated by including all intermediate certificates in a request. For example, early web servers only sent the web server's certificate to the client. Clients that lacked an intermediate CA certificate or where to find them failed to build a valid path from the CA to the server's certificate. To work around the problem, web servers now send all the intermediate certificates along with the web server's certificate. While PKIX refers to the IETF's or Internet's PKI standard, there are many other PKIs with different policies. For example, the US Government has its own PKI with its own policies, and the CA/Browser Forum has its own PKI with its own policies. The US Government's PKI is a massive book of over 2500 pages. If an organization's PKI diverges too much from that of the IETF or CA/Browser Forum, then the organization risks losing interoperability with common tools like web browsers, cURL, and Wget. For example, if a PKI has a policy of only issuing certificates on Monday, then common tools like cURL and Wget will not enforce the policy and allow a certificate issued on a Tuesday. |uniform type = public. x509 certificate

Сертификаты X.509 связывают идентификатор с открытым ключом, используя цифровую подпись. В системе X.509 существует два типа сертификатов. Первый — это сертификат CA. Второй — это сертификат конечного субъекта. Сертификат CA может выдавать другие сертификаты. Сертификат CA верхнего уровня, подписанный самостоятельно, иногда называют корневым сертификатом CA. Другие сертификаты CA называются промежуточными или подчиненными сертификатами CA. Сертификат конечного субъекта идентифицирует пользователя, например, человека, организацию или предприятие. Сертификат конечного субъекта не может выдавать другие сертификаты. Сертификат конечного субъекта иногда называют листовым сертификатом, поскольку ниже него нельзя выдать другие сертификаты. Организация, желающая получить подписанный сертификат, запрашивает его у CA, используя протокол, такой как запрос на подпись сертификата (CSR), протокол простого зачисления сертификатов (SCEP) или протокол управления сертификатами (CMP). Организация сначала генерирует пару ключей, сохраняя секретность закрытого ключа и используя его для подписи CSR. CSR содержит информацию, идентифицирующую заявителя, и открытый ключ заявителя, который используется для проверки подписи CSR, а также уникальное для лица, организации или предприятия различающееся имя (DN). К CSR могут прилагаться другие учетные данные или доказательства личности, требуемые центром сертификации. CSR будет проверен с помощью регистрационного органа (RA), после чего центр сертификации выдаст сертификат, связывающий открытый ключ с конкретным различающимся именем. Функции регистрационного органа и центра сертификации обычно разделены на отдельные подразделения в рамках разделения обязанностей для снижения риска мошенничества. Доверенные корневые сертификаты организации могут быть распространены среди всех сотрудников, чтобы они могли использовать корпоративную систему PKI. Браузеры, такие как Internet Explorer, Firefox, Opera, Safari и Chrome, поставляются с предварительно установленным набором корневых сертификатов, поэтому SSL-сертификаты от крупных центров сертификации будут работать мгновенно; фактически, разработчики браузеров определяют, каким CA доверяют пользователи браузеров. Например, Firefox предоставляет CSV- и/или HTML-файл, содержащий список включенных CA. X.509 также включает стандарты для реализации списков отзыва сертификатов (CRL). Другим способом проверки действительности сертификата, одобренным IETF, является протокол онлайн-статуса сертификата (OCSP). Firefox 3.0 включил проверку OCSP по умолчанию, как и версии Windows, начиная с Vista и более поздних.

X.509 certificates bind an identity to a public key using a digital signature. In the X.509 system, there are two types of certificates. The first is a CA certificate. The second is an end entity certificate. A CA certificate can issue other certificates. The top level, self signed CA certificate is sometimes called the Root CA certificate. Other CA certificates are called intermediate CA or subordinate CA certificates. An end entity certificate identifies the user, like a person, organization or business. An end entity certificate cannot issue other certificates. An end entity certificate is sometimes called a leaf certificate since no other certificates can be issued below it. An organization that wants a signed certificate requests one from a CA using a protocol like Certificate Signing Request (CSR), Simple Certificate Enrollment Protocol (SCEP) or Certificate Management Protocol (CMP). The organization first generates a key pair, keeping the private key secret and using it to sign the CSR. The CSR contains information identifying the applicant and the applicant's public key that is used to verify the signature of the CSR and the Distinguished Name (DN) that is unique for the person, organization or business. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority. The CSR will be validated using a Registration Authority (RA), and then the certification authority will issue a certificate binding a public key to a particular distinguished name. The roles registration authority and certification authority are usually separate business units under separation of duties to reduce the risk of fraud. An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system. Browsers such as Internet Explorer, Firefox, Opera, Safari and Chrome come with a predetermined set of root certificates pre installed, so SSL certificates from major certificate authorities will work instantly; in effect the browsers' developers determine which CAs are trusted third parties for the browsers' users. For example, Firefox provides a CSV and/or HTML file containing a list of Included CAs. X.509 and also include standards for certificate revocation list (CRL) implementations. Another IETF approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Firefox 3.0 enabled OCSP checking by default, as did versions of Windows from at least Vista and later.

Расширения, информирующие о конкретном использовании сертификата

(и его предшественников) определяет ряд расширений сертификатов, которые указывают, как сертификат должен использоваться. Большинство из них являются ветвями от общего OID ISO ccitt(2) ds(5) id ce(29). Некоторые из наиболее распространенных, определенных в разделе 4.2.1, включают:

Основные ограничения, { id ce 19 }, используются для указания того, является ли сертификат сертификатом центра сертификации (ЦС) и может ли он сертифицировать или выдавать другие сертификаты. Ограничение может быть помечено как критическое. Если ограничение помечено как критическое, агент должен прекратить обработку сертификата, если он не понимает это ограничение. Агент может продолжить обработку некритического ограничения, которое он не понимает. Key Usage, { id ce 15 }, предоставляет битовую карту, определяющую криптографические операции, которые могут быть выполнены с использованием открытого ключа, содержащегося в сертификате; например, он может указывать, что ключ должен использоваться для подписей, но не для шифрования. Расширенное использование ключа, { id ce 37 }, обычно используется в конечном сертификате для указания цели открытого ключа, содержащегося в сертификате. Он содержит список OID, каждый из которых указывает на допустимое использование. Например, { id pkix 3 1 } указывает, что ключ может использоваться на серверной стороне соединения TLS или SSL; { id pkix 3 4 } указывает, что ключ может использоваться для защиты электронной почты. В общем случае, при использовании RFC 5280, если сертификат имеет несколько расширений, ограничивающих его использование, все ограничения должны быть выполнены, чтобы данное использование было допустимым. В RFC приводится конкретный пример сертификата, содержащего как keyUsage, так и extendedKeyUsage: в этом случае оба должны быть обработаны, и сертификат может быть использован только в том случае, если оба расширения согласованы в определении использования сертификата. Например, NSS использует оба расширения для определения использования сертификата.

Сертификаты расширенной проверки

Органы сертификации, действующие в рамках PKI CA/Browser Forum, выдают сертификаты с различными уровнями проверки. Различные валидации обеспечивают разные уровни гарантий того, что сертификат представляет то, что он должен представлять. Например, веб-сервер может быть проверен на самом низком уровне гарантий с помощью электронной почты, называемой Domain Validation (DV). Или веб-сервер может быть проверен на более высоком уровне гарантий с использованием более подробных методов, называемых Extended Validation (EV). На практике сертификат DV означает, что сертификат был выдан для домена, например, example.com, после того как кто-то ответил на электронное письмо, отправленное на webmaster@example.com. Сертификат EV означает, что сертификат был выдан для домена, например, example.com, и компания, такая как Example, LLC, является владельцем домена, а владелец был проверен Уставом. Расширенная валидация не добавляет никаких дополнительных средств контроля безопасности, поэтому настройка защищенного канала с использованием сертификата EV не "сильнее", чем настройка канала с использованием другого уровня валидации, например DV. Расширенная валидация обозначается в сертификате с помощью расширения X.509 v3. Каждый центр сертификации использует другой идентификатор объекта (OID) для подтверждения расширенной проверки. Не существует единого OID для обозначения расширенной валидации, что усложняет программирование пользовательских агентов. Каждый пользовательский агент должен иметь список OID, которые указывают на расширенную валидацию. PKI CA/Browser Forum признает расширенную валидацию, и многие браузеры предоставляют визуальную обратную связь пользователю, чтобы указать, что сайт предоставляет сертификат EV. Другие PKI, такие как PKI Интернета (PKIX), не уделяют особого внимания расширенной валидации. Инструменты, использующие политики PKIX, такие как cURL и Wget, просто обрабатывают сертификат EV как любой другой сертификат. Эксперт по безопасности Питер Гутманн утверждает, что центры сертификации создали сертификаты EV, чтобы восстановить уровень прибыли после того, как "гонка к дну" сократила прибыль. Во время гонки к дну центры сертификации снижали цены, чтобы привлечь потребителей к покупке их сертификатов. В результате прибыль снизилась, и центры сертификации снизили уровень проверки, которую они выполняли, до такой степени, что на сертификате почти не было гарантий. p7r – Ответ PKCS#7 на запрос на сертификат (CSR). Содержит недавно подписанный сертификат и собственный сертификат центра сертификации. p7s – PKCS#7 Цифровая подпись. Может содержать оригинальный подписанный файл или сообщение. Используется в S/MIME для подписи электронной почты. Определено в RFC 2311. p7m – PKCS#7 (SignedData, EnvelopedData) Сообщение, например, зашифрованный ("зашифрованный") файл, сообщение или письмо электронной почты MIME. Определено в RFC 2311. p7c – PKCS#7 вырожденная структура SignedData "только сертификаты", без каких-либо данных для подписи. Определено в RFC 2311. p7b, keystore – Структура PKCS#7 SignedData без данных, только пакет сертификатов и/или CRL (редко), но не приватный ключ. Использует форму DER или BER или PEM, начинающуюся с… – формат, используемый Windows для обмена сертификатами. Поддерживается Java, но часто имеет расширение Keystore. В отличие от сертификатов в формате PEM, этот формат имеет определенный способ включения сертификатов цепочки доверия. p12, pfx, pkcs12 – PKCS#12, может содержать сертификаты (публичные) и приватные ключи (защищенные паролем) в одном файле. pfx – Personal Information eXchange PFX, предшественник PKCS#12 (обычно содержит данные в формате PKCS#12, например, файлы PFX, созданные в IIS). crl – Список отзыва сертификатов (CRL). Центры сертификации выпускают их для аннулирования сертификатов до истечения срока действия. PKCS#7 – это стандарт для подписи или шифрования (официально называемого "упаковкой") данных. Поскольку сертификат необходим для проверки подписанных данных, их можно включить в структуру SignedData.

Certification authorities operating under the CA/Browser Forum's PKI issue certificates with varying levels of validation. The different validations provide different levels of assurances that a certificate represents what it is supposed to. For example, a web server can be validated at the lowest level of assurances using an email called Domain Validation (DV). Or a web server can be validated at a higher level of assurances using more detailed methods called Extended Validation (EV). In practice, a DV certificate means a certificate was issued for a domain like example. com after someone responded to an email sent to webmaster@example. com. An EV certificate means a certificate was issued for a domain like example. com, and a company like Example, LLC is the owner of the domain, and the owner was verified by Articles of Incorporation. Extended validation does not add any additional security controls, so the secure channel setup using an EV certificate is not "stronger" than a channel setup using a different level of validation like DV. Extended validation is signaled in a certificate using X.509 v3 extension. Each CA uses a different Object Identifier (OID) to assert extended validation. There is no single OID to indicate extended validation, which complicates user agent programming. Each user agent must have a list of OIDs that indicate extended validation. The CA/Browser Forum's PKI recognizes extended validation and many browsers provide visual feedback to the user to indicate a site provides an EV certificate. Other PKIs, like the Internet's PKI (PKIX), do not place any special emphasis on extended validation. Tools using PKIX policies, like cURL and Wget, simply treat an EV certificate like any other certificate. Security expert Peter Gutmann states CA's created EV certificates to restore profit levels after the Race to the Bottom cut into profits. During the race to the bottom CA's cut prices to lure consumers to purchase their certificates. As a result, profits were reduced and CA's dropped the level of validation they were performing to the point there were nearly no assurances on a certificate. p7r – PKCS#7 response to CSR. Contains the newly signed certificate, and the CA's own cert. p7s PKCS#7 Digital Signature. May contain the original signed file or message. Used in S/MIME for email signing. Defined in RFC 2311.
p7m PKCS#7 (SignedData, EnvelopedData) Message e. g. encrypted ("enveloped") file, message or MIME email letter. Defined in RFC 2311.
p7c PKCS#7 degenerated SignedData "certs only" structure, without any data to sign. Defined in RFC 2311.
p7b, keystore PKCS#7 SignedData structure without data, just certificate(s) bundle and/or CRLs (rarely) but not a private key. Uses DER form or BER or PEM that starts with The format used by Windows for certificate interchange. Supported by Java but often has keystore as an extension instead. Unlike pem style certificates, this format has a defined way to include certification path certificates. p12, pfx, pkcs12 – PKCS#12, may contain certificate(s) (public) and private keys (password protected) in a single file. pfx – Personal Information eXchange PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e. g. with PFX files generated in IIS). crl A Certificate Revocation List (CRL). Certificate Authorities produce these as a way to de authorize certificates before expiration. PKCS#7 is a standard for signing or encrypting (officially called "enveloping") data. Since the certificate is needed to verify signed data, it is possible to include them in the SignedData structure.

Пример 1: перекрестная сертификация на уровне корневого органа по сертификации (CA) между двумя PKI

Для того чтобы PKI 1 доверял существующим в PKI 2 пользовательским сертификатам (например, "User 2"), CA1 генерирует сертификат (cert2.1), содержащий открытый ключ CA2. Теперь и "cert2, и cert2.1 (зеленым цветом) имеют одинаковый субъект и открытый ключ, поэтому для cert2.2 (пользователя 2) существует две допустимые цепочки доверия: "cert2.2 → cert2" и "cert2.2 → cert2.1 → cert1". Аналогично, CA2 может сгенерировать сертификат (cert1.1), содержащий открытый ключ CA1, чтобы пользовательские сертификаты, существующие в PKI 1 (например, "User 1"), доверялись в PKI 2.

Пример 2: продление сертификата CA

Поскольку и cert1, и cert3 содержат один и тот же открытый ключ (старый), для cert5 существует две допустимые цепочки сертификатов: "cert5 → cert1" и "cert5 → cert3 → cert2", и аналогично для cert6. Это позволяет доверять старым пользовательским сертификатам (например, cert5) и новым сертификатам (например, cert6) без различия стороне, использующей в качестве доверенного якоря либо новый корневой сертификат CA, либо старый, в процессе перехода к новым ключам CA.

Образец сертификата X.509

Это пример расшифрованного сертификата X.509, который в прошлом использовался wikipedia.org и несколькими другими веб-сайтами Википедии. Он был выдан GlobalSign, как указано в поле "Issuer". Его поле "Subject" описывает Википедию как организацию, а поле "Subject Alternative Name" (SAN) для DNS описывает имена хостов, для которых он мог быть использован. Поле "Subject Public Key Info" содержит публичный ключ ECDSA, а подпись внизу была сгенерирована частным ключом RSA компании GlobalSign. (Подписи в этих примерах усечены.)

Криптографические недостатки

Системы цифровой подписи зависят от безопасных криптографических хеш-функций для своей работы. Когда инфраструктура открытых ключей допускает использование хеш-функции, которая больше не является безопасной, злоумышленник может использовать уязвимости в этой хеш-функции для подделки сертификатов. В частности, если злоумышленник способен создать коллизию хеша, он может убедить удостоверяющий центр (УЦ) подписать сертификат с безобидным содержимым, хеш которого идентичен хешу другого, вредоносного содержимого сертификата, созданного злоумышленником с выбранными им значениями. Затем злоумышленник может добавить подпись УЦ к вредоносному содержимому сертификата, в результате чего получится вредоносный сертификат, который будет выглядеть как подписанный УЦ. Поскольку содержимое вредоносного сертификата выбирается исключительно злоумышленником, он может содержать другие даты действия или имена хостов, чем безобидный сертификат. Вредоносный сертификат может даже содержать поле "CA: true", позволяющее ему выдавать дополнительные доверенные сертификаты. Сертификаты, основанные на MD2, использовались в течение длительного времени и были уязвимы для атак по поиску прообраза. Поскольку корневой сертификат уже имел самоподпись, злоумышленники могли использовать эту подпись для промежуточного сертификата. В 2005 году Арьен Ленстра и Бенне де Вегер продемонстрировали "способ использования коллизий хеша для создания двух сертификатов X.509, содержащих идентичные подписи и отличающихся только открытыми ключами", что было достигнуто с помощью коллизионной атаки на хеш-функцию MD5. В 2008 году Александр Сотиров и Марк Стивенс представили на Chaos Communication Congress практическую атаку, которая позволила им создать поддельный удостоверяющий центр, принимаемый всеми распространенными браузерами, воспользовавшись тем фактом, что RapidSSL все еще выдавал сертификаты X.509 на основе MD5. В апреле 2009 года на конференции Eurocrypt австралийские исследователи из Университета Маккуори представили работу "Автоматический дифференциальный поиск пути для SHA 1". Исследователи смогли вывести метод, который увеличивает вероятность коллизии на несколько порядков. В феврале 2017 года группа исследователей под руководством Марка Стивенса создала коллизию SHA 1, продемонстрировав слабость SHA 1.

Digital signature systems depend on secure cryptographic hash functions to work. When a public key infrastructure allows the use of a hash function that is no longer secure, an attacker can exploit weaknesses in the hash function to forge certificates. Specifically, if an attacker is able to produce a hash collision, they can convince a CA to sign a certificate with innocuous contents, where the hash of those contents is identical to the hash of another, malicious set of certificate contents, created by the attacker with values of their choosing. The attacker can then append the CA provided signature to their malicious certificate contents, resulting in a malicious certificate that appears to be signed by the CA. Because the malicious certificate contents are chosen solely by the attacker, they can have different validity dates or hostnames than the innocuous certificate. The malicious certificate can even contain a "CA: true" field making it able to issue further trusted certificates. MD2 based certificates were used for a long time and were vulnerable to preimage attacks. Since the root certificate already had a self signature, attackers could use this signature and use it for an intermediate certificate. In 2005, Arjen Lenstra and Benne de Weger demonstrated "how to use hash collisions to construct two X.509 certificates that contain identical signatures and that differ only in the public keys", achieved using a collision attack on the MD5 hash function. In 2008, Alexander Sotirov and Marc Stevens presented at the Chaos Communication Congress a practical attack that allowed them to create a rogue Certificate Authority, accepted by all common browsers, by exploiting the fact that RapidSSL was still issuing X.509 certificates based on MD5. In April 2009 at the Eurocrypt Conference, Australian Researchers of Macquarie University presented "Automatic Differential Path Searching for SHA 1". The researchers were able to deduce a method which increases the likelihood of a collision by several orders of magnitude. In February 2017, a group of researchers led by Marc Stevens produced a SHA 1 collision, demonstrating SHA 1's weakness.

Уменьшение криптографических недостатков

Использование коллизии хеша для подделки подписей X.509 требует, чтобы злоумышленник мог предсказать данные, которые орган сертификации подпишет. Это может быть несколько смягчено, если орган сертификации генерирует случайный компонент в подписываемых сертификатах, обычно серийный номер. Форум CA/Browser требует наличия энтропии серийного номера в разделе 7.1 своих базовых требований с 2011 года.

Начиная с 2016 года, базовые требования запрещают выпуск сертификатов с использованием SHA 1. Начиная с начала 2017 года, Chrome и Firefox отклоняют сертификаты, использующие SHA 1. В 2017 году Edge и Safari также начали отклонять сертификаты SHA 1. Небраузерные валидаторы X.509 пока не отклоняют сертификаты SHA 1.

Рабочая группа ПКИКС

В 1995 году Internet Engineering Task Force совместно с Национальным институтом стандартов и технологий сформировала рабочую группу по инфраструктуре открытых ключей (X.509). Рабочая группа, завершившая свою работу в июне 2014 года, обычно упоминается как "PKIX". Она разработала RFC и другую стандартизирующую документацию по практическому использованию и внедрению X.509. В частности, она создала RFC 5280 и его предшественника, которые определяют способы использования X.509 в интернет-протоколах.

Основные протоколы и стандарты, использующие сертификаты X.509

TLS/SSL и HTTPS используют профиль X.509, как и S/MIME (Secure Multipurpose Internet Mail Extensions) и метод EAP TLS для аутентификации WiFi. Любой протокол, использующий TLS, такой как SMTP, POP, IMAP, LDAP, XMPP и многие другие, по сути использует X.509. IPsec может использовать этот профиль для аутентификации узлов. Спецификация безопасности OpenCable определяет собственный профиль X.509 для использования в кабельной индустрии. Устройства, такие как смарт-карты и TPM, часто содержат сертификаты для идентификации себя или своих владельцев. Эти сертификаты представлены в формате X.509. Стандарт WS Security определяет аутентификацию либо через TLS, либо через собственный профиль сертификатов. Оба метода используют X.509. Система подписи кода Microsoft Authenticode использует X.509 для идентификации авторов компьютерных программ. Стандарт промышленной автоматизации OPC UA использует X.509. SSH обычно использует модель безопасности "Доверие при первом использовании" и не требует сертификатов. Однако популярная реализация OpenSSH поддерживает модель идентификации с подтверждением удостоверительным центром (CA), основанную на собственном формате сертификатов, отличном от X.509.