JonathanWe are trying to upgrade from TurboActivate 3 to TurboActivate 4, and we use the C/C++ API on Linux. In my testing, all of the activation requests (i.e. TA_Activate()) are failing with TA_E_INET. This is unexpected because the machine has a working internet connection and no proxies are in use.
Running an strace on the process that calls TA_Activate() to see what's going on shows that it's making an ssl connection:
[pid 1785] connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.20.30.216")}, 16) = -1 EINPROGRESS (Operation now in progress)
Following this it checks the machine's local certificate store:
[pid 1785] open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 4
The rest of the system calls look inconsequential (can attach the whole thing if that'd be helpful).
In addition to having no trouble getting out to the internet, this machine also has no problem pinging the same server TurboActivate is connecting to:
$ ping 104.20.30.216PING 104.20.30.216 (104.20.30.216): 56 data bytes64 bytes from 104.20.30.216: icmp_seq=0 ttl=58 time=66.892 ms64 bytes from 104.20.30.216: icmp_seq=1 ttl=58 time=61.017 ms64 bytes from 104.20.30.216: icmp_seq=2 ttl=58 time=47.256 ms
It also has no problem connecting over https, as long as the certificate check is skipped (as the cert for that machine is for *.wyday.com, and as far as I can tell from reverse lookup there's no DNS address attached to that IP):
$ wget --no-check-certificate https://104.20.30.216--2016-12-14 23:40:00-- https://104.20.30.216/Connecting to 104.20.30.216:443... connected. WARNING: certificate common name *.wyday.com doesn't match requested host name 104.20.30.216.HTTP request sent, awaiting response... 403 Forbidden2016-12-14 23:40:01 ERROR 403: Forbidden.
This made me wonder if the problem wasn't actually a lack of internet connection but instead just a failed SSL certificate validation.
I've reproduced this behavior on two different hosts, one running Ubuntu 14 and the other running Ubuntu 16.
Has anyone else seen this, or have ideas as to the cause?
My guess: update the CACerts on the machine.
https://wyday.com/limelm/help/faq/#internet-error
Also, make sure you're using the latest version of TurboActivate (currently 4.0.8)
Also, don't ping the IP address directly. That IP is just a reverse proxy (DDoS protection). Connecting to it directly is useless -- it won't tell you anything.
>> "wget --no-check-certificate https://104.20.30.216"
This will fail as well.
JonathanYou are correct! I installed the root certificate used by wyday.com (issued by "COMODO RSA Certification Authority") and all is now well. I am indeed using the latest TurboActivate 4.0.8.
However, as I had to install this manually in order to activate, I'm concerned that our customers are going to have the same experience, and I'd rather not have "trust this root certificate!" as part of our installation guide.
Two followup questions, then:
1) Would you expect this root certificate to be present in typical Linux installations?
2) Did this change in TurboActivate 4? (I don't think I had to install any certs to activate under TurboActivate 3).
>> "1) Would you expect this root certificate to be present in typical Linux installations? "
Yes.
>> "2) Did this change in TurboActivate 4? (I don't think I had to install any certs to activate under TurboActivate 3)."
It changed in 3.4.7 to fix a lot of "bugs" that were actually just system admins, proxies, local "helper" programs, and ISPs from intercepting and modifying communication. When we switched to using 100% SSL for all communication these "bugs in TurboActivate" disappeared.
