Documentum – ActiveX error 12019 in D2-Config during export

Some months ago at a customer, we started the rollout of some security baselines on a new application (not yet productive). One of the changes was to enforce the use of TLSv1.2 on all our Documentum Clients like D2/D2-Config (4.5, 4.6, 4.7), DA (7.2, 7.3), aso… TLSv1.2 was already enabled before that but there was also a fallback to TLSv1.1 or 1.0. For Security reasons, at some point you will need to ensure that TLSv1.2 only can be used because the previous versions contain vulnerabilities… Obviously, there were some testing and validation to ensure that Documentum DFC Clients could handle the TLSv1.2 and everything was working properly.

A few days later, we started to receive a few tickets from developers that couldn’t export the configuration from D2-Config with an ActiveX error 12019:

The strange thing is that this looked like a random issue because on some workstations, it was working properly and on a few others it wasn’t. We took for example two Windows 7 workstations with the same OS and patch level, with the same ActiveX, with the same Browser (IE11 with TLSv1.0, 1.1 and 1.2 enabled) and the issue could only be seen on one of the two workstations.

After more tests, it appeared that the issue could only be reproduced when the D2-Config was using TLSv1.2 and that the client workstation was a Windows 7 or Windows 8 (but not for all workstations…). For W8.1 or W10, it was always working.

So looking into this, we found on the Windows support site a registry that could help. As described in this webpage, when an application specifies the “WINHTTP_OPTION_SECURE_PROTOCOLS”, the OS will check for a value in the registry and use it if present. If the registry entry isn’t present, it will then use the OS default value which is specified there: for Windows 7 and 8, only SSLv3 and TLSv1.0 are enabled and for Windows 8.1 and 10, SSLv3, TLSv1.0, TLSv1.1 and TLSv1.2 are enabled.

The registry to edit can be found here:

• 32 bits OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
• 64 bits OS: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

At this location, you will probably not have much keys so the one to add to control this behavior is “DefaultSecureProtocols” (DWORD). As mentioned on the Microsoft website, the possible values are as follow:

With these values in mind, you can do some simple additions (in hexadecimal of course) to enable several protocols. So for example:

• Enabling TLSv1.1 + TLSv1.2 => 0x00000200 + 0x00000800 = 0x00000A00
• Enabling TLSv1.0 + TLSv1.1 + TLSv1.2 => 0x00000080 + 0x00000200 + 0x00000800 = 0x00000A80

In our case, IE11 supports from TLSv1.0 onwards and therefore we enabled the same for the “DefaultSecureProtocols” registry, to avoid possible issues with other/older applications. Since we restrict the use of TLSv1.2 on our Documentum DFC Clients, the end-user workstations will not have the choice to use weaker protocols so we are on the safe side for our applications. After doing that, all Windows 7 workstations (without exception) were now able to export the D2-Config configuration without issue.

Note: All W7 workstations were all part of the same domain with the same setup, the same GPO and without admin rights for the end-users so this registry wasn’t setup at all… Yet the issue was only on some Windows 7 workstations and it is still unclear why… There must be a difference somewhere but we still didn’t find it. That’s why this registry will only be packaged as a fix for the workstations were the issue is present and until everybody is moved to Windows 8.1 or later.