jimwillsher 64 Posted February 17, 2021 Share Posted February 17, 2021 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 Link to comment Share on other sites More sharing options...
Administrators Marcos 4,703 Posted February 17, 2021 Administrators Share Posted February 17, 2021 Please paste the url here so that we don't have to transcribe it manually for a test; it's quite long. Link to comment Share on other sites More sharing options...
jimwillsher 64 Posted February 17, 2021 Author Share Posted February 17, 2021 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. Link to comment Share on other sites More sharing options...
jimwillsher 64 Posted February 17, 2021 Author Share Posted February 17, 2021 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. Link to comment Share on other sites More sharing options...
itman 1,538 Posted February 17, 2021 Share Posted February 17, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
itman 1,538 Posted February 17, 2021 Share Posted February 17, 2021 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 Link to comment Share on other sites More sharing options...
itman 1,538 Posted February 17, 2021 Share Posted February 17, 2021 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts