X.509

History and usage

Certificates

Structure of a certificate

• 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
• *Subject Unique Identifier
• *Extensions
• **...
• Certificate Signature Algorithm
• Certificate Signature

Extensions informing a specific usage of a certificate

• Basic Constraints, , are used to indicate whether the certificate belongs to a CA.
• Key Usage, , 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, , 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, indicates that the key may be used on the server end of a TLS or SSL connection; indicates that the key may be used to secure email.

Certificate filename extensions

• .pem – 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
• .p7b, .p7c – PKCS#7 SignedData structure without data, just certificate or CRL
• .p12 – PKCS#12, may contain certificate and private keys
• .pfx – PFX, predecessor of PKCS#12

Certificate chains and cross-certification

1. The Issuer of each certificate matches the Subject of the next certificate in the list.
2. Each certificate is signed by the secret key corresponding to the next certificate in the chain.
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.

• Each box represents a certificate, with its Subject in bold.
• A → B means "A is signed by B".
• Certificates with the same color contain the same public key.

  Example 1: Cross-certification at root Certification Authority (CA) level between two PKIs

Example 2: CA certificate renewal

Sample X.509 certificates

End-entity certificate

Intermediate certificate

Root certificate

Security

Architectural weaknesses

• Use of blacklisting invalid certificates,
• *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.
• CRLs are notably a poor choice because of large sizes and convoluted distribution patterns,
• Ambiguous OCSP semantics and lack of historical revocation status,
• Revocation of root certificates is not addressed,
• Aggregation problem: Identity claims, attribute claims, and policy claims are combined in a single container. This raises privacy, policy mapping, and maintenance issues.
• 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 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.

  Problems with certificate authorities

• 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, yet trust value in the eyes of security experts are diminishing.
• Certification authorities deny almost all warranties to the user.
• "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."
• 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 DigiNotar, to carry out man-in-the-middle attacks. Another example is a revocation request of the CA of the Dutch government, because of a new Dutch law becoming active starting January 1, 2018, giving new powers for the Dutch intelligence and security services.

  Implementation issues

• Many implementations turn off revocation check:
• * Seen as obstacle, policies are not enforced
• * If it was turned on in all browsers by default, including code signing, it would probably crash the infrastructure
• DNs are complex and little understood
• rfc822Name has two notations
• Name and policy constraints hardly supported
• Key usage ignored, first certificate in a list being used
• Enforcement of custom OIDs is difficult
• Attributes should not be made critical because it makes clients crash
• Unspecified length of attributes lead to product-specific limits
• There are implementation errors with X.509 that allow e.g. falsified subject names using null-terminated strings or code injection attacks in certificates.
• By using illegal 0x80 padded subidentifiers of object identifiers, 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". Dan Kaminsky at the 26th Chaos Communication Congress "Black OPs of PKI"

  Cryptographic weaknesses

• MD2-based certificates were used for a long time and were vulnerable to preimage attacks. Since the root certificate already had a self-signature, attackers could use this signature and use it for an intermediate certificate.
• In 2005, Arjen Lenstra and Benne de Weger demonstrated "how to use hash collisions to construct two X.509 certificates that contain identical signatures and that differ only in the public keys", achieved using a collision attack on the MD5 hash function.
• In 2008, Alexander Sotirov and Marc Stevens presented at the Chaos Communication Congress a practical attack that allowed them to create a rogue Certificate Authority, accepted by all common browsers, by exploiting the fact that RapidSSL was still issuing X.509 certificates based on MD5.
• In April 2009 at the Eurocrypt Conference, Australian Researchers of Macquarie University presented "Automatic Differential Path Searching for SHA-1". The researchers were able to deduce a method which increases the likelihood of a collision by several orders of magnitude.
• In February 2017, a group of researchers led by Marc Stevens produced a SHA-1 collision, demonstrating SHA-1's weakness.

  Mitigations for cryptographic weaknesses

PKI standards for X.509

• PKCS7.
• Transport Layer Security and its predecessor SSL — cryptographic protocols for Internet secure communications.
• Online Certificate Status Protocol / certificate revocation list — this is to check certificate revocation status.
• PKCS12 — used to store a private key with the appropriate public key certificate.

  PKIX Working Group

Major protocols and standards using X.509 certificates