In order to be accepted as an issuer for other certificates, a CA certificate must be marked as such: they must contain a
Basic Constraints extension with the
cA flag set to
TRUE. If a client (e.g. a Web browser) sees a purported server certificate chain, with the "X.com" certificate, not marked as a CA, used as an intermediate CA, then the client will reject the chain, in application of the standard certificate validation algorithm, in section 6.1.4, step (k):
(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
Note the comments about "version 1" and "version 2" certificates. Modern X.509 certificates are "version 3" (their
version field contains 2, not 0 or 1). Previous versions for the X.509 format did not have room for extensions, so no
Basic Constraints. The glaring vulnerability that you feared, with any certificate owner being able to act as a CA, was, well, glaring indeed. But it took several years for people to catch up.
Fortunately, all current implementations of SSL consider v1 and v2 certificates as "definitely non-CA", just like v3 certificate which lack a
Basic Constraints extension.
On a similar vein, Internet Explorer, up to circa 2003 (if I remember correctly), did not check the
cA flag... and it was indeed a serious problem, which was promptly fixed when discovered. It says quite a lot about X.509 that nobody had actually tested that for quite some time, because IE already had SSL support back in 1996 and v3 certificates were standardized in early 1999 (so, as is typical for Web thing, they were already deployed at that time, and the standard was more of a documentation of existing practice than anything else).
As for your specific question: how long does this chain extend ? There is no intrinsic limit, in the X.509 standard, about chain length, as long as all certificates in the chain are duly marked as CA (except possibly the last one) and have proper signatures and all the fields in certificates match up as they should. However, certification is trust delegation and trust dilutes very fast when delegated too much. Thus, overly long chains are a strong indication that the whole PKI process has gone bad.
Also, long chains may hit internal limits in some implementations. Chain building (the operation which prepares potential chains to be validated) can become expensive (with specially crafted certificates, it can have factorial cost for a given chain length), so implementations must include some guarding mechanism, which often is an internal maximum chain length. Practically encountered chains have length 2 to 4 certificates (i.e. one root, three intermediate CA at most, and then the end-entity certificate). My own code tends to reject chains beyond 8 certificates, and that arbitrary limit has never been, in my experience, an issue.