Activation is lost after running is_genuine_ex in offline mode

A related follow up question. Is it possible to have a workflow where is_genuine_ex can be used in the way described above even in the presence of tls errors? It would be disappointing to have to switch to is_activated and loose all the server-side functionality.

>> "1) Does TurboActivate ever delete/wipe a license file as part of the error handling process?"

No, and we've discussed this on the phone and in emails multiple times with you and people in your company.

TA_E_INET_TLS is related to a bad OS configuration. Use an-up-to-date OS with proper CACerts installed. Covered in the FAQ: https://wyday.com/limelm/help/faq/#internet-error-unix

>> "Is it intended behavior that if is_genuine_ex returns TurboActivateInetTLSError that the program would remove/zero-out the existing license."

Fix the customer's device. Or, better yet, tell them how to fix it.

Don't monitor where you think activation files are sitting. They may or may not be "wiped". Use the API. Don't depend on implementation details that have changed and will change again.

The API does everything you need. Monitoring partial internal implementation files tells you nothing (other than files exist on a disk).

Again, we've said as much multiple times in emails and phone calls.

>> "2) Why is it possible to receive the TurboActivateInetTLSError when setting the TA_SKIP_OFFLINE flag?"

Firstly, because you were using TA_IsGenuine() and not TA_IsGenuineEx() (like the documentation, examples, and we've told you to use multiple times).

Use TA_IsGenuineEx() with the default parameters (90, 14, skip_offline = true).

If you get TA_E_INET_TLS, then read the error (CACerts are broken) and take action to fix the error (fix the CACerts -- google for thousands of solutions for every possible scenario and OS in existence).

>> "Is it possible to have a workflow where is_genuine_ex can be used in the way described above even in the presence of tls errors?"

Yes. Fix the CACerts. We've said this multiple times in emails and phone calls. I'm not sure what we can communicate differently.

If the OS is broken (i.e. bad, missing, or outdated CACerts, for example) TurboActivate stops as early as possible and tells you about the error.

Fixing the error fixes the error.

Sorry to make you repeat yourself Wyatt. I am not someone you have communicated with before on this issue. I read over the past emails to my colleague, but it was not possible to follow the conversation, as half of it is in phone calls I don't have access to. As you said:> "I'm not sure what we can communicate differently."I hope this threaded discussion will be more effective.

Regarding the technical feedback:> "Use an-up-to-date OS with proper CACerts installed. Covered in the FAQ: > https://wyday.com/limelm/help/faq/#internet-error-unix"Our customer claims to have attempted all the troubleshooting steps in that FAQ. I am confirming with our customer exactly what part of this guide they did. I am told they found no issues with the CACerts. I will double check.

>"Firstly, because you were using TA_IsGenuine() and not TA_IsGenuineEx() (like the> documentation, examples, and we've told you to use multiple times).>> Use TA_IsGenuineEx() with the default parameters (90, 14, skip_offline = true).>> If you get TA_E_INET_TLS, then read the error (CACerts are broken) and take action to fix the> error (fix the CACerts -- google for thousands of solutions for every possible scenario and OS in> existence)."Thank you for pointing out that oversight. As requested we switched to TA_IsGenuineEx() and the problem persists. Again, the customer claims the CACerts are good, but I will double check.

> "Don't monitor where you think activation files are sitting. They may or may not be "wiped". Use> the API. Don't depend on implementation details that have changed and will change again."We try to depend on the implementation details as little as possible. However, our application runs within a container (Docker in this case). Only mounted folders will retain changes after the container is closed or restarted. I need to make sure any pieces of state that TurboActivate saves end up in a persistent location that has been mounted on the underlying computer. I need to know the expected behavior of file access so I can debug if I have caused a bug before contacting you for additional support. As far as I know this is all within the intended use of the API as TA_SetCustomActDataPath is enough to support this use case AFAIK. If I am wrong about this, or you would like to discuss LimeLM + Containers further I would request we make another thread, and keep this one on the topic of TA_E_INET_TLS.

> "> "Is it possible to have a workflow where is_genuine_ex can be used in the way described above even in the presence of tls errors?"> Yes. Fix the CACerts."As far as I can tell you answer is really "No". There is no way to have is_genuine_ex ignore TLS errors. You want me to fix the error as the only solution. Is my understanding correct?

In order to send you more useful debug information, I would like your input on the set of commands you would be interested to see the output of to verify the certs are in working order. I will ask the following:

1) "ls" each of the directories listed in https://wyday.com/limelm/help/faq/#internet-error-unix

2) For the first non-empty entry in the list run the command `openssl verify /etc/ssl/certs/ca-certificates.crt` it should return 'Ok'

3) If you think it would be helpful I could just get them to print all the infomration with `openssl x509 -in /etc/ssl/certs/ca-certificates.crt -text -noout`

Please let me know if there are more informative commands, I am not familiar with the best way to test this.

4) It seems this command would be informative?`openssl s_client -connect www.wyday.com:443 -servername www.wyday.com </dev/null | openssl x509 -in /dev/stdin -noout -text`

If you have no internet you get the following error:140611584422336:error:2008F002:BIO routines:BIO_lookup_ex:system lib:../crypto/bio/b_addr.c:704:Name or service not knownconnect:errno=2unable to load certificate139727706124736:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE

5) Ask them if they have a captive gateway which would be intercepting the expected certificate, and giving a different certificate in its place.

6) Ask them to verify the clock on the client machine including the year. If it was very wrong it might not fall within the valid range for the certificate.

I think those are good questions to ask. It will give you a good base of information from which to either ask more questions or solve their problem.

(There are literally thousands of ways a customer can mess up their network, that's why it's impossible for us to come up with definitive "this will fix your problem" type answers.)

Thanks for you help Wyatt, those commands were very informative. I asked the customer to run the following commands:

hostsystem@testaccount:~$ nc -vz www.wyday.com 443Connection to www.wyday.com 443 port [tcp/https] succeeded!hostsystem@testaccount:~$ openssl s_client -connect www.wyday.com:443 -servername www.wyday.com </dev/null | openssl x509 -in /dev/stdin -noout -textwrite:errno=104unable to load certificate139926466978240:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATEhostsystem@testaccount:~$ dateMi 30. Okt 08:58:04 CET 2019

Our customer insists the CACerts are in working order on their machine and that may be true. However our customer's claim that the computer has no access to the internet does not seem to be true based on error 104 (source: https://serverfault.com/questions/807765/cannot-complete-ssl-handshake-with-one-server-from-gce-ubuntu-16-04-1-image-but). It seems our customer's network allows an outbound TCP session, so TurboActivate thinks it can interact with a license server and begins setting up an encrypted connection. However, it appears some network appliance (firewall, etc...) intercepts the return packets. I will ask our customer them to change their network configuration/firewall settings.

At the same time I have some feature requests for TurboActivate:

1) Would it be possible to add something to the Linux FAQ that would point users towards testing their ability to establish a SSL connection with the appropriate port and server in order to to get a more specific error than TA_E_INET_TLS. The command "openssl s_client -connect www.wyday.com:443 -servername www.wyday.com </dev/null | openssl x509 -in /dev/stdin -noout -text" was very helpful for me.2) Is it possible to change the behavior of TurboActivate so that this sort of failure can be ignored if the user is using TA_IsGenuineEx() with Skip_Offline=True? I think having only the ability to send outbound traffic should be considered offline, rather than a fatal error.

>> "1) Would it be possible to add something to the Linux FAQ that would point users towards testing their ability to establish a SSL connection with the appropriate port and server in order to to get a more specific error than TA_E_INET_TLS. The command "openssl s_client -connect www.wyday.com:443 -servername www.wyday.com </dev/null | openssl x509 -in /dev/stdin -noout -text" was very helpful for me."

I wouldn't use "www.wyday.com" That's different than the actual address "wyday.com".

>> "2) Is it possible to change the behavior of TurboActivate so that this sort of failure can be ignored if the user is using TA_IsGenuineEx() with Skip_Offline=True? I think having only the ability to send outbound traffic should be considered offline, rather than a fatal error."

No. If they want to be truly offline then they should be truly offline. If they want to be fake-offline then they have to fix their configuration. If you want TurboActivate to never contact the servers, then use TA_IsActivated().

We're not going to modify TA_IsGenuineEx() to handle broken configurations. It's working as designed: telling the customer about their broken configuration (with links that explain how they should go about fixing it).