9

Update: Now Chrome rejects this website for me.

It seems the trusting is just cached somewhere?
I guess this question isn't as interesting as I thought, but it'd be nice if someone could clarify it.

Original question:

I've disabled automatic certificate updating, removed the root certificate, and rebooted my computer.

Yet Chrome is still trusting the certificate from this site, even though Windows finds it unverifiable!

Why in the world is this happening? Screenshot:

Screenshot

Community
  • 1
user541686
  • 2,502
  • 2
  • 21
  • 28
  • What version of Windows are you seeing this behavior on? When saving it from Chrome and viewing it on my Windows 8 host it appears to be from a trusted CA. – PwdRsch Jan 19 '17 at 20:05
  • @PwdRsch: See the tag. Try deleting the root CA and disabling automatic certificate updating and rebooting. See if it's still trusted for you. – user541686 Jan 19 '17 at 20:09
  • Are there other sites where deleting the root leads to a distrusted certificate? – Arminius Jan 19 '17 at 20:12
  • If I delete the root CA and disable cert updates it seems like I should expect it not to be trusted. – PwdRsch Jan 19 '17 at 20:20
  • 1
    @PwdRsch That's exactly what OP is asking about - why Chrome trusts the certificate although the root was removed. – Arminius Jan 19 '17 at 20:26
  • Did you remove the certificate from inside Chrome? – Arminius Jan 19 '17 at 20:28
  • @Arminius: No, I removed it from outside. But I don't see it inside Chrome either. It would be helpful if you could tell me whether you are able to reproduce this yourself. – user541686 Jan 19 '17 at 20:36

2 Answers2

5

Looks like a reported bug. Someone blogged about it.

John Wu
  • 9,101
  • 1
  • 28
  • 39
3

Asterisk: I don't have the answer to the question. I was able to reproduce the OP's scenario and I am just having a stab at what might be happening.

I started with some basic digging into how certificates are validated by browsers. It looks like when a site serves an SSL cert and the top of the certification path is not a root CA in the trust store, other mechanisms seem to be kicking in. Server-based Certificate Validation Protocol (SCVP) seems to be a mechanism to bridge this "gap" in the trust chain. The wikipedia article on SCVP seems to say the following -

CAPI is capable of building certification paths using any certificates that are installed in Windows certificate stores or provided by the relying party application. The Equifax CA certificate, for example, comes installed in Windows as a trusted certificate. If CAPI knows about the ACME Co CA certificate or if it is included in a signed email and made available to CAPI by Outlook, CAPI can create the certification path above. However, if CAPI cannot find the ACME Co CA certificate, it has no way to verify that Joe User is trusted. SCVP provides us with a standards-based client-server protocol for solving this problem using Delegated Path Discovery, or DPD. When using DPD, a relying party asks a server for a certification path that meets its needs.

Note: CAPI stands for Cryptographic Application Programming Interface. More details in the Wiki article.

My stab in the dark: Chrome is using SCVP (or similar) to validate the certificate when the root cert is no longer present in the Windows cert store. Now, there is a possibility that I am wrong and SCVP is purely for certificate revocation mechanisms like OCSP, but i thought not simply because Chrome disabled OSCP in 2012 and probably doesn't use SCVP for revocation checks.

katrix
  • 533
  • 2
  • 13