On most platforms, certificate management is a responsibility of the operating system. 

The issue described here would only possibly be a security bug if the certificate with an invalid date range were actually usable to sign other certificates that would be accepted without error. Have you found some way for Chrome to accept a certificate chain that originates from the certificate with the invalid date range?

Certificate validation is an important way to guarantee the security of communications on the Internet. Flaws in in certificate validation results in insecurity of communications. We found in our experiments that Chrome accepts this certificate with a specially invalid date range. In our opinion, this is a latent security problem. Therefore, we reported it. 

As for the certificate chain, it is a part of our research. According to our plan, we will carry out related experiments in April or May. If we find useful bugs in the related experiments, we will report them to you. Thank you!

On Windows, certificates are managed by the system; Chrome doesn't "see" what you import at the time of import. If a chain were to build to the invalid root certificate, I'd expect the chain to be deemed invalid. A finding otherwise would be surprising and represent a security bug.

On Linux, Chrome maintains its own certificate manager; the certificate is loaded via CertificatesHandler::ImportServerFileRead, which presumably could do more validation on the imported certificate if it made sense. Again though, this only possibly represents a security bug if Chrome accepts (for the purposes of authenticating a HTTPS server) a certificate chain containing such an invalid certificate.

elawrence@, what should we do with this bug for now, since we don't have any actionable cert chains?

I'm fairly certain this is WontFix as described, but I do want to make sure I properly understand the report.

Why WontFix:
- The situation described is related to importation, not validation. If this was related to validation, it would need to be triaged, but based on the evidence so far, there's no report of attempts to validate with it.

To expand on that: We don't verify certificates when importing. This is because to import a certificate, you need access to the machine, and https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- generally captures why such 'attacks' aren't considered attacks.

To expand on why we don't validate when importing: It's not necessary, and it has a higher false positive rate but offers no tangible security benefit. This is because regardless of whether you verify at import, you will always need to verify at time of use. This is also because to import a client certificate, Chrome doesn't need to verify at import because it will _never_ verify the certificate, because its use will only be in shipping an opaque set of bytes to a server; it's the servers responsibility to validate. Further, we don't verify on the client because we don't know how the server will validate - it could be more relaxed (for example, accepting negative modulus RSA keys, such as were used in a whole host of Estonian national ID cards) or it could be more strict (e.g. checking revocation information dynamically on the server, which Chrome does not support on the client)

If you're able to demonstrate any attack in which such a certificate is used to authenticate a website, we'd be very happy to revisit. However, as described, this is just about adding strictness when importing, and that offers no security benefits, and questionable usability benefits.

No response, closing as WontFix.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot