Certificate does not verify for another hour
Reported by
d3c...@gmail.com,
Jul 6
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: 1. Create a new certificate 2. connect to a site using it. 3. What is the expected behavior? That 'now' being between certificate start and end, that chrome would pass the date. What went wrong? ERR_CERT_DATE_INVALID The cert was 1:31 in the future when I first created it at 10:30 on my computer.... but attached is a creen shot of the clock and the error at the same time showing that the time is between valid_from and valid_to. If I wait an hour, this will work. Seems to be like a daylight savings issue maybe? The .txt file is the cert chain from the details on connection. It is now 10:22 and the cert is still invalid. Did this work before? No Chrome version: 67.0.3396.99 Channel: stable OS Version: 10.0 Flash Version:
,
Jul 6
,
Jul 6
Please attach a chrome://net-export as documented at https://www.chromium.org/for-testers/providing-network-details Note that we cache certificate errors and successes, so if you initially tried to connect to it before realizing your clock was incorrect, then it is working as intended.
,
Jul 6
One might suggest that if a cert is found in the (near) future, that the status could be cleared when valid_after passes. I did a test, opened in an incognito tab, checked what a valid time should be. waited until after the time, and connected in a non-inconito tab and it connected correctly.
,
Jul 6
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 7
Right, incognito profiles will use a separate set of socket pools. I'm going to go ahead and mark this as WontFix. One of the reasons we're very careful about those evictions has to deal with user clock skew. We do clear the cache if the user's clock is significantly off (which is the far more common case), but certificates that are "not yet valid" are not going to be common, especially on the Public PKI - they're more or less forbidden, because they're statements about the future that can't be known.
,
Jul 7
I'm not going to push the issue, I will say a few words, there's a skew of 1:30 some... maybe almost 2:00. Yes, the chance of a collision is slim. In the perspective of 'can't be known' then it can't be cached, because it doesn't exist. If it is cached, it could be given a short TTL. I wonder though; if I kept poking it, would it keep refreshing the cached error? Or is it a fixed delay from the first caching? No response required. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by d3c...@gmail.com
, Jul 6