RESOLVED ISSUE

This article references an issue that has been resolved in the latest fixpack of DotImage

The latest update is Tuesday November 14 2022, 12:00 EST

The issue for this issue in Chrome (for Windows) is resolved in 11.4.0.4.0.328 (DotImage 11.4 FixPack 4) which is available for immediate download on our special support site:

The the first version to have this fix is 11.4.0.4

However, we always recommend the very latest at our official downloads page

NOTE the NuGet/NPM packages can trail by up to 2 weeks, so it is advised if you're looking for an immediate fix, you should use the direct download/install SDK

HOWTO: Upgrade / Update DotImage - Including Web Apps Using WebDocumentViewer and/or WebCapture

If you run into issues with the upgrade, please create a support case

ALSO NOTE: Chrome browser is not OFFICIALLY supported on MacOS - the current recommendation is to use Safari on MAC. We are planning to update the WebCapture MacOS pkg in a future release.

Background

Beginning with Google Chrome version 105, Google began rolling out with a partial/selective roll out of their new Google Chrome Root Store

In essence, up until then, Google Chrome would rely on the same Secure Certificate Root store that the Windows operating system used. As of the roll out, Google is slowly publishing a new certificate root store of their own. The issue has been particularly vexing to us and our customers and their users as there is no direct outward indication that 2 different computers - one of which is having an issue and another which is not - using the exact same version number of Google Chrome - are actually differently configured

We had a false start with this, believing it was due to a different change that Google is also (coincidentally) about to roll out / has just rolled out.

For more on that, please see

INFO:Changes to PNA (Private Network Access) in Chrome 107 and Later

Atalasoft has determined that the root store and PNA changes are separate, distinct issues. We were aware of and had planned for the PNA changes and if you're using at least version 11.3.0.3.0.730 or later, you won't be affected by that issue.

This is about a new and evolving issue having to do with Google's roll out of their new Google Chrome Root Store.

Current Issue

As of Google Chrome 105, users are starting to be switched to Google Chrome Root Store for secure certificates on Chrome. Unfortunately, the current certificate we use to sign our WebCapture Service is not honored by that new Root store and is causing errors for some, but not all users.

The complication about "some, not all" is again due to Google rolling out the change to an increasing number of users, slowly in what is called blue green deployment. As time goes on, more and more users will silently be switched to use the new Root Store and when this happens, the WebCapture Service will stop working.

There is currently no easy way to directly check the version, but a user who suspects they are running into this issue can use the following "sanity check"

The WebCapture service runs a small REST-ful service on the local machine - either per user or as a system service. It runs on 127.0.0.1 (localhost) and has both HTTP and HTTPS versions to allow it to function without warnings for HTTP and HTTPS sites

This service runs at

HTTP
http://127.0.0.1:23023/sessions

HTTPS
https://127.0.0.1:23024/sessions

If you have the WebCapture Service installed, you can "sanity check" if your Chrome / Edge is having an issue with it by hitting the HTTPS URL

Success will respond with a simple JSON either Empty [] or with an array of integers [ 123456789, 987654321, etc... ] and there will be no security warning or issue with the certificate when served via the HTTPS link

If your run this on your machine and get any errors you may well have an affected version.

However it's not entirely deterministic. This is because Google has also started (as of version 107) rolling out their new PNA (Private Network Access) change which requires that a specific header be sent in our response. This issue is corrected in 11.3.0.3.0.730 and newer.. but if you have an older version of WebCapture Service on your machine, you may well be hitting that issue instead of this one.

The best course of action is to apply the 11.3.0.3.0.730 or later fix for that known issue first and re-test - come back to this article after verifying that you've got an updated client.

Workaround

The good news is that there is a workaround for the current issue. Earlier attempts to address it required that an affected user completely uninstall Google Chrome, delete their Chrome user data folder then reinstall. This was not a reliable fix though as it still relied on being in the "lucky" green blue rollout group that still used the old Windows Root Store.

There are two viable workarounds - the first is adding a command line switch to your Chrome shortcut

The benefit of this is you can use it to quickly enable/disable the Chrome Root Store in your current window to  switch between enabled and disabled modes so that you can test/repro. It may also be useful to have a means to change the behavior / apply the workaround for users who are locked out of making registry changes.

These method is provided by Google and will be allowed/usable until Google Chrome 111 which - we do not currently have a date for, but based on roughly monthly updates should be sometime in early Q2 of 2023

Command Line Switch

DISABLE Chrome Root Store (workaround)

add the following command line flag to your shortcut used to start Chrome

 --disable-features=ChromeRootStoreUsed

example:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-features=ChromeRootStoreUsed

ENABLE Chrome Root Store (repro)

add the following command line flag to your shortcut used to start Chrome

 --enable-features=ChromeRootStoreUsed

example:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --enable-features=ChromeRootStoreUsed

More Reading

You can read more about this option in the Chromium Source Blog

Windows Registry Settings

The workaround is applied via a Registry setting in Windows

• Open Registry Editor
• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
• Add a new DWORD with the name ChromeRootStoreEnabled
• set its value to 0
• Close the Registry Editor
• Restart Chrome

More Reading

You can read more about this setting on the Chrome Enterprise Site

MacOS Chrome Setting

NOTE: Safari is the only browser we officially support in MacOS. The following is provided as-is.

The setting name is ChromeRootStoreEnabled

the value to set it to is <false />

Since Chrome is not supported, the official stance is to use Safari on MacOS

FINAL NOTES

The issue has been addressed for Windows users of Chrome in the latest 11.4.0.4 release (noted above)

For MacOS scanning: Safari is the only browser on MacOS that we officially support. However, We are planning to add a fix for the MAC version of Chrome in a future release.

For users of MacOS scanning running into this issue, the easiest workaround is to use Safari. If you would like to be notified of a future fix for MacOS scanning please create a support case and ask us to be added to the notification for MacOS fix for WebCapture Chrome Root Store issue