Excel plug-in unable to connect over https

[nlmave]

Description

During use on one of our training locations, it turned out that COMET-IME was able to connect to the COMET server over https without any problems, however opening the Excel plugin on that very same PC, did NOT allow access to the same server over https with the same credentials. We had to resort to temporary access from the Excel plug-in over http to move forward. The incident was orally reported to RHEA and even on-the-spot consultancy from the RHEA team did not unveil the issue. This ticket is a write-up of that discussion, analysis, and potential fix.

We were suspecting a security setting deep in dotNET itself, that may affect the behavior of strong encryption use from Excel COM based plug-ins.

Steps to Reproduce

After weeks of debugging and testing we finally found a potential root cause; it seems that the following registry settings are needed / forced, in order to allow the Excel plug-in to work:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Kudos to our colleague Ferry Steenvoorde for untangling this mystery.

It is recommended that RHEA checks (the proper use of) this registry setting and if possible enforce it in the tool installer for the Excel plugin. Note that this applies to COMET IME v9.2; it may be different for COMET IME v9.4 as this is using a different dotNET version. We will cross-check once we deploy v9.4 on our infrastructure.

Logs

• [x] There are no logs regarding the issue

System Configuration

• COMET version:

  • [x] COMET-IME: 9.2 (used natively on client OS, without Citrix remote hosting)

• Web Services:

  • [x] CDP4/COMET Web Services version: 7.1.1 (running on Linux)

• Environment (Operating system, version and so on):

  • [x] Microsoft Excel (32/64 bit): Office 2016 64-bit
  • [x] Windows OS (32/64 bit): Windows 10 (latest patches)

[samatstariongroup]

@nlmave we've had a similar issue on our end, so this input is super helpful,l, we'll work on a solution for this

[nlmave]

Not quite sure what was done to fix this problem? I got reports from another user experiencing this issue, so I have at least two leads where a solution can be independently verified.

[lxatstariongroup]

@nlmave we added the "SchUseStrongCrypto" registry settings to the CDP4-COMET installer. We also experienced the same behavior described in this issue and it was solved by adding the registry settings for "SchUseStrongCrypto". So now .Net uses TLS 1.2 by default.

[nlmave]

Good to know! I will inform stakeholders to test the 9.5 release.