makeWebRequest still broken for local non-SSL requests?

Hi all,

I'm working on a simple widget which should be able to trigger some Node-Red actions via http requests (for house automation system).

Now I've faced the same issue as many of us: the request fails with -1001 (SECURE_CONNECTION_REQUIRED). If I understood the old threads correctly it's because of the security manifest of the Garmin IQ App on my Android phone, which prevents the communication to non-ssl web addresses.

Now I'm wondering what's the current state of this issue because the last messages talking about that are 3 years ago or older. Is this really still an issue or did I something wrong?

Or did someone find a good workaround without changing the network infrastructure (adding certificates, proxy API in the internet) or recompiling the Garmin IQ app (temporary until the next update)?

Any feedback appreciated, thanks!

Top Replies

jim_m_58 over 2 years ago +2

It's not broken, it's by design. Unless the server is running on your phone (127.0.0.1 or localhost) you need to use https)

Here's the completed bug report that allows 127.0.0.1

https://forums…

All Replies

0 jim_m_58 over 2 years ago

It's not broken, it's by design. Unless the server is running on your phone (127.0.0.1 or localhost) you need to use https)

Here's the completed bug report that allows 127.0.0.1

https://forums.garmin.com/developer/connect-iq/i/bug-reports/connect-version-4-20-broke-local-http-access

0 Wearable over 2 years ago

Can anyone suggest such a server for Android? In the bug report I still see people talking about routing their requests over 127.0.0.1:xxxx but I can not find any name of such an app.

0 Wearable over 2 years ago

I now will try a different solution. I created a local proxy web server with certificates signed against a self created CA (this way it's not a self-signed cert). The CA is imported to the Android device and for testing purposes to my PC. With the simulator on the PC the requests are working fine, but when executing my widget on a real watch it always returns with "-300", a NETWORK_REQUEST_TIMED_OUT.

What could be the reason for the timeout? I think it still has to be an issue with the certificates, because when choosing a different request url like "https://www.garmin.com/", I get a "-400".

0 gasteropod over 2 years ago in reply to Wearable

Do you get any clues from the logs on the proxy server. I know that self signed certificates do not work, but I've not tried my own CA and I cannot remember the exact error I got when using a self signed certificate. I guess the other thing to try would be to do a network trace and see if the SSL connection gets established.

0 waterkip over 2 years ago in reply to Wearable

You need to have a public CA, your home made CA isn't know in the trust store Garmin uses. It should however break with a SSL cert error and not with a timeout. Or that is what I would expect.

0 gasteropod over 2 years ago in reply to waterkip

Why would Garmin use it's own trust store? Is this documented? I'd expect that if the CA was loaded on the phone in the correct place this should work. Maybe I'll try it.

0 waterkip over 2 years ago in reply to gasteropod

Garmin probably uses the trust store of the OS. For exampoe, this is how you would do it with Debian based distro's: https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu

In Windows you also have a trust store for the CA's etc.

From my understanding your requests are proxied by Garmin for real devices.

0 gasteropod over 2 years ago in reply to waterkip

Exactly, so if you load your CA into the OS trust store of your phone where your Garmin Connect app runs this should work. That is what @Wearable said he had done.

0 waterkip over 2 years ago in reply to gasteropod

Use let's encrypt and see what happens?

0 jim_m_58 over 2 years ago in reply to waterkip

See this thread for which signers people got to work:
https://forums.garmin.com/developer/connect-iq/f/discussion/285625/makewebrequest-to-https-leads-to-404-because-of-ssl-handshake-problem/1422801#1422801