15

I am trying to understand how SSL certificate and signing and the chain of trust works.

I know about root CAs and that they are used to sign intermediate CAs that sign the end certificates that are issued to a website. I also understand how the chain of trust works and that because a ceritifcate signed for X.com is signed by the intermediate certificate that issued it which is signed by the root CA, I can be assured that I am connecting to X.com.

My question is, how long does this chain extend? Can't I use X.com to sign a certificate for another domain, say Y.com. If no, why not? If yes, I don't see the purpose of signing.

Improve this question

5 Answers 5

Reset to default
17

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 certificates.)

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.

Improve this answer
4

When a Root CA signs a certificate for an intermediate CA, the signed certificate has a special field set (specifically, a certificate authority flag in the Basic Constraints extension), that designates it as a CA certificate. Certificates signed for domains, as you'd get from your CA, do not have this field set, so your browser will not consider them for the chain of trusted certificates back to the root CA.

Improve this answer
3

How long does this chain extend?

There is no specified limit, but clients (browsers, mail programs, etc) may have some internal limit as to how many hops they're willing to follow.

Can't I use X.com to sign a certificate for another domain, say Y.com. If no, why not? If yes, I don't see the purpose of signing.

No, since X.com's certificate is not marked as a signing certificate.

Or rather: yes, you could, the underlying technology doesn't prevent you from doing so. But browsers are programmed to check for the CA: true basic constraint for all signing and intermediate certificates, and will not trust the signature if that isn't true.

Convincing a CA to sign an intermediate certificate for you is no small feat, since they're staking their reputation on the assertion that you will not sign anything that shouldn't be signed. Not a small guarantee.

Improve this answer
1

Unfortunately, X.com cannot sign Y.com for security purposes. Take the following example:

  1. Mallory is trying to perform a MITM attack on Alice and Bob. He owns a valid certificate signed by Verisign for Z.com.
  2. Alice sends the valid certificate for X.com to Bob, signed by Verisign.
  3. Mallory intercepts that connection, signs a certificate for X.com with his certificate for Z.com and sends that to bob.
  4. Now Mallory can decrypt all the data coming from Bob because he has the private key for the certificate that he sent, signed by Z.com.
Improve this answer
0

Directly answering your question, NO. In your given case the chain will not extend. In order to validate a given certificate the browser has to verify the CA signature on the certificate. This is done by using the Public key (Digital Certificate) of the CA. The browsers are shipped with these CA certificates already installed (It is possible to manually install a certificate in a browser)

If you use X.com's certificate to sign a certificate for another domain Y.com the browsers will not be able to validate your certificate because you are not in the list of trusted CAs and a security warning will be thrown.

Basically certificates are used to verify the authenticity of the server. This is required to prevent MITM attacks. Otherwise an attacker could claim that he is the real server and your browser would happily send messages encrypted with the private key of the attacker.Hence only the certificates signed by trusted CAs are trusted by the browser.

Improve this answer
2
  • I think this is incorrect. Browsers have to ship with only the root CAs and not the intermediate CAs. So they don't know anything about the intermediate CA, they just use it to verify the chain of trust up to the root CA.
    – AnonSmith
    Commented Jul 15, 2013 at 4:24
  • 1
    And no responsible intermediate CA would deliver you a certificate with the Basic constraints field set to anything else to FALSE if you are an end user. That is what is preventing you to extend the chain.
    – Alexandre Yamajako
    Commented Jul 15, 2013 at 4:55

You must log in to answer this question.

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