Jump to content

certificate revoked invalid oscp


Chanklish
Go to solution Solved by itman,

Recommended Posts

I disabled Eset protocol filtering. This means Eset Web Access and Phishing protection were fully disabled. I tried to access this web site in IE11 with the same result; blank web page displayed.

As far as I am concerned, this web site issue has nothing to do with Eset protections. Why access to the web site works on devices w/o Eset installed must be related to something else.

Edited by itman
Link to comment
Share on other sites

I did some further analysis.

I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store. So we can rule out a certificate issue here.

I next thought that perhaps it was a TLS downgrade issue since this web site supports downgrade to TLS 1.0 and 1.1. Note Microsoft browsers now only support TLS 1.2 connections. But Firefox shows a TLS 1.2 connection. So we can rule out this one out also.

Now here is where it gets really weird. In both IE11 and Edge, I inspected the code for the shown blank web page for the site's logon web page. The code is all there! It's just not being executed it appears. I did notice most of the scripts are angularJS based. Perhaps there is an issue with its use by IE11 and Edge? Also the logon web page does take a long time to render in FireFox.

Link to comment
Share on other sites

58 minutes ago, itman said:

I did some further analysis.

I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store. So we can rule out a certificate issue here.

I next thought that perhaps it was a TLS downgrade issue since this web site supports downgrade to TLS 1.0 and 1.1. Note Microsoft browsers now only support TLS 1.2 connections. But Firefox shows a TLS 1.2 connection. So we can rule out this one out also.

Now here is where it gets really weird. In both IE11 and Edge, I inspected the code for the shown blank web page for the site's logon web page. The code is all there! It's just not being executed it appears. I did notice most of the scripts are angularJS based. Perhaps there is an issue with its use by IE11 and Edge? Also the logon web page does take a long time to render in FireFox.

What about chrome? BCE yold me chrome is the chosen browser

Link to comment
Share on other sites

1 hour ago, Chanklish said:

What about chrome? BCE yold me chrome is the chosen browser

I don't have Chrome installed, so I can' test with it.

Try using Chrome on your end ,and see if the web site use is OK.

Edited by itman
Link to comment
Share on other sites

16 hours ago, itman said:

I found the AAA Services root cert. in FireFox. It's listed under the name of "Comodo AAA Services root." It also matches that for the same cert. in the Win root CA store.

I need to revise what I posted above.

The FireFox AAA Services root cert. is not the same as that one present in the Win root CA store. The FireFox AAA Services root cert. contains both SHA-1 and SHA-256 thumbprints whereas the  Win root CA store cert. only contains a SHA-1 thumbprint. This is why the web site web site is fully accessible via FireFox and not so in Microsoft browsers. Note that Microsoft browsers use the Win root CA store exclusively for web site cert. chain validation processing.

Referring back to what I posted previously, it appears OSCP servers used in web site cert. validation processing are using the same AAA Services root cert. that FireFox uses. Also and because SHA-1 encryption is now deprecated, only the SHA-256 thumbprint is being used for verification purposes by the OCSP servers.

You need to contact BCE and have them contact Sertigo, aka Comodo. Sertigo needs to contact Microsoft in regards to updating their existing Win root CA store AAA Services root cert. to include a SHA-256 thumbprint.

Link to comment
Share on other sites

34 minutes ago, itman said:

I need to revise what I posted above.

The FireFox AAA Services root cert. is not the same as that one present in the Win root CA store. The FireFox AAA Services root cert. contains both SHA-1 and SHA-256 thumbprints whereas the  Win root CA store cert. only contains a SHA-1 thumbprint. This is why the web site web site is fully accessible via FireFox and not so in Microsoft browsers. Note that Microsoft browsers use the Win root CA store exclusively for web site cert. chain validation processing.

Referring back to what I posted previously, it appears OSCP servers used in web site cert. validation processing are using the same AAA Services root cert. that FireFox uses. Also and because SHA-1 encryption is now deprecated, only the SHA-256 thumbprint is being used for verification purposes by the OCSP servers.

You need to contact BCE and have them contact Sertigo, aka Comodo. Sertigo needs to contact Microsoft in regards to updating their existing Win root CA store AAA Services root cert. to include a SHA-256 thumbprint.

but why does it work normally on pc without eset ?

Link to comment
Share on other sites

12 minutes ago, Chanklish said:

but why does it work normally on pc without eset ?

I really don't have an answer for that.

As I posted on my Win 10 installation, the same non-web page rendering occurred both in IE11 and Edge with Eset Protocol Filtering disabled. So as far as Win 10 operation goes, this issue is not Eset related. 

However, I am using Eset Internet Security running on Win 10 Home and you are using Eset Endpoint Security running on a Win 7 version. Note that Win 7 is an unsupported OS and I don't know the what updates from it have been applied. It may very well be that IE11; or is it IE10 on your device, is allowing SHA-1 root certificates verification.

Link to comment
Share on other sites

I will also state this. Eset should perform a detailed analysis on what this web site: https://tvs.bce.lt/ is doing. BTW - the web site provider is located in Lithuania which "speaks volumes" as to its status.

As a test, I did a global URL Allow List exclusion on it. When accessing the web site in IE11, I proceeded to receive 95 connection alerts; most related to AngularJS scripts running on the site's web server. Then the alerts stopped with a blank web page being rendered. This implies that something within IE11 prevented the web page from rendering. Only a Process Monitor session will fully detail on what the IE11 issue is with this web site.

Edited by itman
Link to comment
Share on other sites

11 minutes ago, itman said:

I will also state this. Eset should perform a detailed analysis on what this web site: https://tvs.bce.lt/ is doing. BTW - the web site provider is located in Lithuania which "speaks volumes" as to its status.

As a test, I did a global URL Allow List exclusion on it. When accessing the web site in IE11, I proceeded to receive 95 connection alerts; most related to AngularJS scripts running on the site's web server. Then the alerts stopped with a blank web page being rendered. This implies that something within IE11 prevented the web page from rendering. Only a Process Monitor session will fully detail on what the IE11 issue is with this web site.

how you did URL Allow List exclusion ?

Link to comment
Share on other sites

Below is a screen shot of what is the problem in IE11.

The website certificate chain validation appears to be borked. Also I have excluded the web site from Eset SSL/TLS protocol scanning. Otherwise, you would see Eset's root certificate at the top of the certificate chain. Therefore and again, Eset SSL/TLS protocol scanning is not the source of this problem.

Note that the top of the chain root certificate shows a Sertigo CA root certificate. However in reality, it is a UserTrust CA root certificate. It really appears to me that IE is not correctly processing the additional download of the UserTrust CA root certificate and properly chaining it to the Sertigo CA root certificate. It also appears that IE11 is the only browser that is performing this alternate certificate chain processing. It is not being performed in FireFox. This leads me to believe that IE use in regards to this web site is highly suspect. Or taking it a step further, use of this web site is highly suspect.

Eset_BCE.thumb.png.5ff5c37945472daf44a624eb81973d7c.png

 

Edited by itman
Link to comment
Share on other sites

  • Solution

My final posting in this thread is that I found the source of the problem and it is the web site provider. Let's get into the "nitty gritty" detail.

First, read this Sertigo article in its entirety: https://sectigo.com/knowledge-base/detail/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020/kA03l00000117LT . Most important note the following:

Quote

As of April 30, 2020:  For business processes that depend on very old systems, Sectigo has made available (by default in the certificate bundles) a new legacy root for cross-signing, the “AAA Certificate Services” root. However, please use extreme caution about any process that depends on very old legacy systems. Systems that have not received the updates necessary to support newer roots such as Sectigo’s COMODO root will inevitably be missing other essential security updates and should be considered insecure. If you would still like to cross-sign to the AAA Certificate Services root, please contact Sectigo directly.

What does Sertigo mean by "very old systems?:

Quote

The cross-certificates with AAA Certificate Services provide compatibility to older versions:

    Apple iOS 3.
    Apple macOS 10.4.
    Google Android 2.3.
    Mozilla Firefox 1.
    Oracle Java JRE 1.5.0_08.

AAA Certificate Services self-signed root [expiring 2028] - https://crt.sh/?id=331986

Putting all the above together. The web site should not be using the alternate certificate chain validation path that includes use of the AAA Services root cert. for IE certificate validation purposes.

As to the final question as to why this web site renders OK w/o Eset installed, it is most likely linked to Eset Network Protection processing. In order for Eset to scan encrypted network traffic, it does so by intercepting network packet traffic via interfacing with the Windows Filtering Platform. It appears this is done regardless of whether Eset protocol filtering is enabled or not or if a particular web site is excluded from it. This is most likely because at this point, Eset Web Access protection has yet to be deployed. Once the browser in use receives this network traffic and if no Eset protocol filtering is being deployed, Eset re-encrypts the network traffic prior to the web page network traffic being processed by the browser. Because of this Sertigo certificate path issue, Eset is not properly re-encrypting the network traffic resulting in the browser failing to display the web page properly.

Edited by itman
Link to comment
Share on other sites

i was about to post this , i ended up adding the intermediate certificates to the intermediate certificate store in windows 

works like a charm 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...