asked on

Strange SSL Certificate Chrome/Firefox but not in IE/Edge

Starting today, the User is getting SSL errors when using the Chrome or Firefox browsers, but Edge is OK. Sites like Google and any site that is SSL only displays the privacy error:

NET::ERR_CERT_COMMON_NAME_INVALID

When I interrogate the certificate from the browser address bar I get a strange-looking certificate with non-sensical Issuer (CN) of " Exzewohi" and Organization (O) of "Wagoycqau". The Valid From and Valid To dates coincide with the start of the problem (today, 12/29) (12/28/2020 to 12/29/2021). No matter what site I visit with Chrome or Firefox, this certificate is displayed. However, this certificate is not displayed in Edge. When I goto secure sites via Edge I get that site's expected domain certificate and a normal trusted chain.
Steps taken thus far:

Ran Windows Update (Windows 10 1909)
Sys Date/Time are verified as correct.
I did go to Programs/Apps to see if the user installed anything new and did find some off-color programs installed as of today (12/29) and I removed them. (some PDF splitter/merge tool)
I cleared both browsers and reset them.

Despite these steps, I still get this odd and suspicious certificate and the privacy error.

HainKurt

chrome says it is ok

HainKurt

I tried

Chrome
Canary Chrome
Edge / Chromium Based

all valid...

arnold

NET::ERR_CERT_COMMON_NAME_INVALID
points to another issue.

nature of the environment. anyone else within the site having the same issue?

Check the certificate when Edge/IE is used without this error.
Is it the same?

HainKurt

SSL Checker shows no issues with certificate...

https://www.sslshopper.com/ssl-checker.html#hostname=http://www.labcorplink.com/

looks like a plugin/antivirus add-on or a malware infected your pc...
try opening page on Incognito Mode on chrome browsers to see if the issue remains...
Shift+Ctrl+N on chromium based browsers...

JHMarshIII

ASKER

When the User calls, nine times out of ten it turns out they downloaded something they thought useful and free, but as we know nothing is really free. @Arnold, this was what I suspected too, malware. In Edge all the Certificates render properly. It is just in Chrome/Firefox and only on this machine. It is as if something installed its own certificate to foster trust.

So I will check more deeply for a Malware infection.

ASKER CERTIFIED SOLUTION

David Favor

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

arnold

some anti-virus/security include inspecting data in the browser against virus. this makes the application locally setup as trusted and functions as a man in the middle.

David Johnson, CD

The WebServer uses weak crypto use nartac iis crypto to fix this at the server (not related to users error)
Run MalwareBytes to attempt to fix the users machine.

JHMarshIII

ASKER

With the helpful direction received here, I ran an offline WinDefend scan. That picked up some dated Trojan:Win32/Fareit.MV!MTB in the user's roaming profile. I also found some jibberish directory entries. But most interesting was a folder, 'TOR' with some files related to CERTS like 'cached-certs'. After I removed all these things the bad CERTS stopped loading and the website's proper CERTS started displaying in Chrome/Firefox.

@David Johnson, CD, wow, are you saying LabCorp, a major US medical diagnostic lab is using weak crypto? Not good HIPAA.

I will use MalwareBytes and if needed reinstall the OS.

Thank you all who contributed.

David Johnson, CD

Weak Diffie-Hellman and the Logjam Attack

Diffie-Hellman key exchange is a popular cryptographic algorithm that allows Internet protocols to agree on a shared key and negotiate a secure connection. It is fundamental to many protocols including HTTPS, SSH, IPsec, SMTPS, and protocols that rely on TLS.

We have uncovered several weaknesses in how Diffie-Hellman key exchange has been deployed:

Logjam attack against the TLS protocol. The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack is reminiscent of the FREAK attack, but is due to a flaw in the TLS protocol rather than an implementation vulnerability, and attacks a Diffie-Hellman key exchange rather than an RSA key exchange. The attack affects any server that supports DHE_EXPORT ciphers and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.
Threats from state-level adversaries. Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve—the most efficient algorithm for breaking a Diffie-Hellman connection—is dependent only on this prime. After this first step, an attacker can quickly break individual connections.
We carried out this computation against the most common 512-bit prime used for TLS and demonstrate that the Logjam attack can be used to downgrade connections to 80% of TLS servers supporting DHE_EXPORT. We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency's attacks on VPNs are consistent with having achieved such a break.

Weak Diffie-Hellman and the Logjam Attack (weakdh.org)

arnold

They are likely using a reverse proxy to shield their internal web servers.