I use this code to connect to my own mqtt broker with socket from Nextjs and it works fine
import mqtt, { MqttClient } from "mqtt";
//...
mqtt.connect("ws://IPADDRESS:1884");
//....
Now, I want to change it to secure websocket (wss) and I have CRT file, but don't know how to add it.
import mqtt, { MqttClient } from "mqtt";
//...
mqtt.connect("wss://IPADDRESS:1884");
//....
You can use the same certificate that you used for the website, using it for the web socket too. For example, if the website URL is https://test.com you should connect to test.com with wss (wss://test.com:1884) and use the same SSL certificate in your brocker. For the Mosquitto the config file should be like below.
listener 1883
allow_anonymous true
listener 1884
protocol websockets
socket_domain ipv4
cafile C:\Program Files\mosquitto\cert\ca.crt
keyfile C:\Program Files\mosquitto\cert\server.key
certfile C:\Program Files\mosquitto\cert\server.crt
tls_version tlsv1.2
The port 1883 use for Mqtt connection without TLS, for web socket use port 1884 and it needs SSL certificate.
The certificate files should be on the server, they are:
ca.crt is the CA file of your SSL certificate
server.key is the private key
server.crt is the CRT file of your SSL certificate
When you connect to the web socket from your website because it is HTTPS and you connect to the same URL for the web socket, it uses the same SSL certificate and doesn't need to import it to the browser.
As hashed out in the comments.
You can not load unsecure content from a page loaded over HTTPS. This means if the page loads over https://, then the WebSocket Connection must be wss://
The browser will not ask you to approve a self signed or untrusted certificate when making WebSocket connections like it does when trying to navigate to HTTPS site with a certificate not signed by a trusted CA.
You have 2 choices
You manually import your self signed certificate into the browsers trust store. This is only a valid option for dev/test as it would need be done to ALL browsers that ever access the site.
You get a certificate from a trusted CA (e.g. LetsEncrypt) and use for both the HTTP server and the Broker (or you get get something like Nginx to proxy for the broker and to TLS termination for both)
Related
While connecting to my socket.io server from react app, request is getting blocked. Its working with localhost but when i am trying from VPS, its not working.
From VPS:
From localhost:
http://server_ip:8007/socket.io/?EIO=4&transport=polling
above url returning valid response 0{"sid":"VaHqLXI5UVRRaeUAAAAV","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000,"maxPayload":1000000}
The error ("mixed block") seems to say, you must connect using HTTPS to localhost when hosting files from an HTTPS server. Meaning, should use wss:// instead of ws://. Or connect to your vps host using http:// protocol not https://.
I want to use SSl certificates in codename one.Currently I am using below code for connecting to server
ConnectionRequest req = new ConnectionRequest();
req.setUrl("http:/something");
But I want to use https instead of http.I want to import customize SSL certificates and want to use it in my app.
How to import and use SSL certificates ?
You should just change this to HTTPS but you can't use a custom (invalid) SSL certificate. Your certificate must be valid and must be from a valid certificate authority for it to work.
If this is just for debugging you can add your debugging certificate to the device in the device settings which usually allows you to customize the root certificates.
I'm building a web service to allow salesforce to call to it, the two way SSL is used for security, and salesforce has provided its client certificate: sfdc-client.cert.
In order to test whether salesforce client certificate work or not, I have setup a very simple web on MAC apache and enable SSL and client authentication on ssl config file /etc/apache2/extra/httpd-ssl.conf as below (use self-signed):
SSLCertificateFile "/private/etc/apache2/ssl/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/ssl/server.key"
SSLCACertificateFile "/private/etc/apache2/ssl/sfdc-client.cert"
SSLVerifyClient require
SSLVerifyDepth 10
The first browsing by Chrome, I got "SSL Connection Error", I supposed it's correct in this case.
Then, I have tried to import sfdc-client.cert to key chain access, but it does not work at all because it just supports p12/pfx format.
I also tried to use CURL:
curl https://test.com --cert-type der --cert sfdc-client.cert
but got the error:
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)
I'm totally newbie on this stuff, does anyone know how to test client certificate to make sure it works as above?
First you need to have both the client's certificate and certificate private key to be able to test 2-way SSL authentication.
To test with web browser, follow instructions here: Is there a way to test 2 way ssl through browser?
I'm using wso2 IS 4.8.0, my problem is that when I use the SAML2 SSO, I'm beeing redirect to port 9443 on the browser.
I want to be redirected to another port: 80 or 443, because there is an apache that proxies everything.
Is there a configuration to point the rediret to these ports?
Try adding proxyPort to catalina-server.xml which can be found at <IS_HOME>/repository/conf/tomcat folder as follows,
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="9443"
proxyPort="443"
And you'll need to change redirect url of ssoservice as well which can be found in <IS_HOME>/repository/conf/identity.xml file. Find for <SSOService> tag and edit <IdentityProviderURL> like follows,
<IdentityProviderURL>https://localhost:443/samlsso</IdentityProviderURL>
EDIT : Better to use IdentityProviderURL without the default port.
<IdentityProviderURL>https://localhost/samlsso</IdentityProviderURL>
Since 443 is the default port and there might be validation fails when it redirect to url with port and original request sent without the port.
HTH,
DarRay.
I'd like to use the URL fetch service for app engine (java). I'm just sending a POST to one of my own servers from a servlet.
AppEngine -> post-to: https://www.myotherserver.com/scripts/log.php
I'm reading the url fetch doc:
Secure Connections and HTTPS
An app can fetch a URL with the HTTPS method to connect to secure servers. Request and response data are transmitted over the network in encrypted form.
The proxy the URL Fetch service uses cannot authenticate the host it is contacting. Because there is no certificate trust chain, the proxy accepts all certificates, including self-signed certificates. The proxy server cannot detect "man in the middle" attacks between App Engine and the remote host when using HTTPS.
I don't understand - the first paragraph makesit sound like everything that goes from the servlet on app engine, to my php script is going to be secure if I use https. The second paragraph makes it sound like the opposite, that it won't actually be secure. Which is it?
Thanks
There are two things HTTPS does for you. One is to encrypt your data so that as it travels over the internet, through various routers and switches, no one can peek at it. The second thing HTTPS does is authenticate that you are actually talking to a certain server. This is the part App Engine can't do. If you were trying to connect to www.myotherserver.com, it is possible that some bad guy named bob could intercept your connection, and pretend to be www.myotherserver.com. Everything you sent to bob would be encrypted on it's way to bob, but bob himself would be able to get the unencrypted data.
In your case, it sounds like you control both the sending server and the destination server, so you could encrypt your data with a shared secret to protect against this possibility.
The UrlFetch through https has been fixed allowing certificate server validation.
validate_certificate
A value of True instructs the application to send a request to the
server only if the certificate is
valid and signed by a trusted CA, and
also includes a hostname that matches
the certificate. A value of False
instructs the application to perform
no certificate validation. A value of
None defaults to the underlying
implementation of URL Fetch. The
underlying implementation currently
defaults to False, but will default to
True in the near future.