Editing X.509 (section)

==Certificates==
{{Infobox file format
|name = X.509 certificate
|mime = application/pkix-cert{{Ref RFC|2585|section=4: MIME registrations |pages=4–5 }}
|uniform type = public.x509-certificate<ref>{{cite web |url=https://developer.apple.com/documentation/uniformtypeidentifiers/uttype/3551600-x509certificate |title=x509Certificate |work=Apple Developer Documentation: Uniform Type Identifiers |publisher=[[Apple Inc]]}}</ref>
}}
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|Certificate Signing Request (CSR)]], [[Simple_Certificate_Enrollment_Protocol|Simple Certificate Enrollment Protocol (SCEP)]] or [[Certificate_Management_Protocol|Certificate Management Protocol (CMP)]]. The organization first generates a [[key pair]], keeping the [[Private-key cryptography|private key]] secret and using it to sign the CSR. The CSR contains information identifying the applicant and the applicant's [[public-key cryptography|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#Directory structure|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 certificate]]s can be distributed to all employees so that they can use the company PKI system. Browsers such as [[Internet Explorer]], [[Firefox]], [[Opera (web browser)|Opera]], [[Safari (web browser)|Safari]] and [[Google Chrome|Chrome]] come with a predetermined set of root certificates pre-installed, so [[Secure Sockets Layer|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.<ref>{{Cite web|url=https://wiki.mozilla.org/CA:IncludedCAs|title=CA:IncludedCAs|work=Mozilla Wiki|access-date=17 January 2017}}</ref>

X.509 and  {{IETF RFC|5280}} 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 [[Microsoft Windows|Windows]] from at least [[Windows Vista|Vista]] and later.<ref>{{cite web |url=https://bugzilla.mozilla.org/show_bug.cgi?id=110161 | title=Bug 110161 - (ocspdefault) enable OCSP by default |access-date=17 March 2016|publisher=Mozilla}}</ref>

===Structure of a certificate===
The structure foreseen by the standards is expressed in a formal language, [[Abstract Syntax Notation One]] (ASN.1).

The structure of an X.509 v3 [[digital certificate]] is as follows:
* Certificate
**Version Number
**Serial Number
**Signature Algorithm ID
**Issuer Name
**Validity period
***Not Before
***Not After
**Subject name
**Subject Public Key Info
***Public Key Algorithm
***Subject Public Key
**Issuer Unique Identifier (optional)
**Subject Unique Identifier (optional)
**Extensions (optional)
*** ...
*Certificate Signature Algorithm
*Certificate Signature

The Extensions field, if present, is a sequence of one or more certificate extensions.{{Ref RFC|5280|rsection=4.1.2.9: Extensions}} Each extension has its own unique ID, expressed as [[object_identifier|object identifier (OID)]], 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.{{Ref RFC|5280|rsection=4.2: Certificate Extensions}}

The structure of version 1 is given in {{IETF RFC|1422}}.

The inner format of issuer and subject unique identifiers specified in [https://www.itu.int/rec/T-REC-X.520 ''X.520 The Directory: Selected attribute types''] recommendation.

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 [[certificate authority|CA]] 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, [[IETF]] recommends that no issuer and subject names be reused. Therefore, version 2 is not widely deployed in the Internet.{{citation needed|date=January 2012}} 

Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for [[code signing|signing digital objects]]).

In all versions, the serial number must be unique for each certificate issued by a specific CA (as mentioned in {{IETF RFC|5280}}).

===Extensions informing a specific usage of a certificate===
{{IETF RFC|5280}} (and its predecessors) defines a number of certificate extensions which indicate how the certificate should be used. Most of them are arcs from the <code>joint-iso-ccitt(2) ds(5) id-ce(29)</code> OID. Some of the most common, defined in section 4.2.1, are:

* Basic Constraints, <code>{ id-ce 19 }</code>,{{Ref RFC|5280|rsection=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.
* Key Usage, <code>{ id-ce 15 }</code>,{{Ref RFC|5280|rsection=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.
* Extended Key Usage, <code>{ id-ce 37 }</code>,{{Ref RFC|5280|rsection=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, <code>{ id-pkix 3 1 }</code> indicates that the key may be used on the server end of a TLS or SSL connection; <code>{ id-pkix 3 4 }</code> indicates that the key may be used to secure email.

In general when using {{IETF RFC| 5280}}, if a certificate has several extensions restricting its use, all restrictions must be satisfied for a given use to be appropriate. The <nowiki>RFC</nowiki> 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, [[Network Security Services|NSS]] uses both extensions to specify certificate usage.<ref>{{cite web|url=https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3|title=All About Certificate Extensions|date=9 May 2002|publisher=Mozilla|access-date=10 September 2020|author=Nelson B Boyard|archive-date=15 December 2018|archive-url=https://web.archive.org/web/20181215123125/https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3|url-status=dead}}</ref>

===Extended Validation certificates===
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 <code>example.com</code> after someone responded to an email sent to <code>webmaster@example.com</code>. An EV certificate means a certificate was issued for a domain like <code>example.com</code>, and a company like Example, LLC is the owner of the domain, and the owner was verified by [[Articles_of_incorporation|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|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_(computer_scientist)|Peter Gutmann]] states CA's created EV certificates to restore profit levels after the [[Race_to_the_bottom|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.<ref name="gutmann_book" />

===Certificate filename extensions===
There are several commonly used [[filename extension]]s for X.509 certificates. Some of these extensions are also used for other data such as private keys.

* <code>.pem</code> – ([[Privacy-enhanced Electronic Mail]]) [[Base64]] encoded [[Distinguished Encoding Rules|DER]] certificate, enclosed between {{code|-----BEGIN CERTIFICATE-----}} and {{code|-----END CERTIFICATE-----}}
* <code>.cer</code>, <code>.crt</code>, <code>.der</code> – usually in binary [[Distinguished Encoding Rules|DER]] form, but Base64-encoded certificates are common too (see <code>.pem</code> above)
* <code>.p8</code>, <code>.p8e</code>, <code>.pk8</code> – exported private key as specified in [[PKCS8|PKCS#8]]. May be in DER or PEM form that starts with {{code|-----BEGIN PRIVATE KEY-----}}. The encrypted key starts with {{code|-----BEGIN ENCRYPTED PRIVATE KEY-----}} and may have the <code>.p8e</code> extension.
* <code>.p10</code>, <code>.csr</code> – [[PKCS10|PKCS#10]] a [[certificate signing request]] (CSR). In PEM form starts with {{code|-----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 ''public key'' of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public ''certificate'' (which includes the public key but not the private key), which itself can be in a couple of formats but usually in <code>.p7r</code>.<ref>{{cite web |author=sysadmin1138 |title=What is a Pem file and how does it differ from other OpenSSL Generated Key File Formats? |url=https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file |website=Server Fault |access-date=19 October 2023 |language=en |date=May 19, 2009}} {{Creative Commons text attribution notice|cc=bysa2.5|from this source=yes}}
</ref>
* <code>.p7r</code> – [[PKCS7|PKCS#7]] response to CSR. Contains the newly-signed certificate, and the CA's own cert.
* <code>.p7s</code> – [[PKCS7|PKCS#7]] Digital Signature. May contain the original signed file or message. Used in [[S/MIME]] for email signing. Defined in RFC 2311.
* <code>.p7m</code> – [[PKCS7|PKCS#7]] (SignedData, EnvelopedData) Message e.g. encrypted ("enveloped") file, message or MIME email letter. Defined in RFC 2311.
* <code>.p7c</code> – [[PKCS7|PKCS#7]] degenerated SignedData "certs-only" structure, without any data to sign. Defined in RFC 2311.
* <code>.p7b</code>, <code>.keystore</code> – [[PKCS7|PKCS#7]] SignedData structure without data, just certificate(s) bundle and/or [[revocation list|CRLs]] (rarely) but not a private key. Uses [[Distinguished Encoding Rules|DER]] form or [[X.690#BER_encoding|BER]] or PEM that starts with {{code|-----BEGIN PKCS7-----}}. The format used by Windows for certificate interchange. Supported by Java but often has <code>.keystore</code> as an extension instead. Unlike <code>.pem</code> style certificates, this format has a ''defined'' way to include certification-path certificates.
* <code>.p12</code>, <code>.pfx</code>, <code>.pkcs12</code> – [[PKCS12|PKCS#12]], may contain certificate(s) (public) and private keys (password protected) in a single file. <code>.pfx</code> – ''Personal Information eXchange'' PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g. with PFX files generated in [[Internet Information Services|IIS]]).
* <code>.crl</code> – A [[Certificate Revocation List]] (CRL). Certificate Authorities produce these as a way to de-authorize certificates before expiration.

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