What differentiates a CA cert from a server cert? [duplicate]

Question

From what I can gather, as long as a client trusts a particular CA root, and a server produces a valid chain that leads up to it, the client will trust the server's cert. This only makes sense if the root is saying not only "this intermediate cert is who they claim to be," but "this intermediate cert is allowed to issue new certs on my behalf." Otherwise anyone (with a cert signed by a widely-trusted root) could act as a widely-trusted CA themselves.

As best I can tell, any cert can be used to issue further certs. So the intermediate CA is special not in that it's able to issue further certs, but in that it's explicitly trusted by the root CA to do so.

I guess my question is: what is it about the intermediate (CA) cert that indicates this? Is there a field that says "I am a valid CA" (that of course the root has to sign)? Are there other differences between CA certs and server certs?

Answer 1

Whether or not a certificate can be used to sign another certificate is defined by the basic constraints field of the certificate. When you submit a CSR to a CA, the certificate returned by the CA should specify that the certificate cannot be used to sign other certificates in the basic constraints field.

Otherwise, this would open the door to anyone being able to create a fake certificate for any site. For example, I could create a CSR for mysite.com, get the certificate signed by a CA like VeriSign, then create a CSR for www.paypal.com and use the certificate for mysite.com to sign the certificate for www.paypal.com. Then, I would have a valid certificate for www.paypal.com. But, I'm not paypal.com.

Notwithstanding, many early SSL implementations in early browsers and even some early versions of OpenSSL did not check the basic constraints field of the certificates in a certificate chain, so this was a vulnerability that could be exploited. Security researcher Moxie Marlenspike was active in bringing this to the public's attention which forced browser makers to fix this. See http://www.thoughtcrime.org/ie-ssl-chain.txt here for more info.

Answer 2

Certificates have lots of metadata, like "Basic Constraints" (BCs), "Key Usages" (KUs), "Extended Key Usages", and "Certificate Policies" that specify what they are allowed to be used for (the reason there's so many things is that the X.509 standard has been extended many time, and some implementations only understand some parts of it or want the more specific values if available). These are part of the certificate signing request (CSR) sent to the CA, and are part of the resulting certificate.

For example, if you look at the cert for this site, you'll see that its BCs specify that it is not a CA, and its KUs are digital signature and key encipherment (both used for the server side of the TLS handshake, in some cipher suites). It also has some additional EKUs and other fields, but for the moment those aren't important to the question. If you instead look at the root CA for this site, it's quite short, with only the BCs specifying that it is a CA, and KUs including Certificate Signing and CRL Signing. If you check the intermediate CA, you'll see that it's also a CA cert according to its BCs, and allowed to sign certs and CRLs according to its KUs.

It is the responsibility of the CA to not issue a CA-usable certificate to any party that isn't authorized to act as an intermediate CA under you. In other words, the CA parses the CSR, makes sure that it doesn't specify BCs or KUs that allow it to act as a CA (or, if it does, that it's from a party trusted to act as a CA), and issues the certificate or not accordingly.

It's also essential that the TLS client library, when validating the certificate chain, verify that everything acting as a CA is allowed to do so. It turns out that this wasn't always done, even in widely used SSL/TLS libraries like OpenSSL and SChannel (the Microsoft library built into Windows). Security researcher Moxie Marlinspike wrote a paper about this, and a tool to exploit it; the paper seems hard to find now, but you can view his 2009 presentation deck from BlackHat (or possibly DEFCON) on the topic here: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf. Quite informative.

Answer 3

This only makes sense if the root is saying not only "this intermediate cert is who they claim to be," but "this intermediate cert is allowed to issue new certs on my behalf."

When signing a certificate, the CA asserts indeed that the private key belongs to a particular entity and what that private key is allowed to do. Being allowed to sign certificates is one of the possible "authorizations".

In practice, the owner of the private key can sign whatever he wants with it. However, compliant web browsers would reject signatures that are cryptographically valid but do not match the purposes of the certificate.

Root and intermediate CAs therefore have fields that indicate they are allowed to sign SSL certificates. The fields can vary. For example, these extensions would ensure the certificate can sign other certs:

X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA:TRUE
    X509v3 Key Usage: critical
        Certificate Sign, CRL Sign

Interestingly, a CA can limit how long the chain of intermediate CA can be, by specifying a pathlen. Therefore, it is possible for example that, the day you create the root certificate, you impose that no intermediate CA can be derived from the root by setting the pathlen to zero. In that case, even if the root mistakingly signs a certificate with CA extensions, certificates signed by the intermediate cert should be rejected by well behaved browsers.