Professional Documents
Culture Documents
509
X.509
From Wikipedia, the free encyclopedia
In cryptography, X.509 is a standard that defines the format of public key certificates. X.509 certificates are used in many Internet protocols, including
TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They're also used in offline applications, like electronic signatures. An
X.509 certificate contains a public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-
signed. When a certificate is signed by a certificate authority, or validated by another means, someone holding that certificate can rely on the public key it
contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.
Besides the format for certificates themselves, X.509 specifies certificate revocation lists as a means to distribute information about certificates that are no
longer valid, and 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 International Telecommunications Union's Standardization sector (ITU-T), and is based on ASN.1, another ITU-T standard.
Contents
1 History and usage
2 Certificates
2.1 Structure of a certificate
2.2 Extensions informing a specific usage of a certificate
2.3 Certificate filename extensions
3 Certificate chains and cross-certification
3.1 Example 1: Cross-certification at root CA level between two PKIs
3.2 Example 2: CA certificate renewal
4 Sample X.509 certificates
4.1 End-entity certificate
4.2 Intermediate certificate
4.3 Root certificate
5 Security
5.1 Architectural weaknesses
5.2 Problems with certificate authorities
5.3 Implementation issues
5.4 Cryptographic weaknesses
5.4.1 Mitigations for cryptographic weaknesses
6 PKI standards for X.509
7 PKIX Working Group
8 Major protocols and standards using X.509 certificates
9 See also
10 References
11 External links
1 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
Certificates
In the X.509 system, an organization that wants a signed certificate requests one via a certificate signing request (CSR).
To do this, it first generates a key pair, keeping the private key secret and using it to sign the CSR. This 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 the certificate is for. The CSR may be
accompanied by other credentials or proofs of identity required by the certificate authority.
The certification authority issues a certificate binding a public key to a particular distinguished name.
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.[2]
X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI systems. The IETF-approved way of
checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default, as do versions of Windows
from at least Vista and later.[3]
Structure of a certificate
The structure foreseen by the standards is expressed in a formal language, Abstract Syntax Notation One (ASN.1).
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
Each extension has its own ID, expressed as object identifier, 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.[4]
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.
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).
2 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
In all versions, the serial number must be unique for each certificate issued by a specific CA (as mentioned in RFC 2459).
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:
Basic Constraints, { id-ce 19 },[6] are used to indicate whether the certificate belongs to a CA.
Key Usage, { id-ce 15 },[7] 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, { id-ce 37 },[8] 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, if a certificate has several extensions restricting its use, all restrictions must be satisfied for a given use to be appropriate. RFC 5280 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.[9]
There are several commonly used filename extensions for X.509 certificates. Unfortunately, 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)
.p7b, .p7c – PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
.p12 – PKCS#12, may contain certificate(s) (public) and private keys (password protected)
.pfx – PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)
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 .P7C file is a degenerated SignedData structure, without any data to sign.
PKCS#12 evolved from the personal information exchange (PFX) standard and is used to exchange public and private objects in a single file.
1. The Issuer of each certificate (except the last one) matches the Subject of the next certificate in the list.
2. Each certificate (except the last one) is supposed to be 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).
3. The last certificate in the list is a trust anchor: a certificate that you trust because it was delivered to you by some trustworthy procedure.
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,[10] 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 signing them 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
3 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
validly linked to more than one certificate building completely different certificate chains. This is
crucial for cross-certification between PKIs and other applications. [11] 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
Example 1: Cross-certification between two PKIs
generates a certificate (cert2.1) containing the public key of CA2. [12] 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.
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.[13]
End-entity certificate
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:
04: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:
ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:
4 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:
9d:3b:ef:d5:c1
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
Full Name:
URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl
To validate this end-entity certificate, one needs an intermediate certificate that matches its Issuer and Authority Key Identifier:
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.
Intermediate 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 subject.
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
5 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
Full Name:
URI:http://crl.globalsign.net/root.crl
Root certificate
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:
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:
...
Security
There are a number of publications about PKI problems by Bruce Schneier, Peter Gutmann and other security experts.[14][15][16]
Architectural weaknesses
6 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
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.
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.
Issuance of an Extended Validation (EV) certificate 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.[18]
The subject, not the relying party, purchases certificates. The subject will often utilize the cheapest issuer, so quality is not being paid for in the
competing market. This is partly addressed by Extended Validation certificates.
Certification authorities deny almost all warranties to the user (including subject or even relying parties).
The expiration date should be used to limit the time the key strength is deemed sufficient. This parameter is abused by certification authorities to charge
the client an extension fee. This places an unnecessary burden on the user with key roll-over.
"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." [16]
Like all businesses, CAs are subject to the legal jurisdiction(s) of their site(s) of operation, 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
DigiNotar, to carry out man-in-the-middle attacks.
Implementation issues
Implementations suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of different standards. Some problems are:
Cryptographic weaknesses
Digital signature systems depend on secure cryptographic hash functions to work. When a public key infrastructure allows the use of a hash function that is no
longer secure, an attacker can exploit weaknesses in the hash function to forge certificates. Specifically, if an attacker is able to produce a hash collision, they
can convince a CA to sign a certificate with innocuous contents, where the hash of those contents is identical to the hash of another, malicious set of certificate
contents, created by the attacker with values of their choosing. The attacker can then append the CA-provided signature to their malicious certificate contents,
resulting in a malicious certificate that appears to be signed by the CA. Because the malicious certificate contents are chosen solely by the attacker, they can
have different validity dates or hostnames than the innocuous certificate. The malicious certificate can even contain a "CA: true" field making it able to issue
further trusted certificates.
MD2-based certificates were used for a long time and were vulnerable to preimage attacks. Since the root certificate already had a self-signature,
attackers could use this signature and use it for an intermediate certificate.
In 2005, Arjen Lenstra and Benne de Weger demonstrated "how to use hash collisions to construct two X.509 certificates that contain identical
7 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
signatures and that differ only in the public keys", achieved using a collision attack on the MD5 hash function.[22]
In 2008, Alexander Sotirov and Marc Stevens presented at the Chaos Communication Congress a practical attack that allowed them to create a rogue
Certificate Authority, accepted by all common browsers, by exploiting the fact that RapidSSL was still issuing X.509 certificates based on MD5.[23]
In April 2009 at the Eurocrypt Conference,[24] Australian Researchers of Macquarie University presented "Automatic Differential Path Searching for
SHA-1".[25] The researchers were able to deduce a method which increases the likelihood of a collision by several orders of magnitude.[26]
In February 2017, a group of researchers produced a SHA-1 collision, demonstrating SHA-1's weakness.[27]
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.[28]
As of January 1, 2016, the Baseline Requirements forbid issuance of certificates using SHA-1. As of early 2017, Chrome[29] and Firefox[30] reject certificates
that use SHA-1. As of May 2017 both Edge[31] and Safari [32]are also rejecting SHA-1 certificate. Non-browser X.509 validators do not yet reject SHA-1
certificates.[33]
The OpenCable security specification (https://apps.cablelabs.com/specification/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.[41] Both methods use X.509.
The Microsoft Authenticode code signing system uses X.509 to identify authors of computer programs.
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.[42]
See also
Abstract Syntax Notation One
8 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
Certificate policy
Code Access Security
Communications security
Information security
ISO/IEC JTC 1
Public-key cryptography
Time stamp protocol
Trusted timestamping
References
1. RFC 4158 19. Marlinspike Blackhat 2009 (https://www.blackhat.com/presentations
2. "CA:IncludedCAs - MozillaWiki" (https://wiki.mozilla.org /bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-
/CA:IncludedCAs). wiki.mozilla.org. Retrieved 2017-01-17. SLIDES.pdf)
3. "Bug 110161 - (ocspdefault) enable OCSP by default" 20. Rec. ITU-T X.690, clause 8.19.2
(https://bugzilla.mozilla.org/show_bug.cgi?id=110161). Retrieved 21. "26C3: Black Ops Of PKI" (https://events.ccc.de/congress
2016-03-17. /2009/Fahrplan/events/3658.en.html). Events.ccc.de. Retrieved
4. RFC 5280 section 4.2, retrieved 12 February 2013 (http://tools.ietf.org 2013-09-29.
/html/rfc5280#section-4.2,) 22. Lenstra, Arjen; de Weger, Benne (2005-05-19). On the possibility of
5. RFC 1422 (http://www.ietf.org/rfc/rfc1422) constructing meaningful hash collisions for public keys
6. "RFC 5280, Section 'Basic Constraints' " (http://tools.ietf.org (http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf)
/html/rfc5280#section-4.2.1.9). (PDF) (Technical report). Murray Hill, NJ, USA & Eindhoven, The
7. " 'RFC 5280, Section 'Key Usage' " (http://tools.ietf.org Netherlands: Lucent Technologies, Bell Laboratories & Technische
/html/rfc5280#section-4.2.1.3). Universiteit Eindhoven. Archived (https://web.archive.org
8. "RFC 5280, Section 'Extended Key Usage' " (http://tools.ietf.org /web/20130514200135/http://www.win.tue.nl/~bdeweger
/html/rfc5280#section-4.2.1.12). /CollidingCertificates/ddl-full.pdf) (PDF) from the original on
9. All About Certificate Extensions (https://developer.mozilla.org/en- 2013-05-14. Retrieved 2013-09-28.
US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3) 23. "MD5 considered harmful today" (http://www.win.tue.nl/hashclash
10. "Certification Path Validation". Internet X.509 Public Key /rogue-ca/). Win.tue.nl. Retrieved 2013-09-29.
Infrastructure Certificate and Certificate Revocation List (CRL) Profile 24. Eurocrypt Conference (https://www.iacr.org/conferences
(http://tools.ietf.org/html/rfc5280#page-71). Network Working Group. /eurocrypt2009/)
2008. 25. "Automatic Differential Path Searching for SHA-1"
11. Lloyd, Steve (September 2002). Understanding Certification Path (http://eurocrypt2009rump.cr.yp.to
Construction (http://www.oasis-pki.org /837a0a8086fa6ca714249409ddfae43d.pdf)
/pdfs/Understanding_Path_construction-DS2.pdf) (PDF). PKI Forum. 26. Litke, Pat. "SHA-1 Collision Attacks Now 252"
12. "Cross-Certification Between Root CAs". Qualified Subordination (https://www.secureworks.com/blog/research-20935). SecureWorks.
Deployment Scenarios (http://technet.microsoft.com/en-us/library SecureWorks Insights. Retrieved 24 February 2016.
/cc785267(v=ws.10).aspx). Microsoft. August 2009. 27. "The first collision for full SHA-1" (https://shattered.io/static
13. Nash; Duane; Joseph; Brink (2001). "Key and Certificate Life Cycles. /shattered.pdf) (PDF).
CA Certificate Renewal". PKI: Implementing and Managing 28. "Baseline Requirements Documents - CAB Forum"
E-Security. RSA Press - Osborne/McGraw-Hill. ISBN 0-07-213123-3. (https://cabforum.org/baseline-requirements-documents/). CAB Forum.
14. Carl Ellison and Bruce Schneier. "Top 10 PKI risks" Retrieved 2017-03-19.
(https://www.schneier.com/paper-pki.pdf) (PDF). Computer Security 29. "SHA-1 Certificates in Chrome" (https://security.googleblog.com
Journal (Volume XVI, Number 1, 2000). /2016/11/sha-1-certificates-in-chrome.html). Google Online Security
15. Peter Gutmann. "PKI: it's not dead, just resting" Blog. Retrieved 2017-03-19.
(http://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.pdf) (PDF). 30. "The end of SHA-1 on the Public Web" (https://blog.mozilla.org
IEEE Computer (Volume:35, Issue: 8). /security/2017/02/23/the-end-of-sha-1-on-the-public-web/). Mozilla
16. Gutmann, Peter. "Everything you Never Wanted to Know about PKI but Security Blog. Retrieved 2017-03-19.
were Forced to Find Out" (http://www.cs.auckland.ac.nz/~pgut001 31. "Microsoft Security Advisory 4010323" (https://technet.microsoft.com
/pubs/pkitutorial.pdf) (PDF). Retrieved 14 November 2011. /en-us/library/security/4010323.aspx). technet.microsoft.com. Retrieved
17. Langley, Adam. "Revocation checking and Chrome's CRL (05 Feb 2017-05-16.
2012)" (https://www.imperialviolet.org/2012/02/05/crlsets.html). 32. "Safari and WebKit do not support SHA-1 certificates"
Imperial Violet. Retrieved 2 February 2017. (https://support.apple.com/en-us/HT207459). Apple Support. Retrieved
18. Zusman and Sotirov Blackhat 2009 (https://www.blackhat.com 2017-05-16.
/presentations/bh-usa-09/SOTIROV/BHUSA09-Sotirov-AttackExtSSL- 33. "Lesser HTTPS for non-browsers | daniel.haxx.se"
PAPER.pdf) (https://daniel.haxx.se/blog/2017/01/10/lesser-https-for-non-browsers/).
daniel.haxx.se. Retrieved 2017-03-19.
9 of 10 8/24/17, 9:56 AM
X.509 - Wikipedia https://en.wikipedia.org/wiki/X.509
34. "PKCS #7: Cryptographic Message Syntax Version 1.5" 39. "Public-Key Infrastructure (X.509) (pkix) - Charter"
(https://www.ietf.org/rfc/rfc2315.txt). (https://datatracker.ietf.org/wg/pkix/charter/). datatracker.ietf.org.
35. "The Transport Layer Security (TLS) Protocol Version 1.2" Fremont, CA, USA: Internet Engineering Task Force. Retrieved
(https://tools.ietf.org/rfc/rfc5246.txt). 2013-10-01.0
36. "X.509 Internet Public Key Infrastructure Online Certificate Status 40. "Pkix Status Pages" (https://tools.ietf.org/wg/pkix/). tools.ietf.org.
Protocol - OCSP" (https://tools.ietf.org/html/rfc6960). Retrieved 2017-03-10.
37. "Internet X.509 Public Key Infrastructure Certificate and Certificate 41. "Web Services Security X.509 Token Profile Version 1.1.1"
Revocation List (CRL) Profile" (https://tools.ietf.org/html/rfc5280). (https://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-
38. "RSA Laboratories - PKCS #12: Personal Information Exchange x509TokenProfile-v1.1.1-os.html). docs.oasis-open.org. Retrieved
Syntax Standard" (https://www.emc.com/emc-plus/rsa-labs/standards- 2017-03-14.
initiatives/pkcs12-personal-information-exchange-syntax- 42. "How To Create an SSH CA to Validate Hosts and Clients with Ubuntu
standard.htm). www.emc.com. Retrieved 2017-03-19. | DigitalOcean" (https://www.digitalocean.com/community/tutorials
/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu).
www.digitalocean.com. Retrieved 2017-03-19.
External links
ITU-T's X.509 standards (http://www.itu.int/rec/T-REC-X.509/en)
Peter Gutmann's articles:
Overview of PKI (https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf)
X.509 implementation notes and style guide (https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt)
"Crypto FAQ from RSA Labs" (https://web.archive.org/web/20061230232250/http://www.rsasecurity.com/rsalabs/node.asp?id=2155). Archived from
the original (http://www.rsasecurity.com/rsalabs/node.asp?id=2155) on 2006-12-30.
Sun Inc. - Secure code guidelines (http://java.sun.com/security/seccodeguide.html)
RFC 4158 - Internet X.509 Public Key Infrastructure: Certification Path Building
CSR Decoder and Certificate Decoder (http://certlogik.com/decoder) - can be used to decode and examine an encoded CSR or certificate.
phpseclib: X.509 Decoder (http://phpseclib.sourceforge.net/x509/decoder.php) - decodes to an associative array whose keys correspond to X.509's
ASN.1 description
SeSeLe (http://www.actiu.net/sesele/), Wizard for SSL self-signed certificates.
Microsoft TechNet Understanding Digital Certificates (https://technet.microsoft.com/en-us/library/bb123848(v=exchg.65).aspx)
10 of 10 8/24/17, 9:56 AM