Test cases:
If the SAN extension critical flag is set to false/true, Google Chrome fails to detect the SAN.

If the SAN extension critical flag is omitted, Google Chrome is able to detect the SAN.

It appears that at least some other platforms e.g. Java have this issue [1]. Over to the certificates team to say whether this is intentional.


[1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6668231

More details are needed - as sites like http://no-subject.badssl.com load fine (other than macOS 10.11-10.13, which is KI). These sites have an empty subject and a critical SAN.

However, the description "It is found that the 'critical' flag for the SAN extension is not omitted but loaded with the value of false" likely indicates an encoding error in the certificate (DER does not explicitly encode default values in sequences, and critical is default false)

More details are necessary, and can be provided via https://dev.chromium.org/for-testers/providing-network-details

Sorry, my mistake on the "SAN extension critical flag is set to false/true".

I ran a few more tests on Google Chrome.

Test cases:
If any of the extension in the server certificate has critical flag set to false, Google Chrome will fail to detect the SAN extension.

If any of the extension in the server certificate has critical flag set to true but with some omitted (false), Google Chrome is able to detect the SAN extension.

Although DER does not explicitly encode default values in sequences, and critical is default false, but should Chrome gives some relax on this restriction as the encoded value (which is false and same as the default value) is a value too and should be considered by the application? There is no issue on Firefox, Internet Explore and Java.

Thank you for providing more feedback. Adding requester "rsleevi@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Again, can you provide a NetLog demonstrating what you believe this behaviour to be? And/or a repro?

We have specific tests covering this, and we cannot reproduce based on your description.

Hi, please see the attached files.

Thank you for providing more feedback. Adding requester "rsleevi@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Another log with error.

Seems it is out of scope from TE end, adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Could someone from dev team please take a look into this issue.
Thanks..!

So the behaviour is as I described in Comment #3:

- If one or more extensions (and it doesn't matter which) are improperly DER encoded, such as using an explicitly encoded default value within a sequence, that extension (and the certificate) are rejected.

We've allowed some relaxations of this, such as the isCA boolean of the basicConstraints extension, which has historical widespread misencoding, but this is done on a case-by-case basis.

From a user experience standpoint, this is resulting in suboptimal experience due to not checking the result code of the parsing function, which would allow a more meaningful error (e.g. ERR_CERT_INVALID) to indicate the misencoding.

That said, the error returned is functionally correct - and invalid certificates are being rejected, while valid certificates are accepted - but there's improvements we can do to communicating that.

Matt, Eric: Adding you for your thoughts here

Right, the certificate's SAN extension is improperly DER encoded.

Platform verifiers are generally permissive enough that they will allow this.

However we overlay our own name checking [1] which separately parses the SAN. In GetSubjectAltNames() [2] (which is now using the "byte certs") implementation, an incorrectly encoded extension results in a parsing error. However the consumer X509Certificate::VerifyNameMatch() is not checking for parsing errors so interprets this case the same as if the SAN had been omitted.

In line with comment #12 agree this should be setting ERR_CERT_INVALID.

As far as whether incorrectly encoded critical booleans should be permitted, I would say no. We should only relax parsing of extensions to allow incorrect DER if necessary for compatibility. And neither the CT corpus, nor the fact that Chrome has been shipping this without problems since enabling "use byte certs", indicates that this is a common encoding problem. (Whereas as Ryan indicates, there are other instances where allowing incorrect bool encodings is needed for real world compatibility).

Lastly on the topic of whether having swallowed the parsing error in our name checking is a security bug: I don't believe so. The certificate would have ended up rejected anyway (ERR_CERT_COMMON_NAME_INVALID). In the case where common name fallback was explicitly enabled (not the default) it could end up succeeding, however that is consistent with the expectations of the fallback anyway.

[1] https://cs.chromium.org/chromium/src/net/cert/x509_certificate.cc?sq=package:chromium&dr=CSs&l=477

[2] https://cs.chromium.org/chromium/src/net/cert/x509_certificate_bytes.cc?q=GetSubjectAltName&sq=package:chromium&dr=CSs&l=173

Deleted the attachment and a comment, per the request of the submitter.

 Issue 828074  has been merged into this issue.

Duplicate  Issue 828074  has a nice PoC/Demo of this; the certificate included has a SAN that explicitly encodes "critical:false" and thus fails validation.

As the originator of  Issue 828074  (merged) and after reading this other issue and its comments I really think this is not a bug as initially intended.

Clearly understood that if a flag has a default value, DER mandates that the value never be encoded if it is the default value, so Chrome doesn't need (and shouldn't) to relax here.

Issue has a component, but no priority. Updating to have default priority (Pri-2)