ESET and revoked certificates

[jimwillsher 65]

Hi

Can someone clarify how the ESET "man in the middle" certificate operates, with regards to revoked certificates?

We access a website where we *know* the certificate was revoked on 15th. if I access from a PC on our network, protected by ESET, access is allowed (it shouldn't be):

 

 

If I access the site from another computer, not protected by ESET, the site is correctly rejected by Chrome:

 

 

This doesn't seem right to me.

 

 

Jim

 

[Marcos 5,070]

Please paste the url here so that we don't have to transcribe it manually for a test; it's quite long.

[jimwillsher 65]

It's this one:

saglobal-sandbox1ceacc237d6aa5aedevaos.cloudax.dynamics.com/

However we have already refreshed the certificates. Let me see if we have another site in the same situation.

[jimwillsher 65]

Strange, we have another server (https://sagfunc5abbde991b39cdc0aos.cloudax.dynamics.com/) which eset is correctly flagging.  but it definitely didn't flag the original one I reported, and it had the same cert expiry date.

[itman 1,659]

Here's the deal as far as FireFox goes; I don't use Chrome.

When I enter this URL, https://saglobal-sandbox1ceacc237d6aa5aedevaos.cloudax.dynamics.com/ , I am redirected to this URL, https://login.microsoftonline.com/saglobal.com/wsfed?wa=wsignin1.0&wtrealm=spn%3a00000015-0000-0000-c000-000000000000&wctx=rm%3d0%26id%3dpassive%26ru%3d%2f&wct=2021-02-17T14%3a35%3a06Z&wreply=https%3a%2f%2fsaglobal-sandbox1ceacc237d6aa5aedevaos.cloudax.dynamics.com%2f , which results in the below web page being displayed. The sign on display format is the same as the one given when signing on using one's Microsoft account.

In any case, Eset SSL/TLS protocol scanning has whitelisted this URL and is not scanning it. Why? Because its a Microsoft logon certificate. This also means no certificate validations are being performed by Eset.

-EDIT- Note that Chrome by default uses a CRL for revoked certificate checking. Eset and also FireFox use OCSP. My best guess to what happened here is Chrome's CRL got updated but OCSP servers did not for some reason.

   

Edited February 17, 2021 by itman

[itman 1,659]

1 hour ago, jimwillsher said:

Strange, we have another server (https://sagfunc5abbde991b39cdc0aos.cloudax.dynamics.com/) which eset is correctly flagging.  but it definitely didn't flag the original one I reported, and it had the same cert expiry date.

I also don't know why Eset flags this cert. since it validates fine:

No, this cert. shows revoked via OCSP server status. QUALS SSL status report here: https://www.ssllabs.com/ssltest/analyze.html?d=sagfunc5abbde991b39cdc0aos.cloudax.dynamics.com

 

[itman 1,659]

This article might be of interest on how different browsers perform certificate validations: https://www.ssl.com/article/how-do-browsers-handle-revoked-ssl-tls-certificates/ .

I also don't know if there is a resolution to this inconsistency in certificate verification. Google pretty much locks down access to Chrome internals. FireFox uses both CRL and OCSP by default unless OCSP has been manually disabled. The self-test SSL.com performed shows that FireFox with OCSP enabled is superior to Chrome in certificate checking ; at least on Window OSes.

Edited February 17, 2021 by itman