Usually, I only see certificate chains with a root CA, an intermediate one, and a third one for the particular SSL/TLS website; but can X.509 certificate chains be deeper than 3 levels? Is there a limit to how long they can be? Wouldn't using longer chains that are more interconnected with other root and intermediate CAs help make the chain of trust stronger, more decentralized, and less prone to a single point of failure?

This seems to be the idea behind okTurtles's DNSChain—a decentralized, blockchain-based DNS network that solves the problem of having to rely on a centralized network of CAs; thus, it is resistant to man-in-the-middle (MitM) attacks.

  • 4
  • Your question as stated is hurting the case of okturtles. Please either remove the unwarranted mention of okturtles.com, or self-delete your question and instead ask "how do okturtles work?" As stated, the question provoked two answers about X.509 and they both may be easily misunderstood as negating "okturtles.com is a great idea". Which it seems it is. I'm not affiliated, I've heard about them for the first time just now.
    – kubanczyk
    Commented Mar 11, 2016 at 21:50
  • 1
    you should check certificate of signed.bad.horse
    – rav_kr
    Commented Mar 11, 2016 at 23:02

2 Answers 2


There is no technical/specification limit imposed on the length of certificate chains. (However, there are X509v3 attributes which can impose policy-based limits on the length of a certificate chain for a CA; see the pathLenConstraint field of Basic Constraints, RFC 5280, Section

With longer chains, verifying clients need to perform a little more validation work, constructing and walking and verifying each certificate in that chain, every validation, every time. But that's not necessarily a bad thing. However, it does increase the odds that at some point in time, one of the certificates in the chain will have expired, or been revoked. Many certificate chains are constructed such that there is only one path from the e.g. leaf certificate (server/client) to a trusted root CA; should that path be invalidated anywhere along the way, that leaf certificate would not be considered trusted.

There are ways for CAs to do cross certification, indicating that two CAs trust each other (discussed in RFC 5280, Section 3.2). I'm not sure how common/widespread the usage of this mechanism is. It allows for some kind of delegation, but it is still very hierarchical and centrally managed, rather than being fully decentralized.

Hope this helps!

  • 4
    I'll note one significant instance of cross-certification that happened between LetsEncrypt X1 and IdenTrust DST X3 not too long ago to allow LetsEncrypt to appear in major browsers before it's actual root CA is deployed with browsers. Commented Mar 11, 2016 at 16:48
  • 1
    Cross certification tends not to work well, because systems rebuild chains by following URL found in certificates (AIA extensions), so they won't do it for the cross CA unless the crossing was already in place when the certificates were emitted. Even so, some implementations (Microsoft...) will be content with the first URL for which a matching intermediate CA is found, and won't explore the other URL. Commented Mar 11, 2016 at 16:50
  • @Oasiscircle I did not know they did that. interesting
    – Geremia
    Commented Mar 11, 2016 at 23:24

Theoretically, X.509 chains are unlimited in length. The Basic Constraints extension can apply a per-chain limit; this is used mostly for CA that agree to issue a sub-CA certificate but want to constraint that sub-CA to issue only end-entity certificates.

Implementations may have limitations. In fact, with some carefully crafted certificates, one can make a path-building application explore n! potential paths of depth n, and since factorials go up pretty fast, this can lead to huge denial-of-service attacks. Correspondingly, implementations tend to impose a relatively low maximum length (I know I used '8' for my own implementations).

In broad conceptual terms, trusts dilutes pretty fast upon delegation. When a CA issues a certificate to a sub-CA, it not only asserts that the sub-CA public key is owned by that sub-CA, but it also empowers it to perform that kind of verification on behalf of the parent CA. When a CA issues a certificate for an end-entity, it checks its identity; when it issues a certificate to a sub-CA, it also needs to make sure that the sub-CA won't be gullible. With a third level, the CA must ensure that the sub-CA is not gullible and won't issue a certificate to a gullible sub-sub-CA.

So the reflex would be to try to keep chains short rather than long.

Be wary of the "single point of failure" expression. It normally applies to operational continuity. Here, we are talking about security: a single rogue CA compromises security, regardless of how many other paths you create. This goes somehow in reverse with the SPOF rule: you avoid SPOF by adding redundancy, but in the case of certification, any involved CA is by nature able to compromise things -- the more CA you add in the mix, the more vulnerable you get.

  • I think the main problem here is that a sub-CA certificate can't say "this sub CA is only certified to create certificates for (subdomains of) domain xy" or similar. That would make many problems go away, and allow longer chains without problems. Commented Mar 12, 2016 at 1:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .