Along time ago, I started to use eBlocker in the form of the white cube. When the cube failed to accept a further update I installed the eBlocker software on a Raspberry 4 and continued my computer life with this eBlocker. Then I learnt to reactivate the white cube by installing an SD-card and returned to the cube. Since then I keep both eBlockers up-to-date (the Raspi as a spare fall-back version). Presently, eBlocker’s OS version is 3.0.2.
Now to the reason for this mail:
Last month, I transferred my mac-system from an iMac 27“ (Big Sur) to a new Mac Studio without observing any security problems as regards the eBlocker.
Today I was surprised when I realised an astonishing discrepancy of facts between the Dashboard (Bildschirmfoto 2024-01-27 um 18.15.39) and the „Schlüsselbundverwaltung“ ( Bildschirmfoto 2024-01-27 um 19.21.49 Kopie).
Whilst the Dashboard appears to indicate that the eBlocker certificate is missing, the „Kopie“-screenshot of the „Schlüsselbundverwaltung“ confirms its presence.
This contradiction of facts applies not only to macOS „Sonoma“), but also to my iPad Pro (IPadOS 17.3) and my iPhone (iOS 17.3). I found this discrepancy in both browsers (Firefox 122 and Safari 17.2.1 on the Mac, and the newest version of these browsers on my iOS and iPasOS devices).
Hence I assume that in the new OS of Apple some changes were made, so that the Dashboard program does not continue to work properly in the present Apple OS Sonoma, iPadOS and iOS,, as demonstrated in its „HTTPS support“ and its Function test“ fields.
Any try to install the allegedly missing certificate by means of the HTTPS Assistant failed. I hope that these details will help to remove this apparent bug.
Kind regards
Fr_Al
@adaeweritzt-online-de Thanks for your post.
Unfortunately I have no idea about macOS. Generally the eBlocker certificate needs to be granted CA or root status to work properly. See here for the process https://eblocker.org/en/docs/how-to-add-the-eblocker-certificate-in-macos/
Especially the "Always Trust" setting for SSL is important. Please double check this is in place.
It would be helpful to see the eBlocker certificate settings (same as you show the fritzbox certificate - probably accidentally in the last screenshot).
Just a remark: I'd stick to the Raspi 4 as it's much faster than the White Cube and we'll probably phasing out White Cube support during this year.
THX!
The certificate seems to be installed correctly, because in the dashboard screenshot there is a green checkmark at the function test "Web filtering with HTTPS".
However, the test for the certificate's existence that shows the red checkmark uses another URL with an unusual port number (3001). Either the service on this port does not run any more on the eBlocker or the connection to the port might be blocked on the clients.
You probably already rebooted the eBlocker? That should re-start the service on port 3001.
Does the problem also occur on Safari on macOS?
On my Mac with Sonama I can not reproduce the problem.
Thank you Boris and Random for your advices. In fact, after having restarted my white eBlocker, everything was in order again after a long-lasting updating to version 3.02 which started by itself (a previous updating to version 3.02 apparently had not been successful).
Apart from this success and following to Ramdom's advice, I then sent my white eBlocker into retirement and replaced it by a Raspi4 based eblocker version.
Thank you again, Fr_Al