In a previous bug report (https://forums.garmin.com/developer/connect-iq/i/bug-reports/simulator-dislikes-let-s-encrypt-certs), I mentioned how the simulator doesn't like Let's Encrypt Certs, but Comodo, for example was totally fine. This was annoying, but not a blocker, because, as far as I could tell, devices themselves weren't actually affected by this bug.
However, this appears to no longer be the case.
Runcasts customers have recently, in the last month or two, reported a large increase in the number of 'Unable to Connect' errors they are seeing. When I was finally able to replicate this on my Fenix 5+ (FW 9.00), it turned out the responseCode was '0'. I noticed that this only seemed to affect requests made through Wi-Fi, connections made through Bluetooth and then out through the phone seemed to work.
This made me suspect an SSL certificate issue because the phone will use it's own certificate store when terminating the SSL connection. If the watch's store is out-of-date, or misconfigured, that would explain this behavior.
Another clue was the appearance of the 'Spotify 0200 Error' which had a workaround listed that notably involved manually messing around with the watch's certificates.
To confirm the results, I ported those simulator tests above to run on the watch under a Wi-Fi context by embedding them within the ConfigureSync delegate in a music app. From there, I could confirm that Comodo certificates returned '200', but Let's Encrypt certs return '0'. This was on Fenix 5+ FW 9.00.
When I saw that FW 9.10 for the 5+ fixed the 'Spotify 0200' issue, I became optimistic that it would fix this issue too. So I upgraded and re-ran the tests. Unfortunately, no dice. Tests still fail. Perhaps the Spotify fix was too specific? or didn't account for Let's Encrypt as a CA?
For some reason, I'm not seeing this issue on a 645 Music, but Fenix 6 is affected and Fenix 5+ as well.
UPDATE:
Thinking about this more, the other possibility here is that Let's Encrypt is really a red-herring and just happens to correlate strongly to a different root cause.
In that case, does the watch correctly handle https://en.wikipedia.org/wiki/Server_Name_Indication SNI-based certificate lookups?
