[Solved] eBlocker Status: exclamation mark for HTTPS

I‘m on eOS 2.5.8 and on all my devices (iPad & Win) the Dashboard check shows HTTPs green. So it‘s not a generic bug in the test process.

For me the test seems to work well (in my environment).

A good way to manually check if eBlocker HTTPS support is working (regardless of the Dashboard test) - here for firefox

1. Go to an https website, say https://test.de  
2. Click on the lock next to the URL (in the browser)
3. Click on > to get more info about the security of the connection
4. In the next screen it should read „Verified by“ - followed by the name of your eBlocker device. Followed by a message that the Certification Authority is not recognized by default - but that the certificate was imported by the admin. Then the certificate was installed properly. 

If instead it reads (with test.de) Verified by „GlobalSign ...“ - then the eBlocker certificate is not installed properly.

So you might want to run the test manually, to confirm the Dashboard test has a bug. So far we have not been able to reproduce this bug - if it exists... 

Any help is highly appreciated.

THX!

@random

Thanks for the swift reply! Appreciate it!

Tried to follow your instruction, but I'm stoked here:

"3. Click on > to get more info about the security of the connection"

(I'm using for the test my win10 machine and Edge)

Where is the " > " symbol to click on?

or maybe you can tell me how to check this on OS X Safari.

THX

BonyCB

@bonycb All good. I see the eBlocker icon shows up in the screenshot above which also indicates that the certificate is installed correctly in this particular browsers.

Are you sure that this browser shows the "exclamation mark" in the test? If so, can you please make a screenshot of the test results as well of the HTTPS support tile in the dashboard - and state exactly your OS and browser version.

Please refrain from switching browsers, devices etc. until we are finished with this browser on this device. Once this browser is "all good" we move on to tackle the rest 😉 

THX!

@random

Thanks Random:

Here a screenshot (side by side on Windows machine with running on Win10 Pro 20H2 with MS Edge) showing the requested information:

Same situation on on OS X Big Sur with Safari 14.0.2.

THX

BonnyCB

@bonycb I can not reproduce your findings.

My edge on Win 10 shows all green - incl. the standard HTTPS test:

Can you please click on "Zertifikat (gültig)" in your screenshot above. In the following window, check the tab "Zertifizierungspfad" and post results here:

And finally, can you please post the exact version of edge you are using (In the edge ... menu choose "Help & Feedback" and then "Infos about Microsoft Edge"). Mine reads: Microsoft Edge ist auf dem neuesten Stand.Version 88.0.705.50 (Offizielles Build) (64-Bit)

THX!

@random

Screenshot with all information you've pleased.

Thanks for digging into this subject!

BonnyCB

PS: Additional information:

I've also restarted the browser (as indicated in the notes of the exclamation mark) - even cleared the browser cage and restarted the browser - however, no change.

@bonycb Thanks very much for the feedback.

The good news: your eBlocker works fine - but just the self test fails for some reason.

The bad news: I can‘t reproduce the issue either and have no idea why the test fails in your environment.

Do you have any additional „blocking“, „safety“, „network security“ software/plugin or hardware in your network thats may be interfering here?

I‘ll bring up this topic in todays community meeting. Maybe someone else has an idea?

Thanks a lot for your help.

@bonycb I'm clueless too. Can't reproduce. 🤔 

As @benne said: Would be great to know if you are using additional tools/firewall/plugins etc.

You mentioned you have the same effect on macOS. Did you check the certificate chain as well (just to make sure everything is configured well)? I'm on Win so I can't help with Safari but the process is usually the same - click on the lock next to the URL and check for clickable certificate infos.

THX!

@random @benne

Thanks a lot for your effort! Yeap - it seems to be a quite challenging topic!! But honestly, I this exclamation issue in several posts - so I wouldn't be surprised that other user have same issue, but maybe they're not looking too much on that (just a guess).

Regarding your questions: nope - I don't have a specific environment. Standard one (FritzBox 7490, WLAN-Bridge with FritzRepeater - FritzBox and FritzRepeater in Mash configuration - and devices connected via LAN and WLAN; DNS runs on eBlocker, IPv6 shut disabled on FritzBox). There are also no special blocking/safety/network security hard or software installed. I just have the Bitdefender internet security on my win and OS X devices. So very standard setup.

As mentioned, this behavior started with the update from 2.5.6 to 2.5.8:

Posted by: @bonycb

I made a stepwise clean install, meaning that I dowloaded the 2.5.6 version, set up this version without updating it to 2.5.8. Result - no exclamation mark for HTTPS on all my devices. Everything perfect! Yuppie!! Then, after the update to 2.5.8. it appeared again.

On following the screenshots from my OS X device - Big Sur 11.1 and Safari Version 14.0.2 (16610.3.7.1.9):

So, since with eBlocker version 2.5.6 I didn't had this topic (unfortunately I did not made a screenshot prior update during my clean install), to me it can't be related to something else rather than to the update to 2.5.8.

I like to support as much as I can, so please tel me what else you would need form my side.

Cheers

BonnyCB

PS: Yesterday I reinstalled a new HTTPS certificate to all my devices, just to be sure that nothing went wrong with the initial certificate right after the clean install of the eBlocker, but it didn't helped.

@bonycb

Hi BonyCB, I have the same problem. Is there a solution in the meantime?

Many greetings,
Zilia

@zilia @bonycb For some reason it seems the test is not working properly, even eBlocker works fine (at least for @bonycb). Unfortunately no one in the eBlocker team can reproduce this test fail issue.

I fear unless we find a way to reproduce it we need to leave it "as is" for the moment.

THX!

@random Reading through the posts, I've found one difference in the screenshots of the eBlocker status self tests. In my screenshot as well as @Zilia 's screenshot I see a check for "Web filtering (HTTP)" followed by the "Web filtering (HTTPS)", while your screenshot shows only "Web filtering (HTTPS)" check.

My screenshot:

@Zilia screenshot here  Status display problem/question:

your screenshot in this post:

Could that be a hint to get this traced up and potentially reproduce this in your machine environment?

THX

@bonycb Very good eye! 😉 

I've talked to @bpr and he told me that if HTTP and HTTPS tests are both passed, it will just show "HTTPS pass" (but no extra HTTP item). So unfortunately this is not leading to more info about the cause.

@bpr has some ideas what's going wrong and will check them as soon as 2.6 has been released (by the end of this month, we hope).

So for now unfortunately we have to live with the fact that the HTTPS test fails even everything works well. Sorry for the irritation... 😥 

Thanks very much for your great support in narrowing this issue!

@bonycb

On macOS, you could try this test in the Terminal:

/usr/bin/curl -i  https://setup.eblocker.org/_check_/routing 

The expected result (for the HTTPS test to be green) is "204 No Content", which is returned by eBlocker.

If HTTPS via eBlocker does not work, you would get "404 Not Found" from the server setup.eblocker.com.

@bpr

I did the test as mentioned.

Here the result:

HTTP/1.1 404 Not Found

Date: Thu, 04 Feb 2021 11:58:49 GMT

Server: Apache

Content-Length: 265

Cheers

BonyCB

@bonycb

Hm, that means the request passes through eBlocker.

Is the domain eblocker.org maybe on any blocking list or the HTTPS exemption list (go to Settings / HTTPS / Trusted Websites and search for "eblocker.org")?

Does the routing via eBlocker work? For example when you run the following in Terminal you should see eBlocker's IP address at the top of the list:

traceroute -n 1.1.1.1

@bpr

here my entry in "Settings / HTTPS / Trusted Websites" using "blocker.org" as search keyword:

And the entry using "eblocker" as search keyword:

Result after typing

Posted by: @bpr

traceroute -n 1.1.1.1

in my terminal shows the eBlocker IP as first entry followed by my FritzBox. Last entry (entry no. 7) is the 1.1.1.1 DNS server.

Cheers

BonyCB

@bonycb

OK, thanks! The problem is that if "eblocker.org" is a trusted website, the test URL https://setup.eblocker.org/_check_/routing can not be intercepted by eBlocker.

(All sub-domains of a trusted domain are also trusted automatically.)

If you disable the trusted website, the test should be OK.

@bpr

Great! it worked! I deleted the blocker.org entry and everything good now:

Thankx @bpr!

In order to get that situation understood: Why did it worked in eBlocker 2.5.6, resp. why eBlocker 2.5.6 didn't had that issue?

Cheers

BonnyCB

@bonycb, great that we found the cause of the problem.

In 2.5.6 the test was still using the eblocker.com domain. It changed to eblocker.org in the 2.5.8 release.

@bpr

Thanks for the explanation!

That make sense!

I recall that I manually put the eblocker.org on the thrusted websites last year, since the eBlocker 2.5.6 and below didn't opened the eBlocker.org --> indicating an issue. So I did a manual HTTPS recording of my machine to identify the correct URL and place it there.

After I reacently did the clean install to 2.5.6 in order to understand the issue, there were no user entries in the thrusted websites and apps. So the test went well. Than, I updated to 2.5.8 and made a restore of the setting I saved prior clean install. Doing so my eBlocker entries in the trusted websites and app were back again and the HTTPS selftest failed again.

Yeap - clear now! THX once again!

Cheers

BonyCB