makeWebRequest to https leads to 404 because of SSL handshake problem

I would guess it's the server certificate.  Who signed it?  Only some signers work with CIQ

Thank you - I think too, that this is the problem: It's a let's encrypt certificate.

Which signers do you know work with CIQ.

More Info:
With 'openssl s_client -connect www.test.com:443 -prexit' I can see on my server a 'Post-Handshake New Session Ticket arrived:'-section. Does CIQ have a problem with that post-handshake?
And if so why? (I guess there are a lot of let's encrypt certificates around?!)

Thank you again Jim - it was the let's encrypt certificate. After installing another certificate (ssls.com) it works like a charm.

btw: the connection issue has nothing to do with post-handshake. Now it works and there is still a post-handshake.

Question at Garmin: are there technical reasons that let's encrypt certificates are not supported?

I'm also having issues getting the simulator to make requests to my API, which uses Let's Encrypt for our certs. 

The response is always the same: 404, null data. But this issue only occurs on the simulator, from what I can tell. On a real device, it makes the request without issue. I haven't worked on any Garmin projects for nearly half a year, and before I got back into it, I never ran into this issue. That leaves me feeling that this is a new bug.

Turning off "Use Device HTTPS Requirements" also 'fixes' the issue for me, but I don't trust like that because now I'm concerned some customers may be affected by vague device HTTPS requirements withholding API requests from being made. 

I'd rather not pay for my certs if I can avoid it, so I'm gonna dig deeper into why my Let's Encrypt might be giving me this headache. If I make it anywhere worthwhile, I'll follow up here.

Also, completely random side note: Jim, when did you change your profile pic? I miss the MS Paint stick figure guy. 

A while ago, I had also problems with "makewebrequest", to reach my webservices in my internal network.

I found a solution to use a self signed certificate, which I described here:

https://forums.garmin.com/developer/connect-iq/f/discussion/291012/makewebrequest-for-internal-networks

It's for GCM on an iPhone, but I assume it's similar for Android.
Maybe it's helpful for you

I'm not sure if it's Garmins responsibility. If you use an iPhone, I think it's Apples policy, that doesn't allow third party apps (in that case GCM) to call services with no official certificates

I would not say that Let's Encrypt certs are not supported.  I am using them on two different servers that I am using with CIQ apps.  I am not having any issues.  So I would suspect that there is something wrong with your specific server, perhaps the FQDN/sites referenced in the cert don't match the server.  Since you already applied a different cert, it is possible that you could have revoked and re-generated a new cert with Let's Encrypt and it too might have worked.

My server is using let's encrypt，which works well

There are two types of webRequests that can be triggered from a Garmin watch:

1. Web requests when no WLAN is connected directly on your watch, they will be forewarded via bluetooth to your cellphone which will handle the request and pass on the response. Those requests work well with Let's Encrypt certificates.
2. Web request when WLAN is connected to your watch: They will go directly to your requested service via the watches http client. Here Let's Encrypt certificates are NOT supported.

At least this is my understanding and experience with "Device Https Requirements" where "Device" means the https requirements of the watch itself instead of the requirements that you use when requests are tunneled through your cellphone.

in Case 1, your phone is acting as a proxy, and what ever rules are in place with Android/iOS app.

in Case 2, your watch is rarely connected with wifi (edge devices are different), but in that case, no proxy involved.