Ryan, any ideas?

We'd need a chrome://net-internals capture here, as described in https://dev.chromium.org/for-testers/providing-network-details

It's possible the enterprise has forced revocation checking for local anchors, which is something IE/Edge and FF can also be configured to do, but may not have been.

If we are forcing revocation for local anchors, we're not intentionally doing so- nor would I understand why the CRLSet would now show this as revoked, which is what I think I'm seeing. 

I'll double check the settings for revocation checking. 

Deleted: net-internals-log.json 676 KB

net-internals-log.json 676 KB View Download

https://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors is not set in either the user or the local machine registry entries, nor is it visible in chrome://policies. 

Here's two certs, for an Oracle WebLogic Server Admin Console. 

They have the same certification path, and the certs seem to be the same (other than the required differences for different servers).

The working cert gives me a warning that SHA-1 is a weak encryption, as expected. The non-working cert tells me that it has been revoked.

I'm now seeing this error on a handful of internal sites. Some of my field servers techs has stated that if they delete the users files (IE, delete c:\users\username folder), the issue disappears at least for a while.

I've tried manually deleting just the Chrome files from the user profile, and I can't seem to reproduce that.

Is there an option to wipe out just the CRLSet?

Deleted: NonWorkingCert.cer 932 bytes

NonWorkingCert.cer 932 bytes Download

Deleted: workingCert.cer 932 bytes

workingCert.cer 932 bytes Download

OK, the NetLog (and the attached certs) certainly confirm that we wouldn't be checking the revocation ourselves.

We also don't push CRLSets that revoke internal certs - although chrome://components will tell you what version the CRLSet component is on, in case that aids in debugging.

The only time we should affirmatively mark a cert revoked is if CryptoAPI returns CRYPT_E_REVOKED, which should only happen if, say, the cert was actually revoked (or it ended up in the Certificate Distrust List)

The best next step would be to enable CAPI2 logging and use the Event Viewer for additional diagnostics. Generally the events produced should be sufficient to highlight what was wrong, but you could also do an export of a CAPI2 trade and I could see what I could find.

https://blogs.msdn.microsoft.com/benjaminperkins/2013/09/30/enable-capi2-event-logging-to-troubleshoot-pki-and-ssl-certificate-issues/ , https://technet.microsoft.com/en-us/library/cc771463(v=ws.11).aspx , and https://technet.microsoft.com/en-us/library/cc749296(v=ws.10).aspx are all decent references to explain how to trace the calls and make sense of them.

Oh... for Pete's sake, it looks like we (well, someone in my org) revoked our own certificates, and configured IE to not check for CRLs. I presume Firefox is grabbing that same setting from IE. I was mislead by the no repro with IE11 and Firefox, and the whole why are we still using SHA-1 question. 

My apologies, and thank you for your time and assistance.