4

End certs signed by intermediate certs are accepted by browsers as long as the root is in the trusted certs store. My understanding is that an end-entity cert cannot itself sign other certs (or in any case a browser will not accept such certs). If this is the case, then the browser must be able to distinguish an intermediate cert from an end-entity cert. How does it do this? Is there a message in the intermediate cert saying "This is an intermediate cert" (which has been signed by the root cert for validity)?

questioner
  • 45
  • 4
  • https://stackoverflow.com/questions/48316132/distinguishing-between-ssl-certificates in short: each certificate contains `Basic Constraints` certificate extension. It says whether the subject type is CA or end entity. Extension absence means end entity (not CA). – Crypt32 Mar 13 '18 at 16:35
  • Reminds me of that Apple vulnerability where the basic constraint is not validated and anyone who owns a ceritificate can become a CA... – billc.cn Mar 15 '18 at 17:53

3 Answers3

4

Browsers & OS's only store root certificates, not intermediate certs.

Your question is valid, if I have a cert that is signed by Let's Encrypt, what's to stop me using that cert to sign other certs??!!

There is a flag on the cert that specifies whether it's a CA or End Entity.

For StackExchange today, the server presents 3 certs.

  1. DigiCert
  2. DigiCert SHA2 High Assurance
  3. *.stackexchange.com

If you analyze each cert, under the Basic Constraint->Subject Type, the value will be CA for (1) & (2) but it will be "EndEntity" for (3). Browsers and Applications are expected to not accept certs that aren't signed by a CA cert, if the Basic Constraint->Subject Type extension is missing from the cert, the cert is considered a End Entity by default.

There is also a Basic Constraint->Path Length Constraint , that specifies how long a certificate chain for this root certificate can be. This prevents a intermediate CA, from issuing separate CA certs.

http://www.pkiglobe.org/

keithRozario
  • 3,631
  • 2
  • 12
  • 25
3

There are several "flags" in certificates. one of them is for example "I am a CA" flag, another is the "Maximum Certificate chain length". This last one limits how long a certificate chain may be.

The certificate tools such as openssl will reject signing a certificate with a certificate that does not have the CA flag.

Browsers will stop validating a chain once a non CA certificate is found.

There is no "I am an intermediate" flag, but that status can be infered by being a CA certificate that is signed by someone else.

questioner
  • 45
  • 4
LvB
  • 8,336
  • 1
  • 27
  • 43
  • Do all certs with the CA flag need to be in the trusted root certificate store for the browser to accept a certificate chain or is this only necessary for the root cert? – questioner Mar 13 '18 at 18:56
  • Intermediate CAs do not necessarily have to be directly verified by a root CA but can be verified by another intermediate CA, as long as the chain of trust eventually ends with a root CA. Source: "[Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL](https://pdfs.semanticscholar.org/8bde/cee8b0e9f0b956965051ad2436fc403b619f.pdf)" by Christopher Soghoian and Sid Stamm – vrtjason Mar 13 '18 at 20:10
  • I'm not sure if you misunderstood my question or if I am misunderstanding your answer. I want to know whether the intermediate cert needs to be in the browser's list of trusted certs, not whether you need to have a root cert directly above the intermediate cert (as opposed to having another intermediate cert before the root). – questioner Mar 13 '18 at 21:20
0

Each certificate has a subject which describes who the certificate is for and an issuer which means who issued (and thus signed) the certificate. For root certificate subject and issuer are the same, i.e. the certificate is signed by itself ("self-signed"). For intermediate certificates subject and issuer are different. Both root and intermediate certificate need to be CA certificates, i.e. have CA:true in basic constraints.

Based on the subject and issuer one can construct the certificate chain. At the start of the chain is the server certificate, which is issued by CA certificate #1. This CA certificate #1 might be self-signed (issuer equals subject) in which case it is the end of the trust chain and thus the root certificate. Or it might be signed by yet another CA certificate which means that it is somewhere inside the trust chain (and not the end) and it is thus an intermediate certificate.

For more details see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? or Wikipedia:Chain of trust.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434