This site's certificate was issued on 20 December 2017, so I wouldn't expect it to be distrusted until Chrome 70?

https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html

See the "December 1st" timeline on that:
December 1, 2017
According to Symantec, DigiCert’s new “Managed Partner Infrastructure” will at this point be capable of full issuance. Any certificates issued by Symantec’s old infrastructure after this point will cease working in a future Chrome update.

That is, all certificates issued from the Legacy Symantec Infrastructure after Dec 1, 2017 are not trusted.

So what is the resolution for the end user? How does one get around this? 

Are you saying we won't be able to access one of the largest websites in the world with the new version that works fine now?

I see this was marked WontFix, and while the little I can glean from your response (as a noncoding IT person) suggests this is not a Chrome bug per se, but still a major Chrome problem. 
Or are you saying (assuming) the certificate issue will be fixed by then?

Thanks,

The certificate issue should be fixed by then. The problem is this site's certificate is not trusted, and must replaced it with a trusted certificate.

 Issue 813237  has been merged into this issue.

This does not seem to be a certificate issue. 
alexa.amazon.com is now working for me with 65.0.3325.73
The alexa cert is for pitangui.amazon.com, valid from 12/19/17
  which falls after the 12/1/17 Symantec transition date 
  and should fail per rsleevi c#2

Eric: Can you confirm that M65 newly adds a check to distrust Symantec certs issued after 12/1/17?  The security.googleblog 2017 09 post reads like the 12/1/17 check begins in M66 (as an addition to the before 6/1/16 check in M66).

Since the failure was reported for Windows, is there some MicroSoft Symantec distrust which is kicking in early (before M66)?

mbec@ - I fixed my alexa app in M65 beta, I think, by rebooting my WiFi router.  Does this work for you?  See  issue 813237  for details.

I'm not sure how I healed my laptop.  My alexa app was broken Fr 2/16.  I spent Sa 2/17 using Edge to make Alexa Dot updates.  Today Su 2/17 alexa is magically working again in M65.  

I don't think Amazon has changed their certs since 2/16, but I don't have hard facts on that.  

I can't rule out an interaction with the Edge 2/17 Alexa updates I made either.

If Alexa is still broken for you (mbec) can you look at the cert through the padlock, go to details and save a copy, and attach the copy here?

Your router reboot is a red herring. 

The Alexa.amazon.com cert issued in December from the old Symantec infrastructure is no longer trusted as of M65. Other changes will take place in M66 and M70, as outlined in the blog post. 

I'm not aware of any Microsoft changes. 

Amazon has already replaced the Alexa certificate, as it was not intended to use the legacy Symantec infrastructure. They replaced it on 2/16.

alexa.amazon.com is using the attached cert, OK for M65 (as seen from M65 laptop as of this post)
Subject: pitangui.amazon.com
Issuer: Symantec Class 3 Secure Server CA - G4	
Valid from: 12/19/17 

Looks the same and OK on a second M65 laptop too.

rsleevi@ - What does the Alexa new 2/16 cert look like?

eric, rsleevi: Thanks for the speedy feedback.  Sorry to keep poking at this but I can't square the Valid From date I'm seeing with the discussion here.

Are the M66 Symantec Distrust restrictions active in Canary M66 already?

Alexa.amazon.com 12/19/17 cert attached

Deleted: Alexa-valid_hc19.x64a.cer 2.5 KB

Alexa-valid_hc19.x64a.cer 2.5 KB Download

The distrust for new certificates after 2017-12-01 was part of Chrome 65, the first release after that date.

The distrust for legacy certificates issued before 2016-06-01 is part of Chrome 66, as stated.

You can see all the certs issued at https://crt.sh/?q=alexa.amazon.com . You can further see this cert at https://crt.sh/?id=332958930

You can see this cert being returned by https://www.ssllabs.com/ssltest/analyze.html?d=alexa.amazon.com&latest

rsleevi: Thanks for the fishing lesson.. as in: Teach a man to fish.
I see I've been swimming in my own fish bowl (cache).

I have a net-export log and screenshot that demonstrates that new 2/15 alexa cert was being used but Chrome (M65) reported the old cert (via the padlock pulldown or the devtools console).  The chrome cert export was also the stale 12/19 cert.

The problem was the Images and files cache.  Clearing the last week wasn't enough, which covered the span of recent testing.  Clearing for all time displayed the as-used, 2/15 cert.

I'll open a new CR for the stale cache usage, unless you know of an existing one.  Issue 488043 is loosely related, but doesn't callout the UI aspect.

I don't know what you mean by CR, but it's expected that a file loaded from cache shows the cert at the time of caching. 

In 2015, when I jumped in, the issues DB was accessed as crbug.com, and I followed the then usage of calling 'issues' CRs.

The cache issue throws a shadow over trusting the padlock (or devTools console) cert data when trying to unwind user problems.  I'm going to have to move the 'clear cache' step up front in my debug instructions.  Unfortunately I don't remember checking the 'click on NET::ERR' step while my cache was stale.