none
TLS error on specific website for a specific user RRS feed

  • Question

  • I have a user that is getting a TLS issue on a specific website (allscripts.com) on all browsers (IE, Chrome, and Edge). The default browser used is IE, and when the browser is complete reset then the TLS error goes away (2/3 of the time).

    All of the TLS options are checked in IE (those are set by group policy), which all you see when you google search this issue. It is also not our ISP since the only user/PC that is affected by this. Other users on Windows 10 can get to the site without issue. Everything is up to date, and the user is running the latest version of Windows 10. Any help, tips, or answers are appreciated. 

    Wednesday, June 6, 2018 2:28 PM

Answers

  • Hi,

    first go

    Tools>Internet Options>Advanced tab, check "Always record developer console messages.". Save changes.

    then open IE at a blank page and press f12 to display the dev tool... select the Console tab.

    Next type in the web address for Allscripts.com (they use geo syndication to serve up different hosts. see the Region dropdown on their site). and observe the error messages and warnings that are now listed in the dev tool console.

    It should now list the external host that is causing the cert error as well as blocked content (Tracking Protection and ActiveX filtering).

    SEC7114: A download in this page was blocked by Tracking Protection.
    xxxs:// googleads.g.doubleclick.net/pagead/viewthroughconversion/922016982/?random=1528327860696

    Observe if the user has turned on Tracking Protection and ActiveX Filtering and check that Allscripts is mapped to the Internet zone (not the Trusted zone) from the File>Properties menu in IE.

    Turn them on/off by clicking the blue circle indicator in the IE Address bar (the page will refresh) and observe the output in the Console tab of the dev tool again.

    Next go Tools>Manage Addons>Tracking Protection lists and see which Tracking Protection lists the user has installed.... compare their list with other users installed tracking protection lists. I expect that they will be using different lists to the problem client machine and their tracking protection lists is for a region other than the US.

    If the user has an account with Allscripts, make sure

    1. they have been automatically logged in.

    2. they have not placed Allscripts.com in their Trusted sites list. (you should replace h t t  p s://allscripts.com with *.Allscripts.com see h t t p s ://developer.allscripts.com/Account/Login

    I don't know why they also place google analytics on their login pages. you will have to ask them.

    You should test by running IE in InPrivate mode which will stop the site reading your users google account cookies.

    Regards.


    Rob^_^

    • Marked as answer by Derrell IV Tuesday, September 11, 2018 6:52 PM
    Thursday, June 7, 2018 12:17 AM
  • this article helped as well

    https://blogs.technet.microsoft.com/askds/2018/04/10/tls-handshake-errors-and-connection-timeouts-maybe-its-the-ctl-engine/

    • Marked as answer by Derrell IV Tuesday, September 11, 2018 6:52 PM
    Tuesday, September 11, 2018 6:52 PM

All replies

  • Hi,

    first go

    Tools>Internet Options>Advanced tab, check "Always record developer console messages.". Save changes.

    then open IE at a blank page and press f12 to display the dev tool... select the Console tab.

    Next type in the web address for Allscripts.com (they use geo syndication to serve up different hosts. see the Region dropdown on their site). and observe the error messages and warnings that are now listed in the dev tool console.

    It should now list the external host that is causing the cert error as well as blocked content (Tracking Protection and ActiveX filtering).

    SEC7114: A download in this page was blocked by Tracking Protection.
    xxxs:// googleads.g.doubleclick.net/pagead/viewthroughconversion/922016982/?random=1528327860696

    Observe if the user has turned on Tracking Protection and ActiveX Filtering and check that Allscripts is mapped to the Internet zone (not the Trusted zone) from the File>Properties menu in IE.

    Turn them on/off by clicking the blue circle indicator in the IE Address bar (the page will refresh) and observe the output in the Console tab of the dev tool again.

    Next go Tools>Manage Addons>Tracking Protection lists and see which Tracking Protection lists the user has installed.... compare their list with other users installed tracking protection lists. I expect that they will be using different lists to the problem client machine and their tracking protection lists is for a region other than the US.

    If the user has an account with Allscripts, make sure

    1. they have been automatically logged in.

    2. they have not placed Allscripts.com in their Trusted sites list. (you should replace h t t  p s://allscripts.com with *.Allscripts.com see h t t p s ://developer.allscripts.com/Account/Login

    I don't know why they also place google analytics on their login pages. you will have to ask them.

    You should test by running IE in InPrivate mode which will stop the site reading your users google account cookies.

    Regards.


    Rob^_^

    • Marked as answer by Derrell IV Tuesday, September 11, 2018 6:52 PM
    Thursday, June 7, 2018 12:17 AM
  • this article helped as well

    https://blogs.technet.microsoft.com/askds/2018/04/10/tls-handshake-errors-and-connection-timeouts-maybe-its-the-ctl-engine/

    • Marked as answer by Derrell IV Tuesday, September 11, 2018 6:52 PM
    Tuesday, September 11, 2018 6:52 PM