This would indeed be a surprising finding. Can you please provide a network log demonstrating this claim? The instructions for doing so can be found here: https://dev.chromium.org/for-testers/providing-network-details

Can you also provide the Chrome and OS version information?

I'm not able to reproduce the described issue using either Chrome 63 or Chrome 65 on Windows.

I'll reproduce it, and send necessary files, sorry I did not have time in the past days.

Thank you for providing more feedback. Adding requester "elawrence@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

Still awaiting feedback from reporter.

Howdy, original reporter. Can you please provide additional details requested in Comment #2? At present, this is not reproducible for us.

Thanks!

[Security impact and severity set tentatively based on what they're likely to be if the issue becomes reproducible]

hey, yes I'll, I just didnt have time this week but i'll try to do my best and soon send more details.

Thank you for providing more feedback. Adding requester "tsepez@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

Without the needed data from the original reporter, this issue will need to be closed as inactionable.

As noted in #3, I wasn't able to reproduce this in general. The one thing that might be interesting to look at is whether this is a case where HTTP/2 is in use and coalescing has occurred. Coalescing behavior can be surprising and confusing (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=789843#c8) but I don't think we should be doing such coalescing in the face of a certificate error. If we do, that seems wrong.

I'm so sorry for late response. 
I was issuing this at our customer's production system, but I can not roll back that system to that invalid state,
so I'm trying to setup a dev sys where I can use the same ip and same certificate like there.

In meanwhile I tried to reproduce it, but it was not that easy like I wrote on page, maybe something was special on the environment.

Thank you for providing more feedback. Adding requester "rsesek@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

Before we close this as not-repro, davidben@, rsleevi@ -- Is there anything here that is cause for concern?

Is there any possibility that we're doing H2 coalescing in this scenario in a way where an accepted invalid certificate is allowed for a different host?

So, the logic for H/2 (and QUIC) coalescing is all centered around SpdySession::CanPool(), which is supposed to reject all cert errors ('supposed to' as in - that's what the code is written to do - see https://cs.chromium.org/chromium/src/net/spdy/chromium/spdy_session.cc?rcl=4f39d6332f9986292ee753e016883d7823fb3741&l=679 )

So I don't think so, I hope not, but without more data, I don't think we have anything we can act on.

I'm sorry about it to wasted your time for it.
I'll ask my colleague to set that system certificates back to that certs, and I'll send more details if possible, hopefully on this week, maybe at weekend.
Thank you for your patience.

If you can get a reliable reproduction case or network logs, please feel free to open a new bug. Thanks!

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