Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
X.509
open-in-new
<h2 id="history-and-usage">History and usage</h2> <p>X.509 was initially issued on July 3, 1988, and was begun in association with the <a href="/facts/X.500/zaeao2Lf">X.500</a> standard. The first tasks of it was providing users with secure access to information resources and avoiding a cryptographic <a href="/facts/Man-in-the-middle_attack/dx4cojdz">man-in-the-middle attack</a>. It assumes a strict hierarchical system of <a href="/facts/Certificate_authority/WAo8vMTN">certificate authorities</a> (CAs) for issuing the certificates. This contrasts with <a href="/facts/Web_of_trust/H2cy9v6s">web of trust</a> models, like <a href="/facts/Pretty_Good_Privacy/4BELG9BW">PGP</a>, where anyone (not just special CAs) may sign and thus attest to the validity of others' key certificates. </p><p>Version 3 of X.509 includes the flexibility to support other topologies like <a href="/facts/Network_bridge/5nyTQtNW">bridges</a> and <a href="/facts/Mesh_network/XnVSy5rK">meshes</a>.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> It can be used in a peer-to-peer, <a href="/facts/OpenPGP/4BELG9BW">OpenPGP</a>-like web of trust, but was rarely used that way as of 2004. The X.500 system has only been implemented by sovereign nations[<i>which?</i>] for state identity information sharing treaty fulfillment purposes, and the <a href="/facts/IETF/tIcCsFhX">IETF</a>'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 <i>X.509 certificate</i> usually refers to the IETF's PKIX certificate and <a href="/facts/Revocation_list/JSP12aR0">CRL</a> profile of the X.509 v3 certificate standard, as specified in <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a>, commonly called PKIX for <i>Public Key Infrastructure (X.509)</i>.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> </p><p>An early issue with <a href="/facts/Public_Key_Infrastructure/7fwMLxF4">Public Key Infrastructure</a> (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.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> </p><p>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 <a href="/facts/Web_browser/2pfyymLs">web browsers</a>, <a href="/facts/CURL/01m2dW2j">cURL</a>, and <a href="/facts/Wget/0EeAK2uj">Wget</a>. 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.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> </p> <h2 id="certificates">Certificates</h2> <p>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 <i>cannot</i> issue other certificates. An end-entity certificate is sometimes called a leaf certificate since no other certificates can be issued below it. </p><p>An organization that wants a signed certificate requests one from a CA using a protocol like <a href="/facts/Certificate_signing_request/0zvqmz2S">Certificate Signing Request (CSR)</a>, <a href="/facts/Simple_Certificate_Enrollment_Protocol/zIaDTI0I">Simple Certificate Enrollment Protocol (SCEP)</a> or <a href="/facts/Certificate_Management_Protocol/I3QLtPVo">Certificate Management Protocol (CMP)</a>. The organization first generates a <a href="/facts/Key_pair/gowoFTxS">key pair</a>, keeping the <a href="/facts/Private-key_cryptography/5zfe0b76">private key</a> secret and using it to sign the CSR. The CSR contains information identifying the applicant and the applicant's <a href="/facts/Public-key_cryptography/gowoFTxS">public key</a> that is used to verify the signature of the CSR - and the <a href="/facts/Distinguished_Name/KgpfD8nR">Distinguished Name</a> (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. </p><p>The CSR will be validated using a Registration Authority (RA), and then the <a href="/facts/Certification_authority/WAo8vMTN">certification authority</a> will issue a certificate binding a public key to a particular <a href="/facts/Distinguished_Name/KgpfD8nR">distinguished name</a>. The roles registration authority and certification authority are usually separate business units under <a href="/facts/Separation_of_duties/2kFl4Cje">separation of duties</a> to reduce the risk of fraud. </p><p>An organization's trusted <a href="/facts/Root_certificate/yPhjLEbe">root certificates</a> can be distributed to all employees so that they can use the company PKI system. Browsers such as <a href="/facts/Internet_Explorer/uL8a4Y5l">Internet Explorer</a>, <a href="/facts/Firefox/xez2zv8H">Firefox</a>, <a href="/facts/Opera_(web_browser)/2NYCcTj1">Opera</a>, <a href="/facts/Safari_(web_browser)/9R8v7tNl">Safari</a> and <a href="/facts/Google_Chrome/4INfWq37">Chrome</a> come with a predetermined set of root certificates pre-installed, so <a href="/facts/Secure_Sockets_Layer/pGy16TnA">SSL</a> 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.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> </p><p>X.509 and <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a> also include standards for certificate <a href="/facts/Revocation_list/JSP12aR0">revocation list</a> (CRL) implementations. Another <a href="/facts/IETF/tIcCsFhX">IETF</a>-approved way of checking a certificate's validity is the <a href="/facts/Online_Certificate_Status_Protocol/0SuMER8c">Online Certificate Status Protocol</a> (OCSP). <a href="/facts/Firefox_3.0/xervIswb">Firefox 3.0</a> enabled OCSP checking by default, as did versions of <a href="/facts/Microsoft_Windows/bwhAhuSL">Windows</a> from at least <a href="/facts/Windows_Vista/IASEUCTB">Vista</a> and later.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> </p> <h3>Structure of a certificate</h3> <p>The structure foreseen by the standards is expressed in a formal language, <a href="/facts/Abstract_Syntax_Notation_One/ryUN7doc">Abstract Syntax Notation One</a> (ASN.1). </p><p>The structure of an X.509 v3 <a href="/facts/Digital_certificate/J7aYI4Bx">digital certificate</a> is as follows: </p> <ul><li>Certificate <ul><li>Version Number</li> <li>Serial Number</li> <li>Signature Algorithm ID</li> <li>Issuer Name</li> <li>Validity period <ul><li>Not Before</li> <li>Not After</li></ul></li> <li>Subject name</li> <li>Subject Public Key Info <ul><li>Public Key Algorithm</li> <li>Subject Public Key</li></ul></li> <li>Issuer Unique Identifier (optional)</li> <li>Subject Unique Identifier (optional)</li> <li>Extensions (optional) <ul><li>...</li></ul></li></ul></li> <li>Certificate Signature Algorithm</li> <li>Certificate Signature</li></ul> <p>The Extensions field, if present, is a sequence of one or more certificate extensions.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a>: §4.1.2.9: Extensions Each extension has its own unique ID, expressed as <a href="/facts/Object_identifier/wEC9ubWd">object identifier (OID)</a>, which is a set of values, together with either a critical or non-critical indication. A certificate-using system must reject the certificate if it encounters a critical extension that it does not recognize, or a critical extension that contains information that it cannot process. A non-critical extension may be ignored if it is not recognized, but must be processed if it is recognized.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a>: §4.2: Certificate Extensions </p><p>The structure of version 1 is given in <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc1422">1422</a>. </p><p>The inner format of issuer and subject unique identifiers specified in <a href="https://www.itu.int/rec/T-REC-X.520"><i>X.520 The Directory: Selected attribute types</i></a> recommendation. </p><p>ITU-T introduced issuer and subject unique identifiers in version 2 to permit the reuse of issuer or subject name after some time. An example of reuse will be when a <a href="/facts/Certificate_authority/WAo8vMTN">CA</a> goes bankrupt and its name is deleted from the country's public list. After some time another CA with the same name may register itself, even though it is unrelated to the first one. However, <a href="/facts/IETF/tIcCsFhX">IETF</a> recommends that no issuer and subject names be reused. Therefore, version 2 is not widely deployed in the Internet. </p><p>Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for <a href="/facts/Code_signing/xnLHJYRa">signing digital objects</a>). </p><p>In all versions, the serial number must be unique for each certificate issued by a specific CA (as mentioned in <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a>). </p> <h3>Extensions informing a specific usage of a certificate</h3> <p><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a> (and its predecessors) defines a number of certificate extensions which indicate how the certificate should be used. Most of them are arcs from the joint-iso-ccitt(2) ds(5) id-ce(29) OID. Some of the most common, defined in section 4.2.1, are: </p> <ul><li>Basic Constraints, { id-ce 19 },<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a>: §4.2.1.9 are used to indicate whether the certificate is a CA certificate and can certify or issue other certificates. A constraint can be marked as critical. If a constraint is marked critical, then an agent must fail to process the certificate if the agent does not understand the constraint. An agent can continue to process a non-critical constraint it does not understand.</li> <li>Key Usage, { id-ce 15 },<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a>: §4.2.1.3 provides a bitmap specifying the cryptographic operations which may be performed using the public key contained in the certificate; for example, it could indicate that the key should be used for signatures but not for encipherment.</li> <li>Extended Key Usage, { id-ce 37 },<a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a>: §4.2.1.12 is used, typically on a leaf certificate, to indicate the purpose of the public key contained in the certificate. It contains a list of OIDs, each of which indicates an allowed use. For example, { id-pkix 3 1 } indicates that the key may be used on the server end of a TLS or SSL connection; { id-pkix 3 4 } indicates that the key may be used to secure email.</li></ul> <p>In general when using <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a>, if a certificate has several extensions restricting its use, all restrictions must be satisfied for a given use to be appropriate. The RFC gives the specific example of a certificate containing both keyUsage and extendedKeyUsage: in this case, both must be processed and the certificate can only be used if both extensions are coherent in specifying the usage of a certificate. For example, <a href="/facts/Network_Security_Services/y7bq3SV2">NSS</a> uses both extensions to specify certificate usage.<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a> </p> <h3>Extended Validation certificates</h3> <p>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 <i>Domain Validation (DV)</i>. Or a web server can be validated at a higher level of assurances using more detailed methods called <i>Extended Validation (EV)</i>. </p><p>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 <a href="/facts/Articles_of_incorporation/mByPDXmE">Articles of Incorporation</a>. </p><p>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. </p><p>Extended validation is signaled in a certificate using X.509 v3 extension. Each CA uses a different <a href="/facts/Object_identifier/wEC9ubWd">Object Identifier (OID)</a> 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. </p><p>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. </p><p>Security expert <a href="/facts/Peter_Gutmann_(computer_scientist)/wSd17S87">Peter Gutmann</a> states CA's created EV certificates to restore profit levels after the <a href="/facts/Race_to_the_bottom/BDu34pwQ">Race to the Bottom</a> 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.<a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a> </p> <h3>Certificate filename extensions</h3> <p>There are several commonly used <a href="/facts/Filename_extension/cJgfAym4">filename extensions</a> for X.509 certificates. Some of these extensions are also used for other data such as private keys. </p> <ul><li>.pem – (<a href="/facts/Privacy-enhanced_Electronic_Mail/1VPrsoPx">Privacy-enhanced Electronic Mail</a>) <a href="/facts/Base64/xIvVm33q">Base64</a> encoded <a href="/facts/Distinguished_Encoding_Rules/sNL76pTs">DER</a> certificate, enclosed between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----</li> <li>.cer, .crt, .der – usually in binary <a href="/facts/Distinguished_Encoding_Rules/sNL76pTs">DER</a> form, but Base64-encoded certificates are common too (see .pem above)</li> <li>.p8, .p8e, .pk8 – exported private key as specified in <a href="/facts/PKCS8/psr9e3Xe">PKCS#8</a>. May be in DER or PEM form that starts with -----BEGIN PRIVATE KEY-----. The encrypted key starts with -----BEGIN ENCRYPTED PRIVATE KEY----- and may have the .p8e extension.</li> <li>.p10, .csr – <a href="/facts/PKCS10/M0swhEyc">PKCS#10</a> a <a href="/facts/Certificate_signing_request/0zvqmz2S">certificate signing request</a> (CSR). In PEM form starts with -----BEGIN CERTIFICATE REQUEST-----. These are generated for submission to certificate-authorities (CA). It includes key details of the requested certificate such as Common Name (/CN), subject, organization, state, country, as well as the <i>public key</i> of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public <i>certificate</i> (which includes the public key but not the private key), which itself can be in a couple of formats but usually in .p7r.<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a></li> <li>.p7r – <a href="/facts/PKCS7/M0swhEyc">PKCS#7</a> response to CSR. Contains the newly-signed certificate, and the CA's own cert.</li> <li>.p7s – <a href="/facts/PKCS7/M0swhEyc">PKCS#7</a> Digital Signature. May contain the original signed file or message. Used in <a href="/facts/S%2fMIME/YufdsBt3">S/MIME</a> for email signing. Defined in RFC 2311.</li> <li>.p7m – <a href="/facts/PKCS7/M0swhEyc">PKCS#7</a> (SignedData, EnvelopedData) Message e.g. encrypted ("enveloped") file, message or MIME email letter. Defined in RFC 2311.</li> <li>.p7c – <a href="/facts/PKCS7/M0swhEyc">PKCS#7</a> degenerated SignedData "certs-only" structure, without any data to sign. Defined in RFC 2311.</li> <li>.p7b, .keystore – <a href="/facts/PKCS7/M0swhEyc">PKCS#7</a> SignedData structure without data, just certificate(s) bundle and/or <a href="/facts/Revocation_list/JSP12aR0">CRLs</a> (rarely) but not a private key. Uses <a href="/facts/Distinguished_Encoding_Rules/sNL76pTs">DER</a> form or <a href="/facts/X.690/sNL76pTs">BER</a> or PEM that starts with -----BEGIN PKCS7-----. 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 <i>defined</i> way to include certification-path certificates.</li> <li>.p12, .pfx, .pkcs12 – <a href="/facts/PKCS12/PLwhjewk">PKCS#12</a>, may contain certificate(s) (public) and private keys (password protected) in a single file. .pfx – <i>Personal Information eXchange</i> PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g. with PFX files generated in <a href="/facts/Internet_Information_Services/nqmfJr3T">IIS</a>).</li> <li>.crl – A <a href="/facts/Certificate_Revocation_List/JSP12aR0">Certificate Revocation List</a> (CRL). Certificate Authorities produce these as a way to de-authorize certificates before expiration.</li></ul> <p><a href="/facts/PKCS7/M0swhEyc">PKCS#7</a> 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. </p> <h2 id="certificate-chains-and-cross-certification">Certificate chains and cross-certification</h2> <p>A certificate chain (see the equivalent concept of "certification path" defined by <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a> section 3.2) is a list of certificates (usually starting with an end-entity certificate) followed by one or more <a href="/facts/Certificate_authority/WAo8vMTN">CA</a> certificates (usually the last one being a self-signed certificate), with the following properties: </p> <ol><li>The Issuer of each certificate (except the last one) matches the Subject of the next certificate in the list</li> <li>Each certificate (except the last one) is signed by the secret key corresponding to the next certificate in the chain (i.e. the signature of one certificate can be verified using the public key contained in the following certificate)</li> <li>The last certificate in the list is a <a href="/facts/Trust_anchor/GWcn7Mca">trust anchor</a>: a certificate that you trust because it was delivered to you by some trustworthy procedure</li></ol> <p>Certificate chains are used in order to check that the public key (PK) contained in a target certificate (the first certificate in the chain) and other data contained in it effectively belongs to its subject. In order to ascertain this, the signature on the target certificate is verified by using the PK contained in the following certificate, whose signature is verified using the next certificate, and so on until the last certificate in the chain is reached. As the last certificate is a trust anchor, successfully reaching it will prove that the target certificate can be trusted. </p><p>The description in the preceding paragraph is a simplified view on the <a href="/facts/Certification_path_validation_algorithm/UPforl4U">certification path validation process</a> as defined by <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a> section 6, which involves additional checks, such as verifying validity dates on certificates, looking up <a href="/facts/Revocation_list/JSP12aR0">CRLs</a>, etc. </p> <p>Examining how certificate chains are built and validated, it is important to note that a concrete certificate can be part of very different certificate chains (all of them valid). This is because several CA certificates can be generated for the same subject and public key, but be signed with different private keys (from different CAs or different private keys from the same CA). So, although a single X.509 certificate can have only one issuer and one CA signature, it can be validly linked to more than one certificate, building completely different certificate chains. This is crucial for cross-certification between PKIs and other applications.<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a> See the following examples: </p> <h3>Examples</h3> <p>In these diagrams: </p> <ul><li>Each box represents a certificate, with its Subject in bold</li> <li>A → B means "A is signed by B" (or, more precisely, "A is signed by the secret key corresponding to the public key contained in B").</li> <li>Certificates with the same color (that are not white/transparent) contain the same public key</li></ul> <h4>Example 1: Cross-certification at root Certification Authority (CA) level between two PKIs</h4> <p>In order to manage that user certificates existing in PKI 2 (like "User 2") are trusted by PKI 1, CA1 generates a certificate (cert2.1) containing the public key of CA2.<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a> Now both "cert2 and cert2.1 (in green) have the same subject and public key, so there are two valid chains for cert2.2 (User 2): "cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1". </p><p>Similarly, CA2 can generate a certificate (cert1.1) containing the public key of CA1 so that user certificates existing in PKI 1 (like "User 1") are trusted by PKI 2. </p> <h4>Example 2: CA certificate renewal</h4> <p><a href="http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf"><i>Understanding Certification Path Construction</i></a> (PDF). PKI Forum. September 2002. To allow for graceful transition from the old signing key pair to the new signing key pair, the CA should issue a certificate that contains the old public key signed by the new private signing key and a certificate that contains the new public key signed by the old private signing key. Both of these certificates are self-issued, but neither is <a href="/facts/Self-signed_certificate/3jBNJlWf">self-signed</a>. Note that these are in addition to the two self-signed certificates (one old, one new). </p><p>Since both cert1 and cert3 contain the same public key (the old one), there are two valid certificate chains for cert5: "cert5 → cert1" and "cert5 → cert3 → cert2", and analogously for cert6. This allows that old user certificates (such as cert5) and new certificates (such as cert6) can be trusted indifferently by a party having either the new root CA certificate or the old one as trust anchor during the transition to the new CA keys.<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a> </p> <h2 id="sample-x509-certificates">Sample X.509 certificates</h2> <p>This is an example of a decoded X.509 certificate that was used in the past by wikipedia.org and several other Wikipedia websites. It was issued by <a href="/facts/GlobalSign/arx6gtCV">GlobalSign</a>, as stated in the Issuer field. Its Subject field describes Wikipedia as an organization, and its Subject Alternative Name (SAN) field for DNS describes the hostnames for which it could be used. The Subject Public Key Info field contains an <a href="/facts/ECDSA/gl0mfnS1">ECDSA</a> public key, while the signature at the bottom was generated by GlobalSign's <a href="/facts/RSA_(cryptosystem)/XTzyfHuq">RSA</a> private key. (The signatures in these examples are truncated.) </p> <h3>End-entity certificate</h3> Certificate: Data: Version: 3 (0x2) Serial Number: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Validity Not Before: Nov 21 08:00:00 2016 GMT Not After : Nov 22 07:59:59 2017 GMT Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: 9d:3b:ef ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Agreement Authority Information Access: CA Issuers - URI:<a href="http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt">http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt</a> OCSP - URI:<a href="http://ocsp2.globalsign.com/gsorganizationvalsha2g2">http://ocsp2.globalsign.com/gsorganizationvalsha2g2</a> X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.4146.1.20 CPS: <a href="https://www.globalsign.com/repository/">https://www.globalsign.com/repository/</a> Policy: 2.23.140.1.2.2 X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:<a href="http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl">http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl</a> X509v3 Subject Alternative Name: DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Key Identifier: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Signature Algorithm: sha256WithRSAEncryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35: ... <p>To validate this end-entity certificate, one needs an intermediate certificate that matches its Issuer and Authority Key Identifier: </p> <table><tbody><tr><th>Issuer</th><td>C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2</td></tr><tr><th>Authority Key Identifier</th><td>96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C</td></tr></tbody></table> <p>In a TLS connection, a properly-configured server would provide the intermediate as part of the handshake. However, it's also possible to retrieve the intermediate certificate by fetching the "CA Issuers" URL from the end-entity certificate. </p> <h3>Intermediate certificate</h3> <p>This is an example of an intermediate certificate belonging to a <a href="/facts/Certificate_authority/WAo8vMTN">certificate authority</a>. This certificate signed the end-entity certificate above, and was signed by the root certificate below. Note that the subject field of this intermediate certificate matches the issuer field of the end-entity certificate that it signed. Also, the "subject key identifier" field in the intermediate matches the "authority key identifier" field in the end-entity certificate. </p> Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:44:4e:f0:42:47 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Feb 20 10:00:00 2014 GMT Not After : Feb 20 10:00:00 2024 GMT Subject: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Subject Key Identifier: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: <a href="https://www.globalsign.com/repository/">https://www.globalsign.com/repository/</a> X509v3 CRL Distribution Points: Full Name: URI:<a href="http://crl.globalsign.net/root.crl">http://crl.globalsign.net/root.crl</a> Authority Information Access: OCSP - URI:<a href="http://ocsp.globalsign.com/rootr1">http://ocsp.globalsign.com/rootr1</a> X509v3 Authority Key Identifier: keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: ... <h3>Root certificate</h3> <p>This is an example of a <a href="/facts/Self-signed_certificate/3jBNJlWf">self-signed</a> root certificate representing a <a href="/facts/Certificate_authority/WAo8vMTN">certificate authority</a>. Its issuer and subject fields are the same, and its signature can be validated with its own public key. Validation of the trust chain has to end here. If the validating program has this root certificate in its trust store, the end-entity certificate can be considered trusted for use in a TLS connection. Otherwise, the end-entity certificate is considered untrusted. </p> Certificate:<a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a> Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha1WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Sep 1 12:00:00 1998 GMT Not After : Jan 28 12:00:00 2028 GMT Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: ... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: ... <h2 id="security">Security</h2> <p>There are a number of publications about PKI problems by <a href="/facts/Bruce_Schneier/kWxPFPmQ">Bruce Schneier</a>, <a href="/facts/Peter_Gutmann_(computer_scientist)/wSd17S87">Peter Gutmann</a> and other security experts.<a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a><a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a><a class="footnote-ref" id="fnref:24" href="#fn:24"><sup>24</sup></a> </p> <h3>Architectural weaknesses</h3> <ul><li>Use of blocklisting invalid certificates (using <a href="/facts/Revocation_list/JSP12aR0">CRLs</a> and <a href="/facts/Online_Certificate_Status_Protocol/0SuMER8c">OCSP</a>), <ul><li>If the client only trusts certificates when CRLs are available, then they lose the offline capability that makes PKI attractive. So most clients do trust certificates when CRLs are not available, but in that case an attacker that controls the communication channel can disable the CRLs. Adam Langley of Google has said soft-fail CRL checks are like a safety belt that works except when you have an accident.<a class="footnote-ref" id="fnref:25" href="#fn:25"><sup>25</sup></a></li></ul></li> <li>CRLs are notably a poor choice because of large sizes and convoluted distribution patterns,</li> <li>Ambiguous OCSP semantics and lack of historical revocation status,</li> <li>Revocation of root certificates is not addressed,</li> <li>Aggregation problem: Identity claims (authenticate with an identifier), attribute claims (submit a bag of vetted attributes), and policy claims are combined in a single container. This raises privacy, policy mapping, and maintenance issues.</li> <li>Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore, a large number of CAs exist on the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, as in common business practice.<a class="footnote-ref" id="fnref:26" href="#fn:26"><sup>26</sup></a></li> <li>Federation problem: Certificate chains that are the result of subordinate CAs, bridge CAs, and cross-signing make validation complex and expensive in terms of processing time. Path validation semantics may be ambiguous. The hierarchy with a third-party trusted party is the only model. This is inconvenient when a bilateral trust relationship is already in place.</li> <li>Issuance of an <a href="/facts/Extended_Validation_Certificate/z9DuN1J0">Extended Validation (EV) certificate</a> for a hostname doesn't prevent issuance of a lower-validation certificate valid for the same hostname, which means that the higher validation level of EV doesn't protect against man-in-the-middle attacks.<a class="footnote-ref" id="fnref:27" href="#fn:27"><sup>27</sup></a></li></ul> <h3>Problems with certification authorities</h3> <ul><li>The person or organization that purchases a certificate will often utilize the least expensive certification authority. In response, CA's have cut prices and removed more expensive validation checks in what is known as a <a href="/facts/Race_to_the_bottom/BDu34pwQ">Race to the Bottom</a>. The Race to the Bottom is partly addressed by <a href="/facts/Extended_Validation/z9DuN1J0">Extended Validation (EV)</a> certificates, yet trust value in the eyes of security experts are diminishing.<a class="footnote-ref" id="fnref:28" href="#fn:28"><sup>28</sup></a> According to <a href="/facts/Peter_Gutmann_(computer_scientist)/wSd17S87">Peter Gutmann</a>, EV certificates do not add any additional security controls. Rather, EV certificates merely restore CA profits to levels prior to the Race to the Bottom by allowing a CA to charge more for a service they should have been providing all along.<a class="footnote-ref" id="fnref:29" href="#fn:29"><sup>29</sup></a> The Race to the Bottom is also partly addressed by certificate authorities like <a href="/facts/Let%2527s_Encrypt/Phod5jG9">Let's Encrypt</a> that provide certificates free of charge.<a class="footnote-ref" id="fnref:30" href="#fn:30"><sup>30</sup></a> Let's Encrypt has also become the largest provider of certificates with over 500 million websites using it.<a class="footnote-ref" id="fnref:31" href="#fn:31"><sup>31</sup></a><a class="footnote-ref" id="fnref:32" href="#fn:32"><sup>32</sup></a></li> <li>Certification authorities attempt to deny almost all warranties to the user and relying parties in their <a href="/facts/Certification_Practice_Statement/UguLdd2g">Certification Practice Statement (CPS)</a>. For example, <a href="/facts/Apple_Inc/oTJYta3k">Apple Inc</a> states in their CPS, "To the extent permitted by applicable law, Subscriber agreements, if applicable, disclaim warranties from Apple, including any warranty of merchantability or fitness for a particular purpose".<a class="footnote-ref" id="fnref:33" href="#fn:33"><sup>33</sup></a></li> <li>According to Peter Gutmann, "Users use an undefined certification request protocol to obtain a certificate which is published in an unclear location in a nonexistent directory with no real means to revoke it"<a class="footnote-ref" id="fnref:34" href="#fn:34"><sup>34</sup></a></li> <li>Like all businesses, CAs are subject to the legal jurisdictions they operate within, and may be legally compelled to compromise the interests of their customers and their users. Intelligence agencies have also made use of false certificates issued through extralegal compromise of CAs, such as <a href="/facts/DigiNotar/sEfuU7M4">DigiNotar</a>, to carry out <a href="/facts/Man-in-the-middle_attack/dx4cojdz">man-in-the-middle attacks</a>. Another example is a revocation request of the CA of the Dutch government, because of a Dutch law passed in 2018, giving new powers for the Dutch intelligence and security services<a class="footnote-ref" id="fnref:35" href="#fn:35"><sup>35</sup></a></li></ul> <h3>Implementation issues</h3> <p>Implementations suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of different standards. Some problems are: </p> <ul><li>Many implementations turn off revocation check: <ul><li>Seen as obstacle, policies are not enforced</li> <li>If it was turned on in all browsers by default, including code signing, it would probably crash the infrastructure</li></ul></li> <li>DNs are complex and little understood (lack of canonicalization, internationalization problems)</li> <li>rfc822Name has two notations</li> <li>Name and policy constraints hardly supported</li> <li>Key usage ignored, first certificate in a list being used</li> <li>Enforcement of custom OIDs is difficult</li> <li>Attributes should not be made critical because it makes clients crash</li> <li>Unspecified length of attributes lead to product-specific limits</li> <li>There are implementation errors with X.509 that allow e.g. falsified subject names using null-terminated strings<a class="footnote-ref" id="fnref:36" href="#fn:36"><sup>36</sup></a> or code injection attacks in certificates</li> <li>By using illegal<a class="footnote-ref" id="fnref:37" href="#fn:37"><sup>37</sup></a> 0x80 padded subidentifiers of <a href="/facts/Object_identifier/wEC9ubWd">object identifiers</a>, wrong implementations or by using integer overflows of the client's browsers, an attacker can include an unknown attribute in the CSR, which the CA will sign, which the client wrongly interprets as "CN" (OID=2.5.4.3). Dan Kaminsky demonstrated this at the 26th <a href="/facts/Chaos_Communication_Congress/N7wXXSxh">Chaos Communication Congress</a> "Black OPs of PKI"<a class="footnote-ref" id="fnref:38" href="#fn:38"><sup>38</sup></a></li></ul> <h3>Cryptographic weaknesses</h3> <p>Digital signature systems depend on secure <a href="/facts/Cryptographic_hash_function/cuxkgbST">cryptographic hash functions</a> 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 <a href="/facts/Collision_resistance/8eBxsuHe">hash collision</a>, 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. </p> <ul><li><a href="/facts/MD2_(hash_function)/eycTYeaf">MD2</a>-based certificates were used for a long time and were vulnerable to <a href="/facts/Preimage_attack/dDktzjys">preimage attacks</a>. Since the root certificate already had a self-signature, attackers could use this signature and use it for an intermediate certificate.</li> <li>In 2005, <a href="/facts/Arjen_Lenstra/GG04Nhd9">Arjen Lenstra</a> 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 <a href="/facts/Collision_attack/6aXFAMbW">collision attack</a> on the <a href="/facts/MD5/8WIXb9Dq">MD5</a> hash function.<a class="footnote-ref" id="fnref:39" href="#fn:39"><sup>39</sup></a></li> <li>In 2008, <a href="/facts/Alexander_Sotirov/6a1nnW2G">Alexander Sotirov</a> and Marc Stevens presented at the <a href="/facts/Chaos_Communication_Congress/N7wXXSxh">Chaos Communication Congress</a> 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.<a class="footnote-ref" id="fnref:40" href="#fn:40"><sup>40</sup></a></li> <li>In April 2009 at the Eurocrypt Conference,<a class="footnote-ref" id="fnref:41" href="#fn:41"><sup>41</sup></a> Australian Researchers of Macquarie University presented "Automatic Differential Path Searching for <a href="/facts/SHA-1/LDYCV1je">SHA-1</a>".<a class="footnote-ref" id="fnref:42" href="#fn:42"><sup>42</sup></a> The researchers were able to deduce a method which increases the likelihood of a collision by several orders of magnitude.<a class="footnote-ref" id="fnref:43" href="#fn:43"><sup>43</sup></a></li> <li>In February 2017, a group of researchers led by Marc Stevens produced a SHA-1 collision, demonstrating SHA-1's weakness.<a class="footnote-ref" id="fnref:44" href="#fn:44"><sup>44</sup></a></li></ul> <h4>Mitigations for cryptographic weaknesses</h4> <p>Exploiting a hash collision to forge X.509 signatures requires that the attacker be able to predict the data that the certificate authority will sign. This can be somewhat mitigated by the CA generating a random component in the certificates it signs, typically the serial number. The <a href="/facts/CA%2fBrowser_Forum/JC00DSD0">CA/Browser Forum</a> has required serial number entropy in its Baseline Requirements Section 7.1 since 2011.<a class="footnote-ref" id="fnref:45" href="#fn:45"><sup>45</sup></a> </p><p>As of January 1, 2016, the Baseline Requirements forbid issuance of certificates using SHA-1. As of early 2017, Chrome<a class="footnote-ref" id="fnref:46" href="#fn:46"><sup>46</sup></a> and Firefox<a class="footnote-ref" id="fnref:47" href="#fn:47"><sup>47</sup></a> reject certificates that use SHA-1. As of May 2017 both Edge<a class="footnote-ref" id="fnref:48" href="#fn:48"><sup>48</sup></a> and Safari<a class="footnote-ref" id="fnref:49" href="#fn:49"><sup>49</sup></a> are also rejecting SHA-1 certificate. OpenSSL began rejecting SHA-1 certificates by default in version 3.0, released September 2021.<a class="footnote-ref" id="fnref:50" href="#fn:50"><sup>50</sup></a> </p> <h2 id="pki-standards-for-x509">PKI standards for X.509</h2> <ul><li><a href="/facts/PKCS7/M0swhEyc">PKCS7</a> (Cryptographic Message Syntax Standard — public keys with proof of identity for signed and/or encrypted message for PKI)<a class="footnote-ref" id="fnref:51" href="#fn:51"><sup>51</sup></a></li> <li><a href="/facts/Transport_Layer_Security/pGy16TnA">Transport Layer Security</a> (TLS) and its predecessor SSL — cryptographic protocols for Internet secure communications.<a class="footnote-ref" id="fnref:52" href="#fn:52"><sup>52</sup></a></li> <li><a href="/facts/Online_Certificate_Status_Protocol/0SuMER8c">Online Certificate Status Protocol</a> (OCSP)<a class="footnote-ref" id="fnref:53" href="#fn:53"><sup>53</sup></a> / certificate <a href="/facts/Revocation_list/JSP12aR0">revocation list</a> (CRL)<a class="footnote-ref" id="fnref:54" href="#fn:54"><sup>54</sup></a> — this is to check certificate revocation status</li> <li><a href="/facts/PKCS12/PLwhjewk">PKCS12</a> (Personal Information Exchange Syntax Standard) — used to store a private key with the appropriate public key certificate<a class="footnote-ref" id="fnref:55" href="#fn:55"><sup>55</sup></a></li> <li><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc4158">4158</a> — Certification Path Building — guidance and recommendations for building X.509 public-key certification paths within applications (i.e., validating an end-entity certificate using a CA certificate)</li></ul> <h2 id="pkix-working-group">PKIX Working Group</h2> <p>In 1995, the <a href="/facts/Internet_Engineering_Task_Force/tIcCsFhX">Internet Engineering Task Force</a> in conjunction with the <a href="/facts/National_Institute_of_Standards_and_Technology/gr9Fnh85">National Institute of Standards and Technology</a><a class="footnote-ref" id="fnref:56" href="#fn:56"><sup>56</sup></a> formed the Public-Key Infrastructure (X.509) working group. The working group, concluded in June 2014,<a class="footnote-ref" id="fnref:57" href="#fn:57"><sup>57</sup></a> is commonly referred to as "PKIX." It produced <a href="/facts/Request_for_Comments/esftTvE7">RFCs</a> and other standards documentation on using and deploying X.509 in practice. In particular it produced <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc3280">3280</a> and its successor RFC 5280, which define how to use X.509 in Internet protocols. </p> <h2 id="major-protocols-and-standards-using-x509-certificates">Major protocols and standards using X.509 certificates</h2> <p><a href="/facts/Transport_Layer_Security/pGy16TnA">TLS/SSL</a> and <a href="/facts/HTTPS/MSWYz4zo">HTTPS</a> use the <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a> profile of X.509, as do <a href="/facts/S%2fMIME/YufdsBt3">S/MIME</a> (Secure Multipurpose Internet Mail Extensions) and the <a href="/facts/EAP-TLS/yuCAFHxC">EAP-TLS</a> method for WiFi authentication. Any protocol that uses TLS, such as SMTP, POP, IMAP, LDAP, XMPP, and many more, inherently uses X.509. </p><p><a href="/facts/IPsec/01MwcET1">IPsec</a> can use the <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc4945">4945</a> profile for authenticating peers. </p><p>The <a href="https://apps.cablelabs.com/specification/opencable-security-specification">OpenCable security specification</a> defines its own profile of X.509 for use in the cable industry. </p><p>Devices like <a href="/facts/Smart_card/K7b9lowS">smart cards</a> and <a href="/facts/Trusted_Platform_Module/3XHCGYkX">TPMs</a> often carry certificates to identify themselves or their owners. These certificates are in X.509 form. </p><p>The <a href="/facts/WS-Security/T7v5kCJt">WS-Security</a> standard defines authentication either through TLS or through its own certificate profile.<a class="footnote-ref" id="fnref:58" href="#fn:58"><sup>58</sup></a> Both methods use X.509. </p><p>The <a href="/facts/Authenticode/xnLHJYRa">Microsoft Authenticode</a> code signing system uses X.509 to identify authors of computer programs. <a href="/facts/UEFI/w86VGmy2">Secure Boot</a> feature of <a href="/facts/UEFI/w86VGmy2">UEFI</a> uses X.509 to authenticate UEFI drivers or bootloaders during <a href="/facts/Booting/j6N1kRpc">booting</a> and disallow blocklisted drivers or bootloaders (by using Forbidden Key Exchange or dbx database).<a class="footnote-ref" id="fnref:59" href="#fn:59"><sup>59</sup></a> </p><p>The <a href="/facts/OPC_UA/DX40Sh4D">OPC UA</a> industrial automation communication standard uses X.509. </p><p><a href="/facts/Secure_Shell/wjVRw5zv">SSH</a> generally uses a <a href="/facts/Trust_on_first_use/lebMYQDf">Trust On First Use</a> security model and doesn't have need for certificates. However, the popular OpenSSH implementation does support a CA-signed identity model based on its own non-X.509 certificate format.<a class="footnote-ref" id="fnref:60" href="#fn:60"><sup>60</sup></a> </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Abstract_Syntax_Notation_One/ryUN7doc">Abstract Syntax Notation One</a></li> <li><a href="/facts/Certificate_policy/BJLwFJoz">Certificate policy</a></li> <li><a href="/facts/Code_Access_Security/o9B6J7jX">Code Access Security</a></li> <li><a href="/facts/Communications_security/tp0Q3jHp">Communications security</a></li> <li><a href="/facts/Information_security/horlrCln">Information security</a></li> <li><a href="/facts/ISO%2fIEC_JTC_1/hh9xdNtz">ISO/IEC JTC 1</a></li> <li><a href="/facts/PKI_Resource_Query_Protocol/eLYG1w9r">PKI Resource Query Protocol</a></li> <li><a href="/facts/Public-key_cryptography/gowoFTxS">Public-key cryptography</a></li> <li><a href="/facts/Public_Key_Infrastructure/7fwMLxF4">Public Key Infrastructure</a></li> <li><a href="/facts/Time_stamp_protocol/y1kJu2nD">Time stamp protocol</a></li> <li><a href="/facts/Trusted_timestamping/eRjuYGTM">Trusted timestamping</a></li> <li><a href="/facts/EdDSA/IbTRBhK3">EdDSA</a></li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="https://www.itu.int/rec/T-REC-X.509/en">ITU-T's X.509 standards</a></li> <li>Peter Gutmann's articles: <ul><li><a href="https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf">Overview of PKI</a></li> <li><a href="https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt">X.509 implementation notes and style guide</a></li></ul></li> <li><a href="https://web.archive.org/web/20061230232250/http://www.rsasecurity.com/rsalabs/node.asp?id=2155">"Crypto FAQ from RSA Labs"</a>. RSA Laboratories. Archived from <a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2155">the original</a> on 30 December 2006.</li> <li><a href="http://java.sun.com/security/seccodeguide.html">Secure code guidelines</a> Sun</li> <li>RFC <a href="https://www.rfc-editor.org/rfc/rfc4158">4158</a> - Internet X.509 Public Key Infrastructure: Certification Path Building</li> <li>RFC <a href="https://www.rfc-editor.org/rfc/rfc5280">5280</a> - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</li> <li><a href="https://technet.microsoft.com/en-us/library/bb123848(v=exchg.65).aspx">Understanding Digital Certificates</a> Microsoft TechNet</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>"X.509: Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks". ITU. Retrieved 6 November 2019. <a href="https://www.itu.int/rec/T-REC-X.509" target="_blank">https://www.itu.int/rec/T-REC-X.509</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Hesse, Peter; Cooper, Matt; Dzambasow, Yuriy A.; Joseph, Susan; Nicholas, Richard (September 2005). Internet X.509 Public Key Infrastructure: Certification Path Building. Network Working Group. doi:10.17487/RFC4158. RFC 4158. Informational. <a href="https://datatracker.ietf.org/doc/html/rfc4158" target="_blank">https://datatracker.ietf.org/doc/html/rfc4158</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>"Monumental Cybersecurity Blunders". circleid.com. Retrieved 2022-09-03. <a href="https://circleid.com/posts/20220513-monumental-cybersecurity-blunders" target="_blank">https://circleid.com/posts/20220513-monumental-cybersecurity-blunders</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Hesse, Peter; Cooper, Matt; Dzambasow, Yuriy A.; Joseph, Susan; Nicholas, Richard (September 2005). Internet X.509 Public Key Infrastructure: Certification Path Building. Network Working Group. doi:10.17487/RFC4158. RFC 4158. Informational. <a href="https://datatracker.ietf.org/doc/html/rfc4158" target="_blank">https://datatracker.ietf.org/doc/html/rfc4158</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Gutmann, Peter (April 2014). "Engineering Security" (PDF). <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Gutmann, Peter (April 2014). "Engineering Security" (PDF). <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>"CA:IncludedCAs". Mozilla Wiki. Retrieved 17 January 2017. <a href="https://wiki.mozilla.org/CA:IncludedCAs" target="_blank">https://wiki.mozilla.org/CA:IncludedCAs</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>"Bug 110161 - (ocspdefault) enable OCSP by default". Mozilla. Retrieved 17 March 2016. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=110161" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=110161</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>Nelson B Boyard (9 May 2002). "All About Certificate Extensions". Mozilla. Archived from the original on 15 December 2018. Retrieved 10 September 2020. <a href="https://web.archive.org/web/20181215123125/https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3" target="_blank">https://web.archive.org/web/20181215123125/https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>Gutmann, Peter (April 2014). "Engineering Security" (PDF). <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>sysadmin1138 (May 19, 2009). "What is a Pem file and how does it differ from other OpenSSL Generated Key File Formats?". Server Fault. Retrieved 19 October 2023.{{cite web}}: CS1 maint: numeric names: authors list (link) This article incorporates text from this source, which is available under the CC BY-SA 2.5 license. <a href="https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file" target="_blank">https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>Lloyd, Steve (September 2002). Understanding Certification Path Construction (PDF). PKI Forum. <a href="http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf" target="_blank">http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>"Cross-Certification Between Root CAs". Qualified Subordination Deployment Scenarios. Microsoft. August 2009. <a href="https://technet.microsoft.com/en-us/library/cc785267(v=ws.10).aspx" target="_blank">https://technet.microsoft.com/en-us/library/cc785267(v=ws.10).aspx</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>Nash; Duane; Joseph; Brink (2001). "Key and Certificate Life Cycles. CA Certificate Renewal". PKI: Implementing and Managing E-Security. RSA Press - Osborne/McGraw-Hill. ISBN 0-07-213123-3. <a href="0-07-213123-3" target="_blank">0-07-213123-3</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>"Web Services Security X.509 Token Profile Version 1.1.1". Oasis. Retrieved 14 March 2017. <a href="https://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-x509TokenProfile-v1.1.1-os.html" target="_blank">https://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-x509TokenProfile-v1.1.1-os.html</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>Carl Ellison and Bruce Schneier. "Top 10 PKI risks" (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). Archived from the original (PDF) on 2015-11-24. Retrieved 2014-04-02. <a href="https://web.archive.org/web/20151124191828/https://www.schneier.com/paper-pki.pdf" target="_blank">https://web.archive.org/web/20151124191828/https://www.schneier.com/paper-pki.pdf</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>Peter Gutmann. "PKI: it's not dead, just resting" (PDF). IEEE Computer (Volume:35, Issue: 8). <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> <li id="fn:24"><p>Gutmann, Peter. "Everything you Never Wanted to Know about PKI but were Forced to Find Out" (PDF). Retrieved 14 November 2011. <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></p></li> <li id="fn:25"><p>Langley, Adam (5 February 2012). "Revocation checking and Chrome's CRL". Imperial Violet. Retrieved 2 February 2017. <a href="https://www.imperialviolet.org/2012/02/05/crlsets.html" target="_blank">https://www.imperialviolet.org/2012/02/05/crlsets.html</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></p></li> <li id="fn:26"><p>"Security Systems Business Plan Sample [2021]". OGScapital. 2014-01-27. Retrieved 2021-06-30. <a href="https://www.ogscapital.com/article/securing-the-business-plan-for-the-security-systems-business/" target="_blank">https://www.ogscapital.com/article/securing-the-business-plan-for-the-security-systems-business/</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></p></li> <li id="fn:27"><p>Michael Zusman; Alexander Sotirov (July 2009). "Sub-Prime PKI: Attacking Extended Validation SSL" (PDF). Blackhat. Retrieved 10 September 2020. <a href="https://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL-PAPER.pdf" target="_blank">https://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL-PAPER.pdf</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></p></li> <li id="fn:28"><p>Hunt, Troy (17 September 2018). "Extended Validation Certificates are Dead". TroyHunt.com. Retrieved 26 February 2019. <a href="https://www.troyhunt.com/extended-validation-certificates-are-dead/" target="_blank">https://www.troyhunt.com/extended-validation-certificates-are-dead/</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></p></li> <li id="fn:29"><p>Gutmann, Peter (April 2014). "Engineering Security" (PDF). <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></p></li> <li id="fn:30"><p>"Let's Encrypt". Let's Encrypt. 2023-07-10. Retrieved 2025-04-08. <a href="https://letsencrypt.org/" target="_blank">https://letsencrypt.org/</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></p></li> <li id="fn:31"><p>"For A Better Internet - ISRG 2020 Annual Report" (PDF). Internet Security Research Group. 2020-11-17. Retrieved 2021-05-11. <a href="https://www.abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf" target="_blank">https://www.abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></p></li> <li id="fn:32"><p>"Let's Encrypt Stats". Let's Encrypt. 2023-07-10. Retrieved 2025-04-08. <a href="https://letsencrypt.org/stats/" target="_blank">https://letsencrypt.org/stats/</a> <a href="#fnref:32" class="footnote-back-ref">↩</a></p></li> <li id="fn:33"><p>"Certification Authority — Certification Practice Statement" (PDF). Version 6.1. Apple, Inc. August 19, 2016. <a href="https://www.apple.com/certificateauthority/pdf/Apple_AAI_CPS_v6.1.pdf" target="_blank">https://www.apple.com/certificateauthority/pdf/Apple_AAI_CPS_v6.1.pdf</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></p></li> <li id="fn:34"><p>Gutmann, Peter. "Everything you Never Wanted to Know about PKI but were Forced to Find Out" (PDF). Retrieved 14 November 2011. <a href="/wiki/Peter_Gutmann_(computer_scientist)" target="_blank">/wiki/Peter_Gutmann_(computer_scientist)</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></p></li> <li id="fn:35"><p>van Pelt, Cris. "Logius: Dutch Government CA trust issue". Bugzilla. Retrieved 31 October 2017. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1408647" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1408647</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></p></li> <li id="fn:36"><p>Moxie Marlinspike (2009). "More Tricks for Defeating SSL in Practice" (PDF). Institute For Disruptive Studies. Blackhat. Retrieved 10 September 2020. <a href="https://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf" target="_blank">https://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf</a> <a href="#fnref:36" class="footnote-back-ref">↩</a></p></li> <li id="fn:37"><p>Rec. ITU-T X.690, clause 8.19.2 <a href="#fnref:37" class="footnote-back-ref">↩</a></p></li> <li id="fn:38"><p>Dan Kaminsky (29 December 2009). "26C3: Black Ops Of PKI". CCC Events Blog. Der Chaos Computer Club. Retrieved 29 September 2013. <a href="https://events.ccc.de/congress/2009/Fahrplan/events/3658.en.html" target="_blank">https://events.ccc.de/congress/2009/Fahrplan/events/3658.en.html</a> <a href="#fnref:38" class="footnote-back-ref">↩</a></p></li> <li id="fn:39"><p>Lenstra, Arjen; de Weger, Benne (19 May 2005). On the possibility of constructing meaningful hash collisions for public keys (PDF) (Technical report). Lucent Technologies, Bell Laboratories & Technische Universiteit Eindhoven. Archived (PDF) from the original on 14 May 2013. Retrieved 28 September 2013. <a href="http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf" target="_blank">http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf</a> <a href="#fnref:39" class="footnote-back-ref">↩</a></p></li> <li id="fn:40"><p>"MD5 considered harmful today". Eindhoven University of Technology. 16 June 2011. Retrieved 29 September 2013. <a href="http://www.win.tue.nl/hashclash/rogue-ca/" target="_blank">http://www.win.tue.nl/hashclash/rogue-ca/</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></p></li> <li id="fn:41"><p>"Eurocrypt 2009". International Association for Cryptologic Research. <a href="https://www.iacr.org/conferences/eurocrypt2009/" target="_blank">https://www.iacr.org/conferences/eurocrypt2009/</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></p></li> <li id="fn:42"><p>Cameron McDonald; Philip Hawkes; Josef Pieprzyk (2009). "SHA-1 collisions now" (PDF). Macquarie University and Qualcomm. Retrieved 10 September 2020. <a href="http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf" target="_blank">http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf</a> <a href="#fnref:42" class="footnote-back-ref">↩</a></p></li> <li id="fn:43"><p>Dennis Dwyer (2 June 2009). "SHA-1 Collision Attacks Now 252". SecureWorks Insights. Retrieved 24 February 2016. <a href="https://www.secureworks.com/blog/research-20935" target="_blank">https://www.secureworks.com/blog/research-20935</a> <a href="#fnref:43" class="footnote-back-ref">↩</a></p></li> <li id="fn:44"><p>Marc Stevens; Elie Bursztein; Pierre Karpman; Ange Albertini; Yarik Markov. "The first collision for full SHA-1" (PDF). CWI Amsterdam & Google Research. Retrieved 10 September 2020 – via Shattered. <a href="https://shattered.io/static/shattered.pdf" target="_blank">https://shattered.io/static/shattered.pdf</a> <a href="#fnref:44" class="footnote-back-ref">↩</a></p></li> <li id="fn:45"><p>"Baseline Requirements Documents". CA Browser Forum. Retrieved 19 March 2017. <a href="https://cabforum.org/baseline-requirements-documents/" target="_blank">https://cabforum.org/baseline-requirements-documents/</a> <a href="#fnref:45" class="footnote-back-ref">↩</a></p></li> <li id="fn:46"><p>Andrew Whalley (16 November 2016). "SHA-1 Certificates in Chrome". Google Online Security Blog. Retrieved 19 March 2017. <a href="https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html" target="_blank">https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html</a> <a href="#fnref:46" class="footnote-back-ref">↩</a></p></li> <li id="fn:47"><p>"The end of SHA-1 on the Public Web". Mozilla Security Blog. 23 February 2017. Retrieved 19 March 2017. <a href="https://blog.mozilla.org/security/2017/02/23/the-end-of-sha-1-on-the-public-web/" target="_blank">https://blog.mozilla.org/security/2017/02/23/the-end-of-sha-1-on-the-public-web/</a> <a href="#fnref:47" class="footnote-back-ref">↩</a></p></li> <li id="fn:48"><p>"Microsoft Security Advisory 4010323". Technet. Microsoft. Retrieved 16 May 2017. <a href="https://technet.microsoft.com/en-us/library/security/4010323.aspx" target="_blank">https://technet.microsoft.com/en-us/library/security/4010323.aspx</a> <a href="#fnref:48" class="footnote-back-ref">↩</a></p></li> <li id="fn:49"><p>"Safari and WebKit do not support SHA-1 certificates". Apple Support. 16 August 2018. Retrieved 10 September 2020. <a href="https://support.apple.com/en-us/HT207459" target="_blank">https://support.apple.com/en-us/HT207459</a> <a href="#fnref:49" class="footnote-back-ref">↩</a></p></li> <li id="fn:50"><p>"openssl/NEWS.md at master · openssl/openssl". GitHub. Retrieved 2025-02-16. <a href="https://github.com/openssl/openssl/blob/master/NEWS.md#major-changes-between-openssl-111-and-openssl-300-7-sep-2021" target="_blank">https://github.com/openssl/openssl/blob/master/NEWS.md#major-changes-between-openssl-111-and-openssl-300-7-sep-2021</a> <a href="#fnref:50" class="footnote-back-ref">↩</a></p></li> <li id="fn:51"><p>B. Kaliski (March 1998). PKCS #7: Cryptographic Message Syntax Version 1.5. Network Working Group. doi:10.17487/RFC2315. RFC 2315. Informational. <a href="https://datatracker.ietf.org/doc/html/rfc2315" target="_blank">https://datatracker.ietf.org/doc/html/rfc2315</a> <a href="#fnref:51" class="footnote-back-ref">↩</a></p></li> <li id="fn:52"><p>T. Dierks; E. Rescorla (August 2008). The Transport Layer Security (TLS) Protocol Version 1.2. IETF TLS workgroup. doi:10.17487/RFC5246. RFC 5246. Obsolete. Obsoleted by RFC 8446. Obsoletes RFC 3268, 4346 and 4366; updates RFC 4492. <a href="https://datatracker.ietf.org/doc/html/rfc5246" target="_blank">https://datatracker.ietf.org/doc/html/rfc5246</a> <a href="#fnref:52" class="footnote-back-ref">↩</a></p></li> <li id="fn:53"><p>S. Santesson; M. Myers; R. Ankey; S. Galperin; C. Adams (June 2013). X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Internet Engineering Task Force. doi:10.17487/RFC6960. RFC 6960. Proposed Standard. Updated by RFC 8954. Obsoletes RFC 6277 and 2560. Updates RFC 5912. <a href="/wiki/Carlisle_Adams" target="_blank">/wiki/Carlisle_Adams</a> <a href="#fnref:53" class="footnote-back-ref">↩</a></p></li> <li id="fn:54"><p>Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (May 2008). Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. doi:10.17487/RFC5280. RFC 5280. Proposed Standard. Updated by RFC 9549, 9598, 8398, 8399 and 6818. Obsoletes RFC 4630, 4325 and 3280. <a href="https://datatracker.ietf.org/doc/html/rfc5280" target="_blank">https://datatracker.ietf.org/doc/html/rfc5280</a> <a href="#fnref:54" class="footnote-back-ref">↩</a></p></li> <li id="fn:55"><p>"PKCS 12: Personal Information Exchange Syntax Standard". EMC.com. RSA Laboratories. Archived from the original on 6 July 2017. Retrieved 19 March 2017. <a href="https://web.archive.org/web/20170706095929/https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs12-personal-information-exchange-syntax-standard.htm" target="_blank">https://web.archive.org/web/20170706095929/https://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs12-personal-information-exchange-syntax-standard.htm</a> <a href="#fnref:55" class="footnote-back-ref">↩</a></p></li> <li id="fn:56"><p>"Public-Key Infrastructure (X.509) (pkix) - Charter". IETF Datatracker. Internet Engineering Task Force. Retrieved 1 October 2013. <a href="https://datatracker.ietf.org/wg/pkix/charter/" target="_blank">https://datatracker.ietf.org/wg/pkix/charter/</a> <a href="#fnref:56" class="footnote-back-ref">↩</a></p></li> <li id="fn:57"><p>"Pkix Status Pages". IETF Tools. Retrieved 10 March 2017. <a href="https://tools.ietf.org/wg/pkix/" target="_blank">https://tools.ietf.org/wg/pkix/</a> <a href="#fnref:57" class="footnote-back-ref">↩</a></p></li> <li id="fn:58"><p>"Web Services Security X.509 Token Profile Version 1.1.1". Oasis. Retrieved 14 March 2017. <a href="https://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-x509TokenProfile-v1.1.1-os.html" target="_blank">https://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-x509TokenProfile-v1.1.1-os.html</a> <a href="#fnref:58" class="footnote-back-ref">↩</a></p></li> <li id="fn:59"><p>Smith, Roderick W. (2012-11-04). "Managing EFI Boot Loaders for Linux: Controlling Secure Boot (Managing Keys from Linux)". Roderick W. Smith's Web Page. Retrieved 2025-02-20. <a href="https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#linux" target="_blank">https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#linux</a> <a href="#fnref:59" class="footnote-back-ref">↩</a></p></li> <li id="fn:60"><p>"How To Create an SSH CA to Validate Hosts and Clients with Ubuntu". DigitalOcean. Retrieved 19 March 2017. <a href="https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu" target="_blank">https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu</a> <a href="#fnref:60" class="footnote-back-ref">↩</a></p></li> </ol>