I have an VPS with a mosquitto broker and a webpage hosted inside.
The webpage is running over https with websockets, we bought a .com host to be able to get letsencrypt certicate. At the beging I tried with a certificate of www.sslforfree.com pointing directly to myweb.ovh.net and the webpage connecting to this url too.
In that case everything worked perfect, but I need a certificate that could keep for a long, and letsencrypt I thing that could be the solution.
I created a letsencrypt certicate pointing to the web.com and I put that certificates in my mosquitto.conf in this way
listener 9001
protocol websockets
certfile /etc/letsencrypt/live/web.com/cert.pem
cafile /etc/letsencrypt/live/web.com/chain.pem
keyfile /etc/letsencrypt/live/web.com/privkey.pem
allow_anonymous false
When I try to run my mosquitto I don't have response in the server side, no message in the console and I get an error in the web console "ERR_CONNECTION_REFUSED" it seems that the certicate is not beeing loaded in the server correctly or maybe the cert is not ok.
With the cert from sslforfree everithing worked ok. Could it be a problem with file permissions? I'm totally lost with this problem, also I dont know how to see if the cert is being loaded correctly in my server.
My mosquitto log is
1596462903: Config loaded from mosquitto2.conf.
1596462903: Opening ipv4 listen socket on port 8884.
1596462903: Opening ipv6 listen socket on port 8884.
1596462903: Opening websockets listen socket on port 9001.
1596462924: New connection from 88.9.162.109 on port 8884.
1596462924: New client connected from 88.9.162.109 as crfEquipo40 (c1, k60, u'crfEquipo40').
1596462924: Sending CONNACK to crfEquipo40 (0, 0)
1596462924: Received SUBSCRIBE from crfEquipo40
1596462924: opi40/cmd/teclado (QoS 0)
1596462924: crfEquipo40 0 opi40/cmd/teclado
1596462924: Sending SUBACK to crfEquipo40
1596462925: Received SUBSCRIBE from crfEquipo40
1596462925: opi40/evt/hora (QoS 0)
1596462925: crfEquipo40 0 opi40/evt/hora
1596462925: Sending SUBACK to crfEquipo40
1596462925: Received SUBSCRIBE from crfEquipo40
1596463066: mosquitto version 1.4.15 terminating
As you can see port 9001 is running but nothing is happening, I tried the same with the sslforfree certificate and the connection was ok, messages received in the port 9001 but with the letsencrypt certificate no response.
In my javascript console client I get the next
and also this one in the chrome security panel
Use the /etc/letsencrypt/live/web.com/fullchain.pem rather than /etc/letsencrypt/live/web.com/chain.pem
Related
I am trying to use stunnel to turn a wss connection into a ws connection because wsServer doesn't support wss. The server is running Ubuntu, and the client I'm using is Chrome, if it matters.
This is my stunnel.conf file
foreground = yes
debug = info
output = /var/log/stunnel.log
[wsServer]
cert = /etc/letsencrypt/live/myurl.com/fullchain.pem
key = /etc/letsencrypt/live/myurl.com/privkey.pem
accept = 0.0.0.0:8443
connect = 127.0.0.1:8080
I'm trying to connect to it with a javascript call:
const socket = new WebSocket('wss://myurl.com:8433');
But I consistantly get a connection error:
(index):13 WebSocket connection to 'wss://myurl.com:8433/' failed: (anonymous) # (index):13
Here's what I've checked:
That my port forwarding/system firewalls aren't eating the connection. If I kill stunnel and setup a regular socket listening on either port 8080 or 8433, I can connect to that socket from the client machine.
wsServer accepts non-encrypted traffic, if I instead connect with ws://myurl.com:8080 it works fine
wsServer accepts connections from localhost just fine, which I understand is necessary when stunnel is running on the same machine as the server
Chrome accepts my cert when used for https pages under the same domain, so I don't think I have a cert signing error, but I don't know how to tell if the cert is related to the connection failing
Stunnel does not print any errors when starting up
Nothing gets printed to /var/log/stunnel.log, although the file was created after I added the output field to the .conf file
Any ideas about what else I can try? Is there some reason the cert that works for https wouldn't work with wss?
Do people recommend using ProxyPass through apache and avoiding stunnel altogether?
Not a solution, but a next troubleshooting step. Get yourself openssl and attempt to connect to 8443. This should spit back the certificate information and at least confirm stunnel is presenting the certificate.
openssl s_client -connect myurl.com:8443
It's been awhile since I configured stunnel, but IIRC you can't put a password on your key.
I have both a client and a broker running on a remote Linux machine within a Lora Network server that has a mosquitto connector.
The client can listen for the broker's broadcast from a certain address and port (#127.0.0.1:1883)
I would like to open an ssh tunnel between this remote machine and my machine (windows 10) to 'eavesdrop' on the communication between the client and the broker using MQTT.fx to run a mosquitto client;
So far I tried to:
Run ssh -L 22883:#remoteMachineAdress:1883 usern.ame#gatewayAdress -p222 on MobaXtrem](https://mobaxterm.mobatek.net/)
Then I launch a client on MQTT.fx to listen on the broker: 127.0.0.1 port 22883.
This establishes a connection to the broker. However, I am not receiving any of the messages passed to the original client (the one on the remote machine) receives.
Can anyone tell me what am I doing wrong?
And if there are any tutorials about this?
I appreciate all the help I can get, thank you in advance!
This configuration is correct, it was the connector on the server who was sending the data to a different application.
I am forcing a dummy SSL for my localhost running through xampp. Now I am using web sockets which asks for 'wss:' instead of 'ws:'. But when using 'wss', I am getting the following Error:
WebSocket connection to 'wss://192.168.1.5/?aswin' failed: WebSocket opening handshake was canceled
I am new to this, I don't know what's causing this issue.
Remember to change the port number to a one different to the one you used for not secure connections. Some browsers get confused if suddenly a port becomes secure or viceversa.
Remember to use the hostname indicated in the certificate to connect and not the IP.
If you are using a self-signed certificate, use it for HTTPS so you can see the dialog for accepting that certificate. When accessing via WSS:// there is not certificate acceptance dialog, it will just fail to connect.
I've got a JavaScript-based WebApp that includes the Eclipse Paho client.
The WebApp is stored and executed on an NGINX webserver.
On the same Server where the webserver is installed, the MQTT broker mosquitto is running. I've defined port 8884 as listener port for secured connections.
Running mosquitto_sub (simple C client) with --cafile and -p 8884 works fine!
Now I want to secure the WebApp using SSL by passing mqttOptions = { useSSL: true } in my MQTT client implementation.
I can see that the app is trying to establish an connection to wss://ip instead of ws://ip. But the server responds with a connection refused which is totally clear because I did not configure anything on the webserver as I do not have a clue how to manage this. Will the wss connection be 'mapped' to a https or something? Do I need a websocket proxy in NGINX? Thanks in advance for any help.
You can not use the same port for raw MQTT and MQTT over websockets with mosquitto, you need to create 2 separate listeners.
The fact that you can connect with mosquitto_sub implies you have only set up a listener with the raw MQTT.
e.g.
listener 8883
listener 8884
protocol websockets
This will create a native MQTT listener on 8883 and a MQTT over websockets on port 8884
I did so. Here is the mosquitto conf entry:
listener 8884 127.0.0.1
protocol websockets
cafile /path/to/ca.crt
certfile /path/to/certfile.crt
keyfile /path/to/keyfile.key
require_certificate false
and so the app is trying to connect to myip:8884
I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services