Cannot activate/deactivate (TA_E_INET_TLS) on macOS 10.14 and olderAnswered

Hey Philippe,

We answered about a dozen of the same email yesterday and this morning. Sorry if yours got lost in the shuffle.

Long story short: this is an Apple bug. They fixed it in 10.15 and newer.

Solution: update to macOS 10.15 or newer.

Is the customer being difficult and says they can't update because “updating might break things” (and don't realize the irony that not updating will definitely break things *plus* put their data at risk for ransom). Then, have them update their CA certs. Which CA certs? View our website in a modern OS with a modern browser and you'll see the ones you need.

Will using an old version of TurboActivate fix things? No.

Well… yes, for about a week and then things will go off the rails in new and spectacular ways. So, don't do that. (Trust me, things will go bad for those customers). Use the latest TA (currently 4.4.4) and have then update their OS or update their CA certs.

In summary: this is an Apple bug that Apple fixed. Update the Apple products.

---

Future people viewing this topic after 2021: this topic doesn't apply to you. View the FAQ on this topic (TA_E_INET / TA_E_INET_TLS) for help.

Thank you for your answer. 

First of all, a third of our users are still using macOS 10.13 or 10.14 (2017 or 2018). I can ask them to upgrade their OS, but a lot won't be able to do so within one week (some machines are simply offline running shows in several towns for example).
So I've to find a solution for them, whatever it is.

Secondly, what do you mean by “yes, for about a week and then things will go off the rails in new and spectacular ways (Trust me, things will go bad for those customers)” ? Do you mean macOS 10.14 will be broken very soon ?
The new "IdenTrust Commercial Root CA 1" certificate is installed on macOS 10.12.2 and above, so the problem should affect only older macOS. At least, this is what is told by people for one year.

Thirdly, why other licensing systems (such as DigitalRiver) are not affected ? Because they use another certificate provider than LetsEncrypt ?

Lastly, why TA 4.0.9.6 is working right now, but TA 4.4.4 don't ? Why TA 4.0.9.6 will stpo working suddently in one week or so ?

Thank you for your accurate answers to my 3 questions (in bold). This is very important, it's a matter of days from what I understand.
Of course, if you wrote some documentation about the issue, feel free to point it out.

Lastly, why TA 4.0.9.6 is working right now, but TA 4.4.4 don't ? Why TA 4.0.9.6 will stpo working suddently in one week or so ?

Because it’s vulnerable to the exact same Apple bug. It just appears at a different time.

Plus you’re dealing with 5 years of bugs (security and otherwise) that we’ve since fixed.

And, you’re running into a world of broken behavior by downgrading activation data from a newer version to an Older version.

Short answer, don’t do it. Trust us.

Regarding this Apple bug: if they don’t have a fix for their software by Friday next week we’ll release a workaround. We might just make the workaround regardless, because it’s become evident they have flaky support for some of their built-in functionality.

(No, it won’t come sooner than Friday).

In the meantime the options are:

1. Update to macOS 10.15 or newer.

2. Use offline activation.

3. Update the CA certs in the machine (no, we don’t provide tutorials for that).

Hey there! First of all, thank you for creating LimeLM and responding to this problem quickly.

I just tried out TA 4.4.4.1 on macOS 10.9 and the new version crashes when calling TA_PDetsFromByteArray. The only change to the code was swapping out libTurboActivate.dylib. Here's an abbreviated stack trace:

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libTurboActivate.dylib        	0x00000001012e2030 0x1012bb000 + 159792
1   libTurboActivate.dylib        	0x00000001012e1132 0x1012bb000 + 155954
2   libTurboActivate.dylib        	0x00000001012e19d1 TA_PDetsFromByteArray + 82
3   com.Paracosm.Lumen            	0x0000000100e4ba36 0x100e22000 + 170550
4   com.Paracosm.Lumen            	0x0000000100e488c2 0x100e22000 + 157890
5   com.Paracosm.Lumen            	0x0000000100e47204 0x100e22000 + 152068

Is 10.9 still supported by LimeLM in TA 4.4.4.1? We're in an industry (real-time video tools) where requiring users to update their OSs is not an option, so LimeLM's broad OS version support remains a key selling point for us.

FWIW, it does not crash on 10.10 or 10.11, although it doesn't work either (presumably because Apple needs to patch those OSs). I can hopefully point my customers to workarounds for that, though.

Thanks again!

TA / TF / TFS have required CPUs that support at least SSE4.2 since we've release 4.4 of our software.

See here.

This means if the CPU is older than the year 2008 and they're on macOS, Linux, BSD, they'll get a crash.

On Windows it will work, because Windows has more flexible compilers.

That customer might consider leaving the Apple ecosystem and switching to Windows – Microsoft supports hardware for an insanely long time. Apple stops supporting hardware after 5 to 6 years. The fact that they're on macOS 10.9 is a real problem (whether they acknowledge it or not).

So, yes, TA / TF / TFS will work on macOS 10.9 ... if the hardware isn't ancient.

Ah, thanks for the info! That makes total sense, since we were previously using 4.3, and I was using this page to see if the requirements had changed, which looks to be out-of-date.

The requirements page is correct. We just now also require a non-ancient CPU. We still support macOS 10.9 if it’s on a CPU from 2008 or newer.

We are having similar issues for our end users because of the DST Root CA X3 expiring.

Our issues are NOT with the Operating Systems but because of corporate firewalls, such as Sophos and Fortinet.

These firewalls have rules that the whole certificate chain has to valid and as part of the wyday cert has DST Root CA X3 no traffic can go out through the fire wall.

What might be easier for everyone involved is that wyDay go and purchase and implement a new certificate that doesnt have DST Root CA X3 in the certificate chain, would this be possible?

We've deployed a new chain where it doesn't cross-sign with an expired “root”.

So, things will continue to work correctly for correctly configured clients. And now also for broken devices.

awesome, i can confirm that DST Root X3 is no longer in the wyday.com cert chain

Can you let us know what time you implemented this new cert please?

Approx 45 minutes ago.

thanks for the info. panic over i hope :)

thought I should mention it….

Looks like you are fronted by Cloudflare.. might be worth looking into using their TLS/SSL end-to-end option (free), using a self signed certificate on the server. 

Perhaps this would remove a massive headache for you.

We considered it, for sure. But our infrastructure is more complicated than that and we need consistent TLS certs across the board.

thanks for jumping on to this so quickly. 

Have a good weekend

Many of our customers on older macs are now experiencing this.  I have read the FAQ and also upgraded the LimeLM libraries for mac to 4.4.4.1 — we have rebuilt our software using the latest libraries libraries.  

We have an old iMac OSX 10.13 “High Sierra” machine that we test our builds with.  They all install fine, but cannot activate, de-activate, or re-activate.  An error message that we wrote always pops up.  Unfortunately I cannot debug on the old iMac, so I cannot give you the exact error. 

I have upgraded the certs on my machine as per instructions, but alas, when I restart the machine after doing that it appears that it still does not take.

Is there any thing else we can do to aside from forcing the customer to upgrade their OS?

Thanks,
Arie

Are you using the keychain method? What is shown for the 2 Let’s encrypt certs after running those methods?

In my testing, I'm using the command line to add the .pem files.  After doing that, I cannot find anything in the “Certificates” tab in Keychain access related to “Let's Encrypt” is there a search term I should use to find it easily?

Ah, just found it finally.  The certs show:

---------------

ISRG Root X1

Root certificate authority

Expires: Monday, June 4, 2035 at 6:04:38 AM Central Daylight Time

+ This  certificate is marked as trusted for all users

-----------------

ISRG Root X2

Root certificate authority

Expires: Monday, September 17, 2040 at 11:00:00 AM Central Daylight Time

+ This  certificate is marked as trusted for all users

For the X1, what is the full chain in the Keychain (all the leaf nodes)? Does it include the expired root node?

What happens in Safari when visiting wyday.com?

Hi Wyatt, 

Thank you for the reply.  I'm not sure how to go about examining the “full chain” or “leaf nodes”.  Can you provide some pointers.  I know I can see details about the cert by double-clicking it's icon the Keychain.app but that's about it.  Can you offer a bit more direction to get at that information?

Thanks,
Arie

Hey Wyatt,

Sorry to bump this, but I need to figure this out before the week closes.

Thanks!

FYI, I have the exact same problem and am waiting for the fix on the issue.

https://wyday.com/forum/t/5064/cannot-activatedeactivate-ta_e_inet_tls-on-macos-10-14-and-older/#post-23553
 

https://wyday.com/forum/t/5064/cannot-activatedeactivate-ta_e_inet_tls-on-macos-10-14-and-older/#post-23305

my customers reported the problem and told them the solution you linked. But they are saying nothing is changed. So I have activated their license with offline activation.

Are they on a unsupported macOS version?

Are they using an updated TA?

Much more information is needed. This is a solved problem. Use a supported macOS and latest TA and it just works.

Hey Wyatt,

I've tried the steps for the certs in 10.13 and it still does not work even when using a build of our software with TA 4.4.4.1.  I sent over screenshots of the certs it installed but am unable to verify the “leaf” / “node” thing you mentioned.  Any other suggestions?

Thanks,

Arie

My guess is there’s another X1 cert installed with the expired cross-sign.

What happens when they access wyDay.com from Safari. What does the cert chain look like in Safari?

If they‘re an enterprise why are they running on a vulnerable operating system? And why are they connecting a vulnerable operating system to the internet?

Sorry about the confusion. I have confirmed on my macOS 10.13 that 4.4.4.1 works well. Previously I used 4.4.4.0 since I cannot link to the static library built in Xcode 13. As you mentioned, 4.4.4.1 have resolved the issue.

Please use 4.4.4.1. Its static library was built in Xcode 13. So, you need Xcode 13 if you build with the static library.

Thanks!

FYI, I installed freshly 10.13.6 and all available  macOS security patches.

Thank you for the follow up Seung-Jin, I appreciate that.  I double checked that we are building with TA 4.4.4.1 in our XCode 13 project.  

Maybe the freshly installed instance of 10.13.6 works, but it would be nice to get to the bottom of the issue for our users without upgrading

Wyatt, I sent screenshots of the way the certs look when visiting wyday.com — does that help answer any question?  Is there a way to “clear” the certs for wyday.com.

As far as the vulnerable OS question for enterprise — I think it's largely to do with the task that the machine is really intended to perform, which is just localized rendering.  Many of our customers relegate old hardware and OS's to singular, local, tasks and really don't use the outside network communication on those machines.  And it's also enterprise :) — they are slower to move.  Annoying, yes, but it's something we have to deal with. 

Hi, just following up here.  I sent updated screenshots of the certs on my old iMac running 10.13.6 — did that offer any help?

Nope, certs look fine. Try activating TFS 4.4.4.1 on that machine. If it succeeds then you're not integrating TA 4.4.4.1 in your app. Likely 4.4.4.0 or older.

Okay, I will try that and report back.  Thanks

Just tested TFS 4.4.4.1 on macOS 10.13.6 and it activated — our floating licensing build is capable of leasing and dropping licenses.  I'm not sure what the deal is, but I will triple check that we are building with the latest TA libs into our app.  Will report more.

Since TA 4.1 we've had the TA_GetVersion() function to get the version of the library at runtime (to reduce the guesswork). Use that.

Then fix your build environment so you're getting the latest TA / TF from a single source. Better yet, use the dynamic libraries to further reduce errors.

I'm trying to uset he TA_GetVersion() function in my C++ code.  The following code does not return any data back, and the HRESULT is 1 (which is an error).  Can you shed some light on what I'm doing wrong here?

Incidentally, I was able to verify that in our app, on old macOS machines, the error code returned is 36 which is related to the certificates.  I do want to verify that the compiler is picking up the correct version of TA (4.4.4.1) but cannot get any data to return via TA_GetVersion():

HRESULT   hr;

uint32_t *MajorVersion = 0;

uint32_t *MinorVersion = 0;

uint32_t *BuildVersion = 0;

uint32_t *RevisionVersion = 0;

 hr = TA_GetVersion(MajorVersion, MinorVersion, BuildVersion, RevisionVersion); //always returns 1 

XCode is not complaining that the passed in pointers are problematic given the function signature of TA_GetVersion().  Any tips are appreciated.

Thanks,
Arie

HRESULT   hr;
uint32_t MajorVersion = 0;
uint32_t MinorVersion = 0;
uint32_t BuildVersion = 0;
uint32_t RevisionVersion = 0;

hr = TA_GetVersion(&MajorVersion, &MinorVersion, &BuildVersion, &RevisionVersion);

Thank you.  Okay, I've implemented the code correctly, and have debugged and built our app.  I can confirm that the version of TA from TA_GetVersion() is 4.4.4.1.  I can also confirm that on my macOS machine running 10.13.6 that it is STILL receiving error 36 which is related to the certs.

It is not fixed.  I have spent the better part of two weeks trying to resolve this.  We have customers who have already asked to drop paid licenses because we can no longer support their task-specific machines.

What else is there to try?  I know you mentioned dynamic libraries, instead of static but that will take another two weeks to implement for our installers, going through QA, and then releasing.  Aside from that, user Seung-Jin Lee suggested to use static libraries.  I'm at a loss here as I do think your software is the right one for our licensing mechanism, and we have benefitted greatly, but we need to resolve this as soon as possible.

What we are doing to appease the customer in the interim is setup a temporary floating licensing server (yes a VM against your suggestion) and have them install the floating licensing build of our app.  That works, but we cannot support multiple instances of separate TFS servers in the long term.

We can setup a debug session if you'd like, but I will follow up with a support email with screenshots showing that TA_GetVersion() is correctly retreiving the 4.4.4.1 version and that the app shows the same.

Please advise.

Use the dynamic libraries. This was suggested at the beginning.

Using static libraries is (and always has been) fraught. Unless you have deep knowledge about how to debug conflicts in processes, then don’t use them.

Or use offline activations for customers on machines not supported by Apple.

Or upgrade the macOS to the latest version.

These were all addressed and suggested months ago (scroll up).

This is a bug somewhere not in our code. The TFS example shows this (the code contacting the activation servers in TFS is identical to the code contacting the activations servers in TA). That test I had you do was to demonstrate that fact.

Aside from that, user Seung-Jin Lee suggested to use static libraries. 

No, I didn't suggest to use static libraries. I told the case that you already used static library.

Anyway, sorry about the confusion.

Thanks for the clarification, Seung-Jin.  I am using XCode 13 so the static library builds fine.  Can you please confirm that you are using the dynamic library then?

Wyatt, it looks like the downloads for TA for Windows includes the TurboActivate Wizard (.exe), but I didn't see an equivalent of that for macOS.  Do you build one for that?

No. TA Wizard is optional and Windows only.

The dynamic libraries for TurboActivate 4.4.4.1 work on macOS 10.13.6.

Thanks for pushing in that direction.  Maybe stop supporting static libs on macOS if they are “fraught with errors”?

I'm glad you got things working.

Maybe stop supporting static libs on macOS if they are “fraught with errors”?

They're tricky to use correctly. Which is why we *always* recommend using the dynamic libraries.

Static libraries can be used correctly but it's expensive, time consuming, and requires skill.