The automatic update feature works by retrieving the URL pointed out by UPTDATE_URL. This must currently be a HTTP URL. If you try to use HTTPS, you will get a failure and a not very obvious error message. With: UPDATE_URL=https://www.cendio.com/downloads/clients/clientupdate.conf ...I get: 2014-01-13T12:39:54: Unable to retrieve update configuration: Could not parse response status line We should consider support HTTPS or at least improve the error message.
One major issue is the whole mess with certificates. Who to trust, how this list should be maintained and what to do when the certificate doesn't match. One easy solution is to have to provide the trusted CA certificates to tlclient. None of the major ones will be trusted by default. In order for the updates to work out-of-box for us, we will have our own (self-signed) CA for a special domain, e.g.: https://update.cendio.com/clientupdate.conf That way we can make sure we get a trusted transfer of the file and still have the freedom to chose any certificate provider for our normal www.cendio.com site. Customers might run in to the same issue though. If they want to ship clientupdate.conf from the same domain as the actual updated exe/rpm/deb, then they'll have to add that well known CA to the list of CAs that tlclient trusts.
For reference, these are the locations that Go seems to search for a certificate store on Linux: /etc/ssl/certs/ca-certificates.crt /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/ca-bundle.pem /etc/pki/tls/cacert.pem /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem /etc/ssl/cert.pem /etc/ssl/certs /etc/pki/tls/certs /system/etc/security/cacerts
