COStark26

Thanks itman and BeanSlappers for the security warning and Refresh suggestion. What Refresh involves in deletions would - for fixing just One Site - insure the most fun suicide I could conceive. Won't go through that reconstruct if about:config mods are so affected + Addons Re-install.. I'll return to SSL Filtering and see if the same oddity that caused this reverses itself later. Normal Mode will do for now. All the Best to you both, and Marcos. EDIT: Just Re-Set Back to SSL ON and Hancock Loaded Again in BPP. Next 2 Tries Failed. Oh, Well! Normal it is ........... Thanks again! EDIT: 7/17 It appears that IF I Un-Chk SSL Filtering, close ESET, Re-Open and RE-Chk SSL, Hancock Opens as many times as I try IN THAT SESSION. Close FF and re-open and the Error Returns. When really necessary, I'll do the extra steps to Open in BPP

..... used it in BPP prior without issue and CAN access it in Normal. A FF Forum "expert" suggested Disabling SSL Filtering in ESET and THAT WORKED. OK to leave SSL Filtering UN-Chk'd?

Thanks for the Replies. I DID have -- www.jhannuities.com -- Setup in BPP -- and used it in BPP prior without issue, and CAN access it in Normal. I just tried a Test FF Profile and got the same error, but it Helps that Marcos Did get the page in BPP. Will try in a FF Sppt Forum I use and see what happens.

John Hancock (financial) main web site ....... https://www.jhannuities.com/ --- loads as ----- https://www.jhannuities.com/Marketing/default.aspxMarketing/default.aspx The BPP Screen IN Firefox 68 now shows -- Secure Connection failed ----SEC_ERROR_BAD_SIGNATURE --- and a created FF Tab ESET page suggested Clearing FF Cache, DISABLE BPP, Re-Start Computer (which auto-enables BPP again) and Try ...... SAME Error Msg. I also (SSL/TLS) Un-Chk'd Exclude Communications w/Trusted Domains = No Help. Any suggestions appreciated.

Not crucial to the issue BUT - I read 6:00:15 PM to be 6 PM - 0 Minutes - and 15 Seconds (ie) 15 seconds past 6 PM. No? Hopefully Marcos, etc., will just clarify that the Scheduler Will Never recover a Missed Scan after a Sleeping computer (at the scan time) wakes up. Many can accept a fact; It's the Not Knowing /keep trying - failing that drives you crazy.

https://support.eset.com/kb3207/ Steps 6-7-8 show what I suggested you try; #9 shows In-Depth Scan but you should configure as desired. IF this Fails then Marcos can tell the staff the K-base Instruction fails and to help with a Fix / different settings instruction.

Forget the MBAM item; Just to show Recovery logic is problematic in other places. Main idea was to TRY the 24 hour number Vs your Immediately If last run exceeds 1 hour. Itman may be on to something in above post about Sleep and ESET clock re-sets - but were it me I'd try the 24 hour setting I suggested JUST to say you tried what MATCHES the ESET K-base Instruction.

Since you're not getting anywhere, and this is pure SWAG logic ..... is there away you could let it Run a Scan by Schedule at 1800 on a Monday and set the "Recovery if missed " for - Immediately if last run exceeds 24 hours / Not 1 (as shown in K-Base example for a weekly Friday scan). Make sure it's asleep at 1800 the next Monday and then wake it up anytime after & see what happens. Maybe there is some quirk in the coding logic that wants the "Exceeds #" for Last Run (on a Missed Scan) to be 24 hours (24 Hours + 1 second would be required to MISS a Daily Scan) Vs 1. This Schedule logic contradiction thing is a wide-spread issue. The MBAM Setup screen can show - Recover if Missed by 1 hour - ( implies IF the computer wakes up at "8:00:01 or after" Following a Missed 07:00:00 Scheduled Scan, then Scan.) But 2 Clk's backing out to the Review Screen shows - "Run again Within 1 Hour of Last Miss (implies 07:00:00 asleep / IF the unit awakes between 7:00:01 and 8:00:01 Run the scan. If it doesn't, then DON'T Scan. HOW is that for clear Recover logic? Hope the above works. Nothing to lose. Or try the -Immediately if last run exceeds 24 hours - on a Temporary Daily Schedule and see if 24 works there - to find out quicker.