Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS Websocket - invalid certificate with require_certificate false #1314

Closed
MartinMuzatko opened this issue Jun 17, 2019 · 6 comments
Closed

Comments

@MartinMuzatko
Copy link

Hello, I am trying to establishing a Websocket connection via wss:https://
But I have trouble setting up one.
On server start, I get no errors.

This is my configuration:
I tried with and without socket_domain ipv4, all available tls_versions.

listener 9001
protocol websockets

socket_domain ipv4

cafile /mqtt/config/certs/rootCA.crt
keyfile /mqtt/config/certs/key.pem
certfile /mqtt/config/certs/cert.pem
require_certificate false
tls_version tlsv1

log_type all
websockets_log_level 255

This is the Mosquitto log:

1560766580: fd=8, revents=1
1560766580: accepted new conn  port 63791 on fd=24
1560766580: Accepted 0x560d81425de0 to tsi 0
1560766580: lws_adopt_socket_vhost: new wsi 0x560d81425de0, sockfd 24
1560766580: lws_set_timeout: 0x560d81425de0: 20 secs
1560766580: insert_wsi_socket_into_fds: 0x560d81425de0: tsi=0, sock=24, pos-in-fds=2
1560766580: lws_set_timeout: 0x560d81425de0: 20 secs
1560766580: inserted SSL accept into fds, trying SSL_accept
1560766580: SSL_accept failed 2 / error:00000002:lib(0):func(0):system lib
1560766580: SSL_ERROR_WANT_READ
1560766580: lws_header_table_attach: wsi 0x560d81425de0: ah (nil) (tsi 0)
1560766580: lws_header_table_attach: wsi 0x560d81425de0: ah 0x560d813ebbf0: count 1 (on exit)
1560766580: Attached ah immediately
1560766580: fd=24, revents=1
1560766580: SSL_accept failed 1 / error:00000001:lib(0):func(0):reason(1)
1560766580: SSL_accept failed skt 24: error:00000001:lib(0):func(0):reason(1)
1560766580: *** error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
1560766580: lws_close_free_wsi: shutting down connection: 0x560d81425de0 (sock 24, state 0)
1560766580: lws_set_timeout: 0x560d81425de0: 20 secs
1560766580: fd=24, revents=17
1560766580: SSL_accept failed 5 / error:00000005:lib(0):func(0):DH lib
1560766580: SSL_accept failed skt 24: error:00000005:lib(0):func(0):DH lib
1560766580: lws_close_free_wsi: real just_kill_connection: 0x560d81425de0 (sockfd 24)
1560766580: remove_wsi_socket_from_fds: removing same prot wsi 0x560d81425de0
1560766580: remove_wsi_socket_from_fds: wsi=0x560d81425de0, sock=24, fds pos=2, end guy pos=3, endfd=0
1560766580: not calling back closed mode=8 state=0
1560766580: lws_header_table_detach: wsi 0x560d81425de0: ah 0x560d813ebbf0 (tsi=0, count = 1)
1560766580: lws_free_wsi: 0x560d81425de0, remaining wsi 1

Via browser:

new Websocket('wss:https://127.0.0.1:9001')
I get the following error:

VM89:1 WebSocket connection to 'wss:https://127.0.0.1:9001/' failed: Error in connection establishment: net::ERR_CERT_AUTHORITY_INVALID

Isn't there a way like with HTTPS to ignore these WSS errors? I thought that with require_certificate false this would not be a problem.

Thanks in advance!

Related: #1005 - although, this is linux x64

@ralight
Copy link
Contributor

ralight commented Jun 17, 2019

The require_certificate true option means that a client must have its own certificate in order to connect. If set to false (which is the default), then the client doesn't need its own certificate. This isn't what is happening here.

It looks like you haven't given your client the Certificate Authority certificate as a trusted certificate. If this is the case, you could potentially tell your client to not worry about what it is connecting to, but there isn't much point using encryption in that case.

@MartinMuzatko
Copy link
Author

We are using encryption because our industrial partners only occasionally let their hardware connect to the internet or maybe not at all. In this case, a validated certificate through the authorities is not always possible. However, for this purpose, we always encrypt our connection via SSL.

While there is a way in browsers to trust a website without a valid SSL, this is not the case for MQTT.
We are using the same certificate for both the broker and for the website. I think we need to fix this via a reverse proxy, in order to have the browser properly recognize the certificate for both websocket and http.

@ralight
Copy link
Contributor

ralight commented Jun 19, 2019

I see - so it sounds like it is the client that you have a problem with then? The broker isn't stopping the client from connecting, it is the client deciding not to carry on connecting.

@ralight
Copy link
Contributor

ralight commented Aug 1, 2019

Is there any update on this? As it stands I don't believe the problem is with mosquitto.

@MartinMuzatko
Copy link
Author

I did not figure it out, but I found a workaround. Either way, websocket for TLS via MQTT does not make sense anyway, because of cross origin resource sharing. If I visit my website at https://test.com with a self-signed certificate and open a websocket to an origin that is different. I wouldn't even be able to open the website of the websocket to have my browser prompt for adding the other self-signed certificate (even though it would be the same certificate, it is still a matter of origins here!)

I probably could have solved it, by accepting the certificate of the origin for a websocket - if this is even a thing in browsers.
I am now using a reverse proxy to unite the websocket with the website, this way both are coming from the same origin.

The only problem I have now, is that Safari on IOS does allow https websocket with self-signed certificate. So basically all that effort was in vain :)

I am closing this. I think there is no proper solution except for the experience I made now with websockets. Thank you for your time to help me getting on the right track.

@ralight
Copy link
Contributor

ralight commented Aug 1, 2019

Ok... I suppose that's the best solution for now then. Thanks for getting back to me.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants