Catch 22 Situation Encounter In SSL Protocol Scanning

[itman 1,659]

Below is a screen shot of a warning I received from an expired cert embedded in my ISP's home web page.

 

Additionally, my settings for the "End Certificate Validation" section are the defaults:

 

TRCA verification - ask

If certificate is invalid/corrupt - block

 

If I am interpreting the above correctly, SSL protocol scanning should have auto blocked the expired certificate which it did not. The reason why I believe it did not is because I have the option "Apply created exceptions based on certificates" set to on since there are certs I want to exclude from SSL protocol scanning. It appears this option is overriding the End Certificate Validation settings?

 

The result is I am constantly being prompted to allow, deny, trust, or exclude the expired certificate every time I access my web home page. 

 

I have gotten around this issue temporarily by exporting the expired cert to my Untrusted Publishers store and then excluding that cert in Eset. 

 

Either Eset needs to fix this so the "End Certification Validation" takes precedence or a "Block" option be added to the existing Trust or Exclude categories in the exceptions area.

 

Edited April 19, 2015 by itman

[rugk 397]

So what happened to you is that the certificate could not be validated by a trusted root certification authority, so unless you removed some CAs you shouldn't ignore this warning.

This doesn't mean the certificate is expired, because if it would be expired ESS would (according to your settings, which are the defaults) block it without notifying the user, because the certificate is invalid.

 

If this only happens at yahoo.com then please export the certificate (click on cornet.yahoo.com in the popup and go to "Details", "Copy to file") and post the file here.

If you know how to do it you can also compare the hash of the certificate with the ones I linked below. I have visited the site you posted in your screenshot and the connection wasn't refused (of course not, that's yahoo..) and uploaded the correct cert here: https://mega.co.nz/#!jRhwlRyS!MonUypyjN5qIa1wzJ3Pua9ERABdQBjFLa0mC9n81dkE

 

For the ones who don't want to wait here is the hash: ‎4e eb 31 09 63 39 4e 8e a0 4e 70 9c a9 1d cd a6

Edited April 19, 2015 by rugk

[itman 1,659]

I just checked domain comet.yahoo.com at Quals. Its thumbprint is 45a7c9c571177f12486686dd53c0f08ec7efa31f

 

Here is a screenshot of the original cert. with its thumbprint.It is clearly expired:

 

 

Eset forum will not let me attach the actual .cer file

 

What I figure is going on is AT&T hasn't updated its cert server with the correct certificate.

 

The thumbprint you posted is for the root CA cert.

 

-EDIT- Had a "brain cramp" when I originally posted this ......... Attached is a zip folder containing the cert.

comet.yahoo.com.zip

Edited April 20, 2015 by itman

[itman 1,659]

A bit more info on this incident.

 

I checked the source code on my browser home page and the actual connection was to a sub-domain: https://comet.yahoo.com/comet.

 

Also this web site cert was expired since April 10 and I was only alerted to a problem by Eset on April 19. I believe also that the only reason I was alerted was because there finally was finally an issue with the cert path validation. I consider this a serious problem with Eset since I can no longer trust that it will properly verify the web site certificate when the SSL protocol scanning option is enabled. 

[Marcos 5,070]

...consider this a serious problem with Eset since I can no longer trust that it will properly verify the web site certificate when the SSL protocol scanning option is enabled

ESET clearly says that the certificate is untrusted so I don't see a reason why not to trust this information. The only question is whether the fact that the connection wasn't blocked and you were asked about the certificate is a bug and this will need to be answered by our engineers before we can comment on it.

[itman 1,659]

Elaborating on my initial posting, I believe Eset SS is presently working as designed. Quoting the documentation manual when you select "No" from the initial untrusted certificate prompt, the following occurs:

 

1. "Marks the certificate as untrusted for the current session - the alert window will be displayed on the next attempt to use the certificate.

 

2. "You can select Block communication that uses the certificate to always terminate an encrypted communication to a site that uses the unverified certificate.

 

The connection is indeed being blocked, but only for this specific instance. Hence, when the web page again attempts to access the bad cert, the whole process repeats. In my instance, the web page was repeatedly trying to access the bad cert and I was stuck in a loop.

 

My recommendation is to add the following:

 

1. An "Untrusted" section to the existing "Trust" and "Exclude" sections where bad certs would be stored.

 

2. Add a "No, always" option to the existing unknown/unverified cert prompt. This will mark the certificate as untrusted for all sessions and will add it to the list of untrusted certificates - no alert windows will be displayed for untrusted certificates. All communication using this certificate will be automatically blocked. 

 

Additionally, I recommend Eset provide wording on the initial SSL warning window to click on the shown cert name to determine the issue with the cert. The average user would not know to do that.

Edited April 21, 2015 by itman