The CT logs detail a number of unexpired certificate chains where Netscape Server Gated Crypto (2.16.840.1.113733.1.8.1) appears in an intermediate, however the end-entity asserts TLS Server Auth instead.
These paths do not currently validate with net::PathBuilder, since we enable EKU matching on intermediates ( issue 63442 ).
By comparison, Firefox considers Netscape SGC as equivalent to serverAuth when checking intermediates (https://bugzilla.mozilla.org/show_bug.cgi?id=982292) and hence permits such mismatches.
Relatedly, there is Microsoft Server Gated Crypto (1.3.6.1.4.1.311.10.3.3). Doesn't look like Firefox special cases this, however Chrome processes it in some places (i.e. X509Util.java considers it equivalent to TLS Server Auth, and cert_verify_proc_win.cc requests it during path building).
I suspect all the affected certs having Netscape SGC are using weak signatures (SHA1). If that is the case, we could limit this compatibility hack to SHA1 chains.
The CT logs detail a number of unexpired certificate chains where Netscape Server Gated Crypto (2.16.840.1.113730.4.1) appears in an intermediate, however the end-entity asserts TLS Server Auth instead.
These paths do not currently validate with net::PathBuilder, since we enable EKU matching on intermediates ( issue 63442 ).
By comparison, Firefox considers Netscape SGC as equivalent to serverAuth when checking intermediates (https://bugzilla.mozilla.org/show_bug.cgi?id=982292) and hence permits such mismatches.
Relatedly, there is Microsoft Server Gated Crypto (1.3.6.1.4.1.311.10.3.3). Doesn't look like Firefox special cases this, however Chrome processes it in some places (i.e. X509Util.java considers it equivalent to TLS Server Auth, and cert_verify_proc_win.cc requests it during path building).
I suspect all the affected certs having Netscape SGC are using weak signatures (SHA1). If that is the case, we could limit this compatibility hack to SHA1 chains.
All of the public certificate chains (logged to CT) that rely on Netscape Server Gated Crypto are either:
(a) Expired
(b) Using a weak signature algorithm (SHA-1)
And there are only 2,754 such unexpired leaf certificates.
So modeling as a failure when doing tlsServerAuth should be sufficient.
A compatibility hack for NSSGC would probably only be relevant when sha1_local_anchors_enabled=true.
Comment 1 by eroman@chromium.org
, Jul 29 2017