Specification: Complexity and lack of quality
The X.509 standard was primarily designed to support the X.500 structure, but todays use cases center around the web. Many features are of little or no relevance today. The X.509 specification suffers from being over-functional and underspecified and the normative information is spread across many documents from different standardization bodies. Several profiles were developed to solve this, but these introduce interoperability issues and did not fix the problem.
Architectural flaws
Use of blacklisting invalid certificates (using CRLs and OCSP) instead of whitelisting
CRLs are particularly poor because of size and distribution patterns
Ambiguous OCSP semantics and lack of historical revocation status
Revocation of root certificates not addressed
Aggregation problem: Identity claim (authenticate with an identifier), attribute claim (submit a bag of vetted attributes) and policy claim are combined in a single container. This raises privacy, policy mapping and maintenance issues.
Delegation problem: CAs cannot technically restrict subCAs to issue only certificates within a limited namespaces and attribute set – this feature of X.509 in not in use. Therefore a large number of CAs exists in the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, like it is common business practice.
Federation problem: Certificate chains that are the result of sub-CAs, bridge- and cross-signing make validation complex and expensive in terms of processing time. Path validation semantics may be ambiguous. Hierarchy with 3rd-party trusted party is the only model. This is inconvenient when a bilateral trust relationship is already in place.
Problems of Commercial Certificate Authorities
Flawed business model: The subject, not the relying party, purchases certificates. The RA will usually go for the cheapest offer; quality is not being paid for in the competing market.
CAs deny almost all warranties to the user.
Expiration date: Should be used to limit the time the key strength is deemed sufficient. Abused by CAs to charge the client an extension fee. Places unnecessary burden on user with key roll-over.
Client certificates have zero protection value against dedicated attackers.
In browsers, the security is that of the weakest CA. There are very weak CAs.
“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.“
Implementation issues
Implementation suffer from design flaws, bugs, different interpretations of standards and lack of interoperability of different standards. Some problems are:
Many implementations turn off revocation check:
Seen as obstacle, policies are not enforced
Would it be turned on in all browsers by default, including code signing, it would probably crash the infrastructure.
DNs are complex and little understood (lack of cononicalization, i18n problems, ..)
rfc822Name has 2 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
Exploits
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.
X.509 certificates based on SHA-1 had been deemed to be secure up until very recent times. 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.
Domain-validated certificates („Junk certificates“) are still trusted by web browsers, and can be obtained with little effort from commercial CAs.
EV-certificates are of very limited help, because Browsers do not have policies that disallow DV-certificates,
There are implementation errors with X.509 that allow e.g. falsified subject names using null-terminated strings or code injections attacks in certificates.
