1

OpenSSL shows the following certificate chain for example.com:443.

$ openssl s_client -connect example.com:443 < /dev/null | head -10
depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=Los Angeles/O=Internet Corporation for Assigned Names and Numbers/OU=Technology/CN=www.example.org
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----

The certificate chain has the server certificate issued to www.example.org and an intermediate certificate that belongs to DigiCert SHA2 High Assurance Server CA.

However, the certificate chain does not contain the self-signed root certificate fo DigiCert High Assurance EV Root CA.

But both Firefox and Chrome also show the root certificate as part of the certificate chain. That's because these root certificates come bundled with the browsers.

enter image description here

enter image description here

I want to know if there is any way in Firefox or Chrome to figure out that only two of the three certificates in the displayed certificate chain belong to the certificate chain provided by the server in the TLS handshake? Perhaps some sort of visual indicator or some other thing that differentiates the certificates that appeared in the certificate chain from the ones that are part of the browser's trust store?

Improve this question
7
  • There isn't and there is no reason for such an indicator: the source of the certificate does not have any effect on security as long as the chain is validated properly and correctly anchored.
    – Stephane
    May 4, 2017 at 15:22
  • 1
    @Stephane If I nitpick for a moment, that seems a bit naive. See the ongoing problems with Symantec: groups.google.com/forum/#!topic/mozilla.dev.security.policy/… or older problems with suspicious CAs: theregister.co.uk/2016/09/27/… There might be a legitimate reason to want to know the source.
    – Jesse K
    May 4, 2017 at 19:30
  • The Certificate Client should ignore any "Anchor" certificate Authorities from the server and perform validation only from the Client keystore. Otherwise, what is the point of the Client Keystore? As I read the RFCs on this, the server should not send the Anchor Certificate but many do.
    – jwilleke
    May 5, 2017 at 8:58
  • @jwilleke By "anchor certificate" do you mean the root certificate? Or do you mean something else? Could you please clarify this?
    – Lone Learner
    May 6, 2017 at 11:19
  • 1
    @JesseKeilson (Sorry, I was traveling the last few days). It's not naive, it's just acknowledging a simple fact: if your root anchor is compromised (in ANY way) then there is simply no way to recover without removing the root altogether. If it's NOT compromised, then, assuming the crypto and application code aren't breached (which isn't the argument here), then there is no way for an attacker to exploit it by sending an alternative trust chain through the SSL handshake.
    – Stephane
    May 9, 2017 at 9:20

1 Answer 1

Reset to default
1

You can get the full list of certificates sent by the server by connecting to the server and grab the chain with OpenSSL:

openssl s_client -connect www.google.com:443

That will display (among other thing) the whole chain as sent by the server

That is, however, useless for assessing the security of your connection (it's useful for debugging, though).

Why is that info useless? Well, there is two possible scenarii here:

  1. The trust anchor used is safe. In this case, there is no way for an attacker to inject an invalid certificate in the trust chain: if a given certificate is in the chain, it has been (directly or indirectly) signed by the root and therefore vetted by that root. Since you trust that root (that is the whole point here), you can trust that certificate. Repeat for every cert in the chain and your have full trust.
  2. The trust anchor is compromised in ANY way. Then you cannot trust ANY certificate that it has issued no matter where they come from. These certificates could have been replaced with exactly identical ones with only the public key part changed and you wouldn't be the wiser.

In none of these case will knowing where the intermediate certificates come from help you decide if a specific connection can be trusted, therefore that information is useless from a security perspective.

I'd like to add two things here:

  • That explanation assumes that there is no flaw in either the cryptography or the software used. If this assumption isn't right, then all bets are offs (but this isn't exactly the context of the question).
  • There is a very special case that works in a different way: certificate pinning. In this case, you do not trust a trust chain but hard code (in some way or another) the leaf certificate. In this case, the trust chain is meaningless because that is not the way the trustfulness of the connection is asserted.
Improve this answer

You must log in to answer this question.

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