First off, trying both Chrome and Safari on High Sierra - your customer support form at https://symless.com/contact/customer-support does _not_ upload. Something about your attempts at validating form fields seems to be erroring out, blocking uploading the form. Here's the log files:
https://synergy-logs.symless.com/f1a580f90b38117d6a08effc2ee608c0/logs/67-2018-01-03T09-34-20.log and https://synergy-logs.symless.com/f1a580f90b38117d6a08effc2ee608c0/logs/67-2018-01-03T09-57-36.log
My suspicion is that your SSL certificate is broken, and folks running recent OS versions have SSL libraries that refuse to validate connections to sites that a) use a self signed certificate and/or b) have an ssl certificate that does _not_ match the hostname being connected to - see https://www.sslshopper.com/ssl-checker.html#hostname=pubsub1.cloud.symless.com - it's 2017, with services out there like Let's Encrypt, who self signs a public facing web service anymore? (And, for that matter, gets the hostname on the self signed certificate wrong?)
When I saw that Synergy 2 had come out of Beta, I had high hopes for being able to start using it again.
@Daniel Garcia Just to elaborate on the SSL certificate issue. The reason why our websocket/pubsub server was using a self-signed certificate is that this server is never intended nor required to be accessed through the users browser, or by third-party applications or services.
Enabling the full operating system default certificate store in many scenarios actually reduces security. It tends to be trivial for nosy network administrators, who want to monitor everything their users are doing, to install MITM friendly root certificates as a matter of network-wide policy. I personally don't consider it desirable to make this easy in non-Enterprise products.
It is also fairly common for malicious or just plain-sloppy software to install root certificates in to the OS's certificate store. You can read about a particularly notorious example of this here https://en.wikipedia.org/wiki/Superfish#Lenovo_security_incident
The reason the subject name (which was previously our servers IP address) on the certificate was incorrect is that the server was upgraded, which resulted in an IP change, and the old certificate was simply reused. Not regenerating the certificate was an oversight.
The API endpoint server, which is what you hit when you use our one-click login button, has always been signed by a trusted CA.
We understand that it can be unnerving to see connections to our servers when using a partially closed-source product that captures your keystrokes, so I hope this puts your mind at ease