TurboActivate 5.0.2.0 TA_E_INET_TLS - Unknown CAAnswered

  • TurboActivate Version: 5.0.2.0
  • Windows Version: Windows 11 Build 26200 (Insider Preview) (but also with 26200.7171 and probably other Windows versions)
  • Error: TA_E_INET_TLS (0x24 / 36)
  • Packet Capture: Server returns TLS Alert 48 (unknown_ca) in response to Client Hello
  • Testing Results:
    • ✅ Native Windows TLS 1.3 connections work (PowerShell Invoke-WebRequest succeeds)
    • ✅ OpenSSL s_client connects successfully with TLS 1.3
    • ✅ TLS 1.3 is enabled in registry (HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client)
    • ✅ WinHTTP DefaultSecureProtocols set to 0x2800 (TLS 1.2 + 1.3)
    • ✅ TLS 1.3 cipher suites available (28 total)
    • ✅ ISRG Root X1 certificate installed
    • ✅ Windows Defender disabled during test - no change
    • ❌ TurboActivate fails with TA_E_INET_TLS

      I have a WireShark capture from that exchange, but it's very straightforward. Connection is initiated as Client Hello TLS 1.2 with supported_versions set to TLS 1.3, the server sends Server Hello, Change Cipher Spec and the client returns Unknown CA in response. 

      It happens on three separate machines in different places in Poland and one in Peru without any VPNs, proxies, etc. on the way. We tested it and get consistent failures.

      It used to work before with the same code, the same configuration on the same machines in the same locations, the same TA lib version. 

      We are using static TA lib on Windows.
ago, edited ago
Answer

To whomever has the same issue in the future:

This was caused by the mismatch of libCurl between our app and TurboActivate. If you embed or distribute your own Curl dll, make sure to build it without OpenSSL, because TurboActivate expects it to default to Windows Secure Protocols and will crash when OpenSSL is used instead. 

Thanks for no support whatsoever on this issue.

ago

Sorry, about not responding. This one got lost in the shuffle (long holiday weekend).

But yeah, our default response to using static libraries is to not do it: “Don't use the static library, only use the dynamic library!”


Why? For exactly the issue caused here: it's extremely hard to ensure other static libraries don't clobber what we need and expect.

ago
Reply
Discard post