localhost and 192.168.x.x over HTTPS for a-frame webVR development and local testing - ssl

I'm trying to develop a A-frame-based VR experience.
I can test it on my mac via http://localhost but can't do the same using mobile phone or VR headset via http://192.168.1.123.
The problem is that those browsers demand that the page is served over HTTPS rather than HTTP, otherwise it denies access to the device motion sensor, making testing impossible.
Using the following instructions, I managed to successfully have my VR web page served over with a valid certificate.
https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/
https://github.com/mattdesl/budo/blob/master/docs/command-line-usage.md#ssl-and-https
But, that is not enough, mobile device and headset access the page over a local-wifi IP like 192.168.1.123 rather than localhost and the ssl certificate doesn't seem to work for those, even if i replace localhost by the correct IP when generating the domain key & certificates.
i guess each device browser would need to have its trusted store updated or something...
Would be curious to know how people solved their problem in their a-frame local development and testing flow.

Partial answer -- for Oculus Quest or Go browser development at least.
You can use the Chrome remote device debugging tools:
https://developer.oculus.com/documentation/oculus-browser/browser-remote-debugging/
Then setup port forwarding for the remote device:
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/local-server
This method allows you to sidestep the whole certificate thing since you can still use localhost:port to which the browser grants appropriate device permissions.

Since you can't use IP numbers, you want to include your local domain name into the certificate, like this:
https://stackoverflow.com/a/10176685/573216
Worked for me in a similar context.

Related

SSL from personal machine for testing Progressive Web Apps

I want to test building Progressive Web Apps and know this requires SSL. I am able to test onlocalhost (using npm http_server) but would like to test from other machines on the same local network and some mobile devices, so I need https and an SSL certificate.
I have tried using XAMPP on a windows machine, and made a certificate using makecert, but even though I installed it on Chrome on another machine, it didn't work.
Any ideas how I can achieve this ie run web server of some kind on one Windows 10 machine, host the pages using SSL and browse from another and mobile devices?
Do I have to use 3rd party certs, and would these work on a local machine (eg by local IP) rather than a domain name?
Bit confused!

Mobile app testing with jmeter, internet connecrion does not work after conguiring proxy settings

I am doing a mobile test recording with jmeter, after i configure my mobile proxy settings to system ip and port to math jmeter. Internet stops working? P.S. i already installed the ApacheJmeterTemporaryRootCA.crt
There is a number of "mobile" operating systems and we are not telepathic enough to figure out which one you're talking about in order to provide troubleshooting instructions. I assume you use Android as it is about 75% of market.
Make sure to start JMeter's HTTP(S) Test Script Recorder prior to amending mobile device proxy settings
Make sure JMeter and mobile device are on the same subnet (connected to the same WiFi network)
Make sure that port 8888 is open in your operating system firewall
On certain Android versions you cannot set system proxy for HTTPS traffic, you will need to install a separate application like ProxyDroid for this
If nothing helps you can always consider an alternative way of recording mobile traffic, in this case you won't have to worry about proxies and certificates and you will get confidence that your device is connected to the Internet. See Testing Mobile sites and Apps article for more details.
I am very late here, but still this may help others who are still facing this issue.
In beginning i faced the same issue. Then, I tried by disabling the firewall. It worked fine.
Also disabling firewall may create a way for malicious contents to enter. Try only for trusted sources.

Issues encountered on a fresh installation of RocketChat (1524) on Ubuntu

I have just downloaded and installed latest Rocket.chat using SNAP tool on Ubuntu (16.04 LTS). Overall, I had a smooth experience of installing and getting started with Rocket.chat. However, I did find a few serious issues.
I try to get auto SSL running by following the instructions at: https://rocket.chat/docs/installation/manual-installation/ubuntu/snaps/autossl/. But after configuring the Caddy file, the Caddy service failed to start, with the message:
Activating privacy features… 2018/04/24 17:58:09 open /root/snap/rocketchat-server/1254/.caddy/acme/acme-v02.api.letsencrypt.org/sites//.crt: no such file or directory
The second issue is with start video chat using webRTC. When I clicked on it, nothing happened. I am using Chrome browser and tried to start video chat on several devices. All the Chrome browsers have passed the webRTC tests. I don’t know why video screen is not shown.
I signed in with open.rocket.chat and compared the differences between my installation and the official site. When my browser points to open.rocket.chat site, the videochat does not work either. It does show the video window, but only displays only myself, not the remote member. Note to experiment, I signed up with 2 accounts to simulate 2 members chatting.
Also I downloaded the Android Rocketchat client. However, I couldn’t find the start video chat option. Is it true that video chat is unavailable yet on the Android client?
To summarise, we have the issue of setting up auto SSL with Caddy, and using video chat (webRTC). It could be that I missed a few basic configurations on my environment. Other functions like text messaging works fine.
We are deciding whether we should use Slack/CometChat for our instant messaging solution. It seems RocketChat has all the features we want, but it is a pity we couldn’t get it to work completely.
Appreciate someone can guide me in this.
I did some investigations on these issues, and have made some progress. I'd like to share my findings, which I hope could be of some help in future to newbies of RocketChat like me.
However, I still have a few issues unresolved, and hope someone could help.
Caddy service failed to start
Using self-signed certificate and defining the domain name in /etc/hosts, I can get Caddy service to start and https to work. My guess is that the domain name I used, even it is registered with a DNS provider, has no CNAME record, and is not mapped to any IP address. Letsencrypt, which is used by Caddy to do on-demand SSL, therefore is unable to create a SSL certificate for my domain name. It would be nice if the RocketChat documentation could make it clearer.
open.rocket.chat WebRTC-based video chat not working
after I used another Windows machine, the video chat is working. Presumably my previous computer does not have the latest Windows update. But I am glad with open.rocket.chat site, every feature I tested is working.
On my self-hosted Rocket-chat (i.e. a Linux server at home), however, the video chat is still not working. When I clicked on the "start video chat" button, no video screen is launched on my browser window. On the remote browser (which was used for simulating the conversation partner), there is a notification "xxx invites you to video chat, do you accept?". I clicked on "Yes". After that, nothing happens on the remote browser. The only issue I can think of is that I didn't use https to connect to the self-hosted Rocket-chat. Because I am using several computers in my home wireless network. I only use http://192.168.0.3:3000 to point to the chat server. I am wondering if secure connection is required in order to use video chat?
On the Android Rocket Chat app, I couldn't find any links to start a video chat, nor can I receive any video chat invite. Is it by design or a defect?
Hope someone can enlighten me on these issues.
I made further investigation as to why webRTC does not work on my self-hosted Rocket-chat instance. It is related to secured connection. There is a related discussion in the RocketChat forum:
https://github.com/RocketChat/Rocket.Chat/issues/1813
Basically, the connection to the Rocket.chat server must be secure for WebRtc to work. After I configure Caddy to support HTTPS listening on Rocket.Chat (currently using self-signed certificate), WebRTC works. It would really help users if the documentation can make this clear.
Now the remaining issue for me is to figure out if Android Rocket Chat app supports Web RTC.

SSL Certificate not trusted

Having an issue with my SSL certificate. Often it seems to work fine, but sometimes the user's browser throws up a warning that it is not trusted.
I know very little about SSL certificates, but here is some information that may or may not be relevant:
URL: demo.EnterpriseJazz.com
It is a wild card certificate because
the application uses subdomains (one subdomain per registered organization Example: BobsLawnCare.EnterpriseJazz.com)
The certificate was cheap for a wild card certificate, I paid around $50 for it if I remember correctly. I believe I got it from a cheap re-seller.
The server is located in my house on a Verizon FIOS business internet connection. It is not in a data center.
Seems to work fine with:
Safari on my new Macbook Pro
Chrome on my new Macbook Pro
Firefox on my windows machine
Microsoft Edge on my windows machine
Internet Explorer on my windows machine
Opera on my windows machine
Firefox on my Linux machine (CentOS)
Not trusted with:
Chrome on my iPhone 6s
Safari on my iPhone 6s (screen shots below)
Have a look at the SSLLabs report for this site. Apart from a shockingly insecure setup you will notice:
This server's certificate chain is incomplete.
This means that the client has not enough information to build the trust path to the root certificate and thus can not accept the certificate as trusted.
However a desktop browser will attempt to work around such setup problems by trying to fill in the missing chain certificates, i.e. downloading these from the web or using cached certificates from earlier connections to other clients. But apart from the desktop browsers most other clients will not do it and thus fail.
I had the exact same issue.
After futzing with every nook and cranny of my SSL and http setups, I finally realized "How silly I was to not check the URL first!"
My browser had been connecting to the regular non-trusted site (http://example.com) and I had blindly assumed that the broken lock icon meant something was wrong with my cert installation. Duh!
Modern browsers hiding the actual protocol letters behind a pretty icon or user-friendly message that conflates two issues into one - that didn't help.
My suggestion would be to first make sure you're hitting the https version of your site. If not, your first step to the solution is to create an automatic redirect of all http to https.
I hope getting to this post first helps at least 1% of those who had this problem. I'm in that 1%

HTTPS works only under my WIFI

I've a very weird problem with https.
I installed a new ssl certificate on my subdomain beta.gosherpy.com and when I try to access from any device here in my office using this wifi https://beta.gosherpy.com works perfectly. As soon as I use mobile 3G or another wifi the response is "cannot connect to the server".
I talked to GOdaddy Customer care and they bring me to sslshopper and sslchecker tool which states that everything is good and correct.
I've no idea why under my wifi works outside not. any idea ?
Best