Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks | |
Status | In force (Recommendation) |
---|---|
First published | 1.0 at November 25, 1988 |
Latest version | 9.1 October 14, 2021 |
Organization | ITU-T |
Committee | ITU-T Study Group 17 |
Series | X |
Base standards | ASN.1 |
Related standards | ISO/IEC 9594-8:2020, X.500 |
Domain | Cryptography |
Website | www |
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. [1] X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, [2] the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures. [3]
An X.509 certificate binds an identity to a public key using a digital signature. A certificate contains an identity (a hostname, or an organization, or an individual) and a public key (RSA, DSA, ECDSA, ed25519, etc.), and is either signed by a certificate authority or is self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can use the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.
X.509 also defines certificate revocation lists, which are a means to distribute information about certificates that have been deemed invalid by a signing authority, as well as a certification path validation algorithm, which allows for certificates to be signed by intermediate CA certificates, which are, in turn, signed by other certificates, eventually reaching a trust anchor.
X.509 is defined by the ITU's "Standardization Sector" (ITU-T's SG17), in ITU-T Study Group 17 and is based on Abstract Syntax Notation One (ASN.1), another ITU-T standard.
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. [2] It can be used in a peer-to-peer, OpenPGP-like web of trust,[ citation needed ] but was rarely used that way as of 2004 [update] . The X.500 system has only been implemented by sovereign nations[ which? ] 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 RFC 5280, commonly called PKIX for Public Key Infrastructure (X.509). [4]
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. [5]
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. [5]
Internet media type | application/pkix-cert [6] |
---|---|
Uniform Type Identifier (UTI) | public.x509-certificate [7] |
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. [8]
X.509 and 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 Windows from at least Vista and later. [9]
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:
The Extensions field, if present, is a sequence of one or more certificate extensions. [10] Each extension has its own unique ID, expressed as 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. [11]
The structure of version 1 is given in RFC 1422.
The inner format of issuer and subject unique identifiers specified in 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 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 ]
Extensions were introduced in version 3. A CA can use extensions to issue a certificate only for a specific purpose (e.g. only for signing digital objects).
In all versions, the serial number must be unique for each certificate issued by a specific CA (as mentioned in RFC 5280).
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 joint-iso-ccitt(2) ds(5) id-ce(29)
OID. Some of the most common, defined in section 4.2.1, are:
{ id-ce 19 }
, [12] 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.{ id-ce 15 }
, [13] 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.{ id-ce 37 }
, [14] 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.In general when using RFC 5280, 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, NSS uses both extensions to specify certificate usage. [15]
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. [5]
There are several commonly used filename extensions for X.509 certificates. Some of these extensions are also used for other data such as private keys.
.pem
– (Privacy-enhanced Electronic Mail) Base64 encoded DER certificate, enclosed between -----BEGIN CERTIFICATE-----
and -----END CERTIFICATE-----
.cer
, .crt
, .der
– usually in binary DER form, but Base64-encoded certificates are common too (see .pem
above).p8
, .p8e
, .pk8
– exported private key as specified in PKCS#8. 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..p10
, .csr
– PKCS#10 a Certificate Signing Request (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 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 .p7r
. [16] .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 -----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 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.
A certificate chain (see the equivalent concept of "certification path" defined by RFC 5280 section 3.2) is a list of certificates (usually starting with an end-entity certificate) followed by one or more CA certificates (usually the last one being a self-signed certificate), with the following properties:
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.
The description in the preceding paragraph is a simplified view on the certification path validation process as defined by RFC 5280 section 6, which involves additional checks, such as verifying validity dates on certificates, looking up CRLs, etc.
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. [17] See the following examples:
In these diagrams:
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. [18] 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".
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.
Understanding Certification Path Construction (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 self-signed. Note that these are in addition to the two self-signed certificates (one old, one new).
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. [19]
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 GlobalSign, 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 ECDSA public key, while the signature at the bottom was generated by GlobalSign's RSA private key. (The signatures in these examples are truncated.)
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:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2 X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Policy: 2.23.140.1.2.2 X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl 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: ...
To validate this end-entity certificate, one needs an intermediate certificate that matches its Issuer and Authority Key Identifier:
Issuer | C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 |
---|---|
Authority Key Identifier | 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C |
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.
This is an example of an intermediate certificate belonging to a certificate authority. 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.
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: https://www.globalsign.com/repository/ X509v3 CRL Distribution Points: Full Name: URI:http://crl.globalsign.net/root.crl Authority Information Access: OCSP - URI:http://ocsp.globalsign.com/rootr1 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: ...
This is an example of a self-signed root certificate representing a certificate authority. 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.
Certificate: [20] 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: ...
There are a number of publications about PKI problems by Bruce Schneier, Peter Gutmann and other security experts. [21] [22] [23]
Implementations suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of different standards. Some problems are:
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.
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 CA/Browser Forum has required serial number entropy in its Baseline Requirements Section 7.1 since 2011. [39]
As of January 1,2016 [update] , the Baseline Requirements forbid issuance of certificates using SHA-1. As of early 2017 [update] , Chrome [40] and Firefox [41] reject certificates that use SHA-1. As of May 2017 [update] both Edge [42] and Safari [43] are also rejecting SHA-1 certificate. Non-browser X.509 validators do not yet reject SHA-1 certificates. [44]
In 1995, the Internet Engineering Task Force in conjunction with the National Institute of Standards and Technology [50] formed the Public-Key Infrastructure (X.509) working group. The working group, concluded in June 2014, [51] is commonly referred to as "PKIX." It produced RFCs and other standards documentation on using and deploying X.509 in practice. In particular it produced RFC 3280 and its successor RFC 5280, which define how to use X.509 in Internet protocols.
TLS/SSL and HTTPS use the RFC 5280 profile of X.509, as do S/MIME (Secure Multipurpose Internet Mail Extensions) and the EAP-TLS method for WiFi authentication. Any protocol that uses TLS, such as SMTP, POP, IMAP, LDAP, XMPP, and many more, inherently uses X.509.
IPsec can use the RFC 4945 profile for authenticating peers.
The OpenCable security specification defines its own profile of X.509 for use in the cable industry.
Devices like smart cards and TPMs often carry certificates to identify themselves or their owners. These certificates are in X.509 form.
The WS-Security standard defines authentication either through TLS or through its own certificate profile. [20] Both methods use X.509.
The Microsoft Authenticode code signing system uses X.509 to identify authors of computer programs.
The OPC UA industrial automation communication standard uses X.509.
SSH generally uses a Trust On First Use 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. [52]
A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.
In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.
In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string. For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.
In cryptography, a certificate revocation list (CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted". CRLs are no longer required by the CA/Browser forum, as alternate certificate revocation technologies are increasingly used instead. Nevertheless, CRLs are still widely used by the CAs.
In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.
S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.
In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.
The certification path validation algorithm is the algorithm which verifies that a given certificate path is valid under a given public key infrastructure (PKI). A path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted certificate authority (CA).
The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.
Code signing is the process of digitally signing executables and scripts to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity. Code signing was invented in 1995 by Michael Doyle, as part of the Eolas WebWish browser plug-in, which enabled the use of public-key cryptography to sign downloadable Web app program code using a secret key, so the plug-in code interpreter could then use the corresponding public key to authenticate the code before allowing it access to the code interpreter's APIs.
Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.
The Server-based Certificate Validation Protocol (SCVP) is an Internet protocol for determining the path between an X.509 digital certificate and a trusted root and the validation of that path according to a particular validation policy.
The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.
In cryptography Privilege Management is the process of managing user authorisations based on the ITU-T Recommendation X.509. The 2001 edition of X.509 specifies most of the components of a Privilege Management Infrastructure (PMI), based on X.509 attribute certificates (ACs). Later editions of X.509 have added further components to the PMI, including a delegation service and interdomain authorisation.
An offline root certificate authority is a certificate authority which has been isolated from network access, and is often kept in a powered-down state.
A Public key certificate which uses an asterisk *
in its domain name fragment is called a Wildcard certificate. Through the use of *
, a single certificate may be used for multiple sub-domains. It is commonly used for transport layer security in computer networking.
DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).
Certificate Transparency (CT) is an Internet security standard for monitoring and auditing the issuance of digital certificates.
In public key infrastructure, a validation authority (VA) is an entity that provides a service used to verify the validity or revocation status of a digital certificate per the mechanisms described in the X.509 standard and RFC 5280.
DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.
Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications.
{{cite journal}}
: Cite journal requires |journal=
(help){{cite web}}
: CS1 maint: numeric names: authors list (link) This article incorporates textfrom this source, which is available under the CC BY-SA 2.5 license.