X.509 сертификаттарының форматы мен қағидалары

Кіріспе

X.509 – криптографияда ашық кілт сертификаттарының форматын анықтайтын Халықаралық телекоммуникация одағының (ITU) стандарты. X.509 сертификаттары көптеген интернет-протоколдарында, соның ішінде HTTPS негізі болып табылатын TLS/SSL-де қолданылады. X.509 сертификаты сандық қолтаңбаны пайдалана отырып, сәйкестендіруді ашық кілтке байланыстырады. Сертификат сәйкестендіруді (хосттың аты, ұйым немесе жеке тұлға) және ашық кілтті (RSA, DSA, ECDSA, ed25519 және т.б.) қамтиды және сертификаттау органымен қол қойылады немесе өзіне-өзі қол қойылады. Сертификатқа сенімді сертификаттау органы қол қойған немесе басқа тәсілмен тексерілген жағдайда, осы сертификатты иеленуші оның құрамындағы ашық кілтті басқа тараппен қауіпсіз байланыс орнату үшін немесе тиісті жеке кілтпен цифрлық қол қойылған құжаттарды тексеру үшін пайдалана алады. X.509 сонымен қатар сертификаттарды қайтарып алу тізімін анықтайды, бұл қол қоюшы орган жарамсыз деп таныған сертификаттар туралы ақпаратты тарату құралы, сондай-ақ сертификаттау жолын тексеру алгоритмін, бұл сертификаттарға аралық CA сертификаттарымен қол қоюға мүмкіндік береді, олар өз кезегінде басқа сертификаттармен қол қойылады, соңында сенімділік нүктесіне жетеді. X.509 ITU-ның «Стандарттау секторы» (ITU T-ның SG17) ITU T-ның 17-тобында анықталады және ол тағы бір ITU T стандарты – Abstract Syntax Notation One (ASN.1) негізінде құрылған.

Тарих және қолданылуы

X.509 бастапқыда 1988 жылдың 3 шілдесінде жарияланды және X.500 стандартымен байланысты дамытылды. Оның бастапқы міндеттері пайдаланушыларға ақпараттық ресурстарға қауіпсіз қол жеткізуді қамтамасыз ету және криптографиялық аралық шабуылдың алдын алу болды. Ол сертификаттарды беру үшін сертификаттау органдарының (CA) қатаң иерархиялық жүйесін қарастырады. Бұл PGP сияқты сенім желісі модельдерімен қарама-қайшы келеді, онда кез келген адам (арнайы CA ғана емес) қол қоя алады және осылайша басқалардың кілттік сертификаттарының жарамдылығын растай алады. X.509 нұсқасы 3 көпірлер мен торлар сияқты басқа топологияларды қолдауға мүмкіндік береді. Оны OpenPGP сияқты сенім желісінде пайдалануға болады, бірақ 2004 жылға дейін осылай пайдалану сирек болды. X.500 жүйесін мемлекеттік ақпаратты бөлісу шартын орындау мақсатында тәуелсіз мемлекеттер ғана іске асырды, ал IETF-тің Public Key Infrastructure (X.509) (PKIX) жұмыс тобы стандартты Интернеттің икемді ұйымдастыруына бейімдеді. Шын мәнінде, X.509 сертификаты термині көбінесе IETF-тің PKIX сертификаты мен X.509 v3 сертификат стандартының CRL профилін білдіреді, бұл Public Key Infrastructure (X.509) үшін PKIX деп белгілі. Public Key Infrastructure (PKI) және X.509 сертификаттарымен байланысты алғашқы мәселе — «қай каталог» деген мәселе болды. Мәселе мынада: клиент жоғалған аралық сертификаттарды қайдан алу керектігін білмейді, өйткені жаһандық X.500 каталогы ешқашан құрылмады. Бұл мәселе барлық аралық сертификаттарды сұрауға қосу арқылы шешілді. Мысалы, алғашқы веб-серверлер клиентке тек веб-сервердің сертификатын жіберді. Аралық CA сертификаты болмаған немесе оны қайдан табуға болатынын білмеген клиенттер CA-дан сервердің сертификатына жарамды тізбек құра алмады. Бұл мәселені шешу үшін веб-серверлер енді веб-сервердің сертификатымен бірге барлық аралық сертификаттарды жібереді. PKIX IETF немесе Интернет PKI стандартына сілтеме берсе де, басқа көптеген PKI бар, олардың әртүрлі саясаты бар. Мысалы, АҚШ үкіметінің өз саясаты бар жеке PKI бар, ал CA/Browser Forum-ның өз саясаты бар жеке PKI бар. АҚШ үкіметінің PKI 2500 беттен астам кітаптан тұрады. Егер ұйымның PKI IETF немесе CA/Browser Forum-нан тым алыстаса, онда ұйым веб-браузерлер, cURL және Wget сияқты жалпы құралдармен өзара іс-қимыл жасау қабілетін жоғалту қаупі бар. Мысалы, егер PKI тек дүйсенбі күні сертификаттарды беру саясатын ұстанса, онда cURL және Wget сияқты жалпы құралдар саясатты орындамайды және сейсенбі күні берілген сертификатқа рұқсат береді. Біркелкі тип = жалпыға ортақ. x509 сертификаты X.509 сертификаттары сандық қолтаңбаны пайдалана отырып, жеке тұлғаны ашық кілтке байланыстырады. X.509 жүйесінде куәліктердің екі түрі бар. Біріншісі — CA сертификаты. Екіншісі — соңғы нүкте сертификаты. CA сертификаты басқа сертификаттарды беруге болады. Жоғары деңгейдегі, өзіне-өзі қол қойылған CA сертификаты кейде Root CA сертификаты деп аталады. Басқа CA сертификаттары аралық CA немесе бағынышты CA сертификаттары деп аталады. Соңғы нүкте сертификаты пайдаланушыны жеке тұлға, ұйым немесе кәсіпорын ретінде анықтайды. Соңғы нүкте сертификаты басқа сертификаттарды бере алмайды. Соңғы нүкте сертификаты кейде жапырақ сертификаты деп аталады, өйткені одан төмен басқа сертификаттар берілмейді. Сертификатталған сертификатты қалаған ұйым, сертификатқа қол қою туралы сұрау (CSR), қарапайым сертификатты тіркеу протоколы (SCEP) немесе сертификатты басқару протоколы (CMP) сияқты протоколды пайдалана отырып, CA-дан сұрайды. Ұйым алдымен жеке кілтті құпия сақтап, кілт жұбын жасайды және оны CSR-ге қол қою үшін пайдаланады. CSR-де өтініш берушінің жеке басын анықтайтын ақпарат және өтініш берушінің қолтаңбасын және жеке тұлғаға, ұйымға немесе кәсіпорынға тән ерекше атауды (DN) тексеру үшін пайдаланылатын ашық кілті бар. CSR сертификаттаушы орган талап еткен басқа да сенімхаттармен немесе жеке басын куәландыратын құжаттармен бірге берілуі мүмкін. CSR тіркеу органы арқылы расталады, содан кейін сертификаттау органы белгілі бір ерекше атауға ашық кілтті байланыстыратын сертификат береді. Тіркеу органы мен сертификаттау органының рөлдері әдетте алаяқтық тәуекелін азайту үшін міндеттерін бөліп, жеке бизнес-бөлімдер болып табылады. Ұйымның сенімді түбірлік сертификаттары барлық қызметкерлерге таратылуы мүмкін, сондықтан олар компанияның PKI жүйесін пайдалана алады. Internet Explorer, Firefox, Opera, Safari және Chrome сияқты браузерлер алдын ала орнатылған түбірлік сертификаттардың алдын ала белгіленген жиынтығымен келеді, сондықтан SSL сертификаттары негізгі сертификат беруші органдардан бірден жұмыс істейді; шындығында браузерлерді әзірлеушілер қандай CA-лар браузер пайдаланушылары үшін сенімді үшінші тараптар екенін анықтайды. Мысалы, Firefox Included CA тізімін қамтитын CSV және/немесе HTML файлымен қамтамасыз етеді. X.509 сонымен қатар сертификатты жою тізімі (CRL) жүзеге асыруларына арналған стандарттарды қамтиды. IETF бекіткен сертификаттың жарамдылығын тексерудің тағы бір жолы — Online Certificate Status Protocol (OCSP). Firefox 3.0 OCSP тексеруін әдепкі бойынша қосты, сондай-ақ Vista және одан кейінгі нұсқаларындағы Windows та қосты.

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 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.

Куәліктің нақты қолданылуын көрсететін кеңейтулер

(және оның алдыңғы нұсқалары) сертификаттың қалай қолданылуын көрсететін сертификат кеңейтімдерін анықтайды. Олардың көпшілігі iso ccitt(2) ds(5) id ce(29) OID бірлескен идентификаторының доғалары болып табылады. 4.2.1-бөлімде сипатталған ең көп таралғандарының кейбіреулері:

Негізгі шектеулер, { id ce 19 }, сертификаттың CA сертификаты екенін және басқа сертификаттарды растауға немесе шығаруға болатынын көрсету үшін қолданылады. Шектеу маңызды деп белгіленуі мүмкін. Егер шектеу маңызды деп белгіленсе, агент шектеуді түсінбесе, сертификатты өңдеуден бас тартуы керек. Агент түсінбеген маңызды емес шектеуді өңдеуді жалғастыра алады. Кілтті пайдалану, { id ce 15 }, сертификаттағы ашық кілтті пайдаланып орындалатын криптографиялық операцияларды көрсететін биттік картаны ұсынады; мысалы, кілт қолтаңбалар үшін, бірақ шифрлау үшін қолданылмауы керек екенін көрсете алады. Кеңейтілген кілтті пайдалану, { id ce 37 }, әдетте жапырақ сертификатында, сертификаттағы ашық кілттің мақсатын көрсету үшін қолданылады. Онда OID тізімі бар, олардың әрқайсысы рұқсат етілген пайдалануды көрсетеді. Мысалы, { id pkix 3 1 } кілтті TLS немесе SSL қосылымының серверлік жағында пайдалануға болатынын көрсетеді; { id pkix 3 4 } кілтті электрондық поштаны қорғау үшін пайдалануға болатынын көрсетеді. Жалпы алғанда, RFC 5280 стандартына сәйкес, егер сертификатта оның қолданылуын шектейтін бірнеше кеңейтімдер болса, белгілі бір мақсатқа орайлы болу үшін барлық шектеулер орындалуы тиіс. RFC keyUsage және extendedKeyUsage кеңейтімдері бар сертификаттың нақты мысалын келтіреді: бұл жағдайда екеуі де өңделуі керек және сертификатты тек екі кеңейтім де сертификатты пайдалануды дұрыс анықтаса ғана қолдануға болады. Мысалы, NSS сертификатты пайдалануды анықтау үшін екі кеңейтімді де қолданады.

Кеңейтілген валидациялау сертификаттары

CA/Browser Forum PKI аясында жұмыс істейтін сертификаттау органдары әртүрлі деңгейдегі сертификаттарды шығарады. Әртүрлі растаулар сертификаттың күтілгендей екендігіне әртүрлі деңгейде сенім береді. Мысалы, веб-серверді Domain Validation (DV) деп аталатын электрондық пошта арқылы ең төменгі деңгейде растауға болады. Немесе веб-серверді Extended Validation (EV) деп аталатын егжей-тегжейлі әдістерді қолдана отырып, жоғары деңгейдегі сеніммен растауға болады. Іс жүзінде, DV сертификаты дегеніз, мысалы, example.com домені үшін сертификат берілгенін білдіреді, содан кейін webmaster@example.com электрондық поштасына жауап келгеннен кейін. EV сертификаты дегеніз, example.com домені үшін сертификат берілгенін және Example, LLC сияқты компания доменнің иесі екенін, ал иесінің құрылтай құжаты арқылы тексерілгенін білдіреді. Extended validation қосымша қауіпсіздік шараларын қоспайды, сондықтан EV сертификатын пайдаланатын қауіпсіз арнаны орнату, DV сияқты басқа деңгейдегі растауды пайдаланатын арнадан "күштірек" емес. Extended validation X.509 v3 кеңейтуін пайдалана отырып сертификатта көрсетіледі. Әр CA extended validation растау үшін әртүрлі объект идентификаторын (OID) қолданады. Extended validation көрсету үшін бірыңғай OID жоқ, бұл пайдаланушы агентін бағдарламалауды қиындатады. Әрбір пайдаланушы агенті extended validation көрсеткен OID тізіміне ие болуы керек. CA/Browser Forum PKI extended validation-ды мойындайды және көптеген браузерлер сайттың EV сертификатын көрсету үшін пайдаланушыға визуалды хабарлама береді. Басқа PKI, мысалы, Интернет PKI (PKIX), extended validation-ға ерекше мән бермейді. PKIX саясатын қолданатын cURL және Wget сияқты құралдар EV сертификатын басқа сертификаттар сияқты қарастырады. Қауіпсіздік сарапшысы Питер Гутманн CA-лардың пайда деңгейін қалпына келтіру үшін EV сертификаттарын жасағанын айтады, себебі "Төменге қарай жарыс" пайданы азайтты. "Төменге қарай жарыс" кезінде CA-лар тұтынушыларды өз сертификаттарын сатып алуға көндіру үшін бағаны төмендетті. Нәтижесінде пайда азайды және CA-лар сертификаттарға кепілдік деңгейін төмендетті, тіпті сертификатта ешқандай кепілдік болмайтын жағдайға жетті. p7r – PKCS#7 CSR-ға жауап. Жаңа қол қойылған сертификатты және CA-ның өзінің сертификатын қамтиды. p7s – PKCS#7 Цифрлық қолтаңба. Түпнұсқа қол қойылған файл немесе хабарлама болуы мүмкін. S/MIME электрондық поштаға қол қою үшін қолданылады. RFC 2311 стандартында анықталған. p7m – PKCS#7 (SignedData, EnvelopedData) хабарламасы, мысалы, шифрланған ("enveloped") файл, хабарлама немесе 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 форматындағы деректерді қамтиды, мысалы, IIS-те құрылған PFX файлдары). 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-ші мысал: екі PKI арасындағы сертификаттау органының (CA) түбір деңгейіндегі кросс-сертификаттау

PKI 2-дегі қолданушы сертификаттарына (мысалы, "User 2") PKI 1-ге сенімділік қалыпқа келтіру үшін CA1, CA2-нің ашық кілтін қамтитын сертификатты (cert2.1) жасайды. Енді "cert2 және cert2.1 (жасыл) екеуінің де бірдей тақырыбы мен ашық кілті бар, сондықтан cert2.2 (User 2) үшін екі жарамды тізбек бар: "cert2.2 → cert2" және "cert2.2 → cert2.1 → cert1". Сол сияқты, CA2 CA1-дің ашық кілтін қамтитын сертификатты (cert1.1) жасау арқылы PKI 1-дегі қолданушы сертификаттарына (мысалы, "User 1") PKI 2 сенім арта алады.

2-мысал: CA сертификатының жаңартылуы

Cert1 және cert3 екеуінде де бірдей ашық кілт (ескі кілт) болғандықтан, cert5 үшін екі жарамды сертификат тізбегі бар: "cert5 → cert1" және "cert5 → cert3 → cert2", ал cert6 үшін де осыған ұқсас жағдай. Бұл, жаңа CA кілттеріне көшу кезінде, жаңа түбірлік CA сертификаты немесе ескісі сенімділік нүктесі ретінде қолданылған жағдайда, ескі пайдаланушы сертификаттарына (мысалы, cert5) және жаңа сертификаттарға (мысалы, cert6) бірдей сенім білдіруге мүмкіндік береді.

X.509 сертификаттарының үлгісі

Бұл бұрын wikipedia.org және басқа да бірнеше Уикипедия сайттарында қолданылған, декодталған X.509 сертификатының мысалы. Ол "Емитент" өрісінде көрсетілгендей, GlobalSign компаниясымен шығарылған. Оның "Subject" өрісі Уикипедияны ұйым ретінде сипаттайды, ал DNS форматындағы "Subject Alternative Name" (SAN) өрісі оны қолдануға болатын хост атауларын көрсетеді. "Subject Public Key Info" өрісі ECDSA ашық кілтін қамтиды, ал төменгі жағындағы қолтаңба GlobalSign компаниясының RSA жеке кілтімен жасалған. (Бұл мысалдардағы қолтаңбалар толық емес.)

Криптографиялық әлсіздіктер

Цифрлық қолтаңба жүйелері жұмыс істеуі үшін қауіпсіз криптографиялық хэш-функцияларға тәуелді. Егер ашық кілт инфрақұрылымы қауіпсіздігі жойылған хэш-функцияны пайдалануға рұқсат берсе, шабуылшы сертификаттарды жалғандау үшін хэш-функцияның осал тұстарын пайдалана алады. Атап айтқанда, егер шабуылшы хэш-соқтығысуды (hash collision) жасаса, ол CA-ны зиянсыз мазмұны бар сертификатқа қол қоюға көндіре алады, мұнда осы мазмұнның хэші шабуылшының қалауынша таңдалған мәндермен басқа, зиянды сертификат мазмұнының хэшімен сәйкес келеді. Содан кейін шабуылшы CA ұсынған қолтаңбаны зиянды сертификаттың мазмұнына қоса алады, нәтижесінде CA қол қойғандай көрінетін зиянды сертификат пайда болады. Зиянды сертификаттың мазмұны шабуылшы тарапынан толығымен анықталады, сондықтан оның жарамдылық мерзімі немесе хост аты зиянсыз сертификаттан өзгеше болуы мүмкін. Зиянды сертификатта «CA: true» өрісі болуы мүмкін, бұл оған сенімді сертификаттарды шығаруға мүмкіндік береді. MD2 негізіндегі сертификаттар ұзақ уақыт бойы қолданылып келді және preimage шабуылдарына ұшырайды. Түбірлік сертификат өзінен-өзі қолтаңбаланғандықтан, шабуылшылар осы қолтаңбаны пайдаланып, оны аралық сертификат ретінде қолдана алады. 2005 жылы Арьен Ленстра мен Бенне де Вегер «MD5 хэш-функциясындағы соқтығысуды пайдаланып, қолтаңбалары бірдей, бірақ ашық кілттерімен ғана ерекшеленетін екі X.509 сертификатын қалай жасауға болатынын» көрсетті. 2008 жылы Александр Сотиров пен Марк Стивенс Хаос коммуникация конгресінде RapidSSL әлі де MD5 негізінде X.509 сертификаттарын шығарып жатқандығын пайдаланып, барлық танымал браузерлер қабылдайтын жалған сертификат беру органы құруға мүмкіндік беретін практикалық шабуылды ұсынды. 2009 жылдың сәуірінде Eurocrypt конференциясында Macquarie университетінің австралиялық зерттеушілері «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 Forum 2011 жылдан бері базалық талаптардың 7.1-бөлімінде сериялық нөмірдің энтропиясын міндетті етіп келеді. 2016 жылдан бастап базалық талаптар SHA 1 қолданылатын сертификаттарды шығаруға тыйым салады. 2017 жылдың басында Chrome және Firefox SHA 1 қолданылатын сертификаттарды қабылдамайды. 2017 жылдан бастап Edge және Safari да SHA 1 сертификаттарын қабылдамайды. Браузерлік емес X.509 валидаторлары әлі де SHA 1 сертификаттарын қабылдамайды.

PKIX жұмыс тобы

1995 жылы Интернет-инженерлік жұмыс тобы Ұлттық стандарттар және технология институтымен бірлесіп, Ашық кілт инфрақұрылымы (X.509) жұмыс тобын құрды. 2014 жылдың маусым айында аяқталған бұл жұмыс тобы көбінесе "PKIX" деп аталады. Ол X.509-ды іс жүзінде қолдану және енгізу туралы RFC және басқа стандарттық құжаттарды жасады. Атап айтқанда, ол RFC 5280 және оның ізбасары RFC 5280-ді жасады, олар Интернет протоколдарында X.509-ды қалай пайдалану керектігін анықтайды.

X.509 сертификаттарын пайдаланатын негізгі протоколдар мен стандарттар

TLS/SSL және HTTPS X.509 профилін пайдаланады, сондай-ақ S/MIME (Secure Multipurpose Internet Mail Extensions) және WiFi аутентификациясы үшін EAP TLS әдісі де пайдаланады. SMTP, POP, IMAP, LDAP, XMPP және тағы да көптеген TLS қолданатын кез келген протокол X.509-ды қажет етеді. IPsec пірлерді аутентификациялау үшін осы профильді пайдалана алады. OpenCable қауіпсіздік спецификациясы кабельдік индустрияда пайдалану үшін X.509-дың өзіндік профилін анықтайды. Смарт-карталар және TPM сияқты құрылғылар өздерін немесе иелерін анықтау үшін сертификаттарды сақтайды. Бұл сертификаттар X.509 нысанында болады. WS Security стандарты аутентификацияны TLS немесе өзінің сертификат профилі арқылы анықтайды. Екі әдіс те X.509-ды қолданады. Microsoft Authenticode кодты қол қою жүйесі компьютерлік бағдарламалардың авторларын анықтау үшін X.509-ды пайдаланады. OPC UA өндірістік автоматтандыру байланыс стандарты X.509-ды қолданады. SSH көбінесе Trust On First Use қауіпсіздік моделін қолданады және сертификаттар қажеттілігі тумайды. Дегенмен, танымал OpenSSH нұсқасы өзінің X.509 емес сертификат форматына негізделген CA қол қойылған сәйкестік моделін қолдайды.