I have followed the instructions here: http://www.steves-internet-guide.com/mosquitto-tls/ to enable ssl.
It is a self signed certificate and when I try to access the broker over the internet from a web page, I get ERR_CERT_AUTHORITY_INVALID.
When I type the websocket address as https://websocketaddress/, I get the warning and when I click proceed and then reload the page accessing the websocket address, I am able to access the broker and get values.
So it is because it's a self signed certificate, I get that error.
My question is what is the procedure to add ssl after I buy the certificate from a CA?
Yes, it is because you are using a self signed certificate.
If you are using a self signed certificate then you have to manually distribute the CA cert to EVERY client that wants to use the broker.
As I said in the answer to your last question about this, if you want it to be accessible to everybody on the internet then you will need to use a certificate from a trusted public CA. The CA cert from these sources are already included in the browser so you don't need to add them.
You can either pay a CA for a certificate that will most likely come with a years life, or you can use LetsEncrypt who will supply a free certificate with a 90 day life, but they also supply a tool that can renew the certificate for you and you can script it to update the certificate then restart mosquitto.
The procedure for setting up mosquitto will be the same, you just need use the files from the CA.
For a paid for Certificate, you will generate a private key, then from that create a CSR (Certificate Signing Request) which you send to the CA and they will send back a certificate.
For LetsEncrypt, the command line tool will handle creating a private key and CSR for you and sending it to the CA to get a certificate. The files will be stored in /etc/letsencrypt/live/[hostname]/. Make sure you use the fullchain.pem for the CA cert entry in mosquitto.conf.
Related
In browsers, is it possible to request javascript for a web-client over https, but have said client connect with a websocket to an IP either:
without ssl
with a self-signed certificate (without previously adding the certificate to the browser)
From what i read, it simply isn't. Mixed content is forbidden, and self-signed certs are not accepted, unless the user goes through a weird and dangerous looking menu, to manually accept the certificate in the browser. It's not like the typical user has the qualification to check a certificate anyways.
This would directly imply, that for this case, encryption cannot be used at all, sadly.
Isn't there something i overlooked? If the websocket connection wasn't over ssl, the client could even just encrypt itself, inside a non-ssl connection. The server it's connecting to won't have a certificate from a CA, it typically won't even have a domain.
Edit: some background
The desired situation is as follows:
a user enters a website, and gets served a client via a secure connection (this is from a static domain, so having a certificate from a CA is no problem here. However, using https apparently disallows non-ssl-connections from that site, and the client accordingly).
the client then opens a websocket connection to a server IP, which may arbitrarily vary (can even be multiple servers at the same time), and typically has no domain. For this, i can only come up with a few scenarios:
no ssl (forbidden, mixed content)
self-signed certificate, preferably the client would get the public key from the main domain, and have that pinned (self-signed produces warnings, and users can't really be required to manually install certificates just for this)
Some CA offers free and automated certificates for IPs, which we can depend on, and just generate new certificates whenever necessary, without any human action needed (i didn't consider this before, because i simply didn't think any CA would offer such a thing. Maybe there is, but so far, i've not encountered any)
I've created a self-signed sertificate
$ openssl genrsa -out key.pem 1024
$ openssl req -new -key key.pem -out request.csr
$ openssl x509 -req -in request.csr -signkey key.pem -out cert.pem
and created an HTTPS server:
var server = https.createServer({
key: fs.readFileSync(__dirname + "/key.pem"),
cert: fs.readFileSync(__dirname + "/cert.pem")
}
Then I requested the page. The expected result is that a browser complained that a connection is not secure. My question how does a browser know that? Is it server job to verify the certificate and notify browser about that or it's a browser job?
SSL Certificates are verified by the client.
The server typically will verify the certificate is not broken or corrupt on start-up, but most servers don't actually validate the legitimacy of their certificate.
Why verify the certificate?
Verification of the server certificate is important because otherwise the client can't really know who it is communicating with. MITM (Man In the Middle) attacks can take place where a third party is intercepting both sides of the communication and they can provide their data to you instead of the data from the server which you thought you were receiving.
A little bit about certificate types
Most certificates are signed by CAs, there are also self-signed certificates, and pinned certificates. I advise using a certificate signed by a CA whenever possible. The Second best option (which generally can only be used within an organization) would using your own internal CA and then self-signing your server cert with your CA cert, this is known as a self-signed certificate and it won't be trusted automatically by any clients or browsers which receive it.
In the self-signed option you must import your CA public key into your CA key store for your server certificate to be trusted. Finally there is simply a pinned certificate, this is where you simply tell your browser to trust an otherwise untrusted certificate (do not do this).
Warning - You should avoid pinning certificates because they are almost impossible to replace during a compromise, and certificates should be schedule to expire within a reasonable period, and be regularly rotated. Pinning makes that very difficult if almost impossible in some situations.
Types of certificates
CA Signed (Needed to operate a secure site on the WWW)
Self Signed (Good for internal organization usage, internal company wikis for example)
Pinned (Avoid)
What kind of verification happens?
So you have a certificate, first you configure your server to use that certificate.
Now when a client comes along and requests a secure connection to your site (as indicated by connecting to port 443 in in the case of HTTPS). Your server sends it's public (not private) certificate and begins a secure handshake. One such handshake is called a Diffie–Hellman key exchange. The handshake itself is beyond the scope of this question.
Before participating in the key exchange, the browser will first examine the certificate which the server provided. For it to be valid several checks must be successful.
There are some of the checks performed.
Does this certificate contain the hostname which matches the hostname we connected to?
If NO, does the certificate include a wildcard CN (Common Name)?
If YES, does that CN have a valid "wildcard" that matches the host name we're connected to? YES/NO
Does the certificate include a CRL (Certificate Revocation List)? If so, does that CRL indicate that this certificate is still valid? YES/NO
Is this certificate signed by a known certificate authority (CA)? YES/NO
Only if NO, does this client (browser) have a public certificate (which matches the certificate offered by this server), which has been marked as Trusted? YES/NO *This is also known as a pinned certificate, as you are not relying on a CA to verify it's authenticity.
For the browser to trust the certificate, and by proxy the server. Then we must check each of the Yes boxes above
Other security stuff that makes the world safer
Now there are other things not "specific" to the certificate which are also verified.
For example, both the client and server must agree on the handshake method, the ciphers used, the hashing algorithm used, and other things.
The server may also pass special HTTPS security flags instructing the browser not to trust other certificates for this service for a period of time (this is known as certificate pinning). Certificate pinning like that used in "Strict Transport Security" (not to be confused with pinning a certificate as mentioned above) can help prevent MITM (man in the middle) attacks. This is one of the many extra security features that HTTPS Strict Transport Security offers.
Once all of the security checks have been certified the browser sends any request it had to the server and the server responds appropriately.
When you visit a secured website (with https), the server also sends a certificate signed by an authority to prove its identity (so that you know you're not getting man in the middled).
Then, your browser needs to know if the certificate is genuine or not, because the man in the middle could send a certificate too. Luckily for you, your browser has a list of authorities to trust. If the certificate's authority signature matches one of the trusted authorities, then everything is fine and no alert is raised.
But if no authorities matches, then the browser kindly asks you if we can trust this authority. In the case of a self-signed certificate, you can trust it (but not before verifying the fingerprint, because, again, a man in the middle could send a different certificate to trick you into believing they're the real deal).
If you trust it, then the browser imports it and adds it to the certificates to trust, never raising an alarm again (until your certificates expires or change (like in a man in the middle situation)).
Is it server job to verify the certificate and notify browser about that or it's a browser job?
The main role of the server certificate is to make sure that the client is communicating with the expected server.
If the client (browser) would just trust the server that the certificate is valid some man in the middle attacker could simply claim to be the real server and claim that the certificate is valid. And after this the client would establish the encrypted connection to the attacker instead of the real server which means that the attacker gets access to the sensitive data. Therefore the servers certificate must always be properly checked by the client.
My question how does a browser know that?
In short: by checking that the certificate is trusted by checking the signature of the issuer and following the trust chain up to a locally trusted root certificate, also checking that the hostname of the URL matches the subject of the certificate and that the certificates are still valid, i.e. not expired and not revoked. For more details see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.
I'm running a web app where users can request a map with their position through gps. In order to do that browsers like Chrome and Safari require an HTTPS protocol, not just http, otherwise call to JS function "getCurrentPosition" will fail. (but on Firefox, for example, it's working)
First question: are there any other possibilities to get user location (through gps, not just by ip)?
If not, the only way (I think) is to switch to https.
Now, app is running on a cheap shared hosting (and I can't do anything about that right now), the only thing that I can do is purchase an SSL certificate in order to enable https protocol.
Second question: hosting offers both ssl certificate with dedicated ip and without dedicated ip. Which is the difference? Well, I know what's a dedicated ip, but for my needs (website + this small app) which advantage could I have from a dedicated ip?
Third question: if I choose a certificate from another CA then I need root access to server in order to install it, is it right?
Last one: some hostings offer SSL with identity verification and without it, how theese last work? I mean, https should't guarrantee encrypted connections with a verified website?
If you have any links please post them, most of resources that I found are too old and they don't talk about acquiring gps data with JS.
Thanks a lot!
EDIT: just for completion: this page is about this deprecated js call for non-secure site. Are there other possibilites to get same result?
First question: are there any other possibilities to get user location
(through gps, not just by ip)?
You can track users’ real time location by using Google Maps APIs, I hope below links will help you.
Using Google Map Tracks API
https://developers.google.com/maps/
Second question: hosting offers both ssl certificate with dedicated ip
and without dedicated ip. Which is the difference? Well, I know what's
a dedicated ip, but for my needs (website + this small app) which
advantage could I have from a dedicated ip?
In the past, SSL requires dedicated IP to secure web applications. But in the mean time, SSL doesn’t require dedicated IP due to SNI technology. If your website hosted on shared IP address, then SNI permits a server to implement multiple certificates on a single IP address.
There are plenty of advantages using a dedicated IP instead of shared IP - read this article
Third question: if I choose a certificate from another CA then I need
root access to server in order to install it, is it right?
Whether you continue with current provider or new one, you don’t need root access of server in order install an SSL certificate.
Last one: some hostings offer SSL with identity verification and
without it, how theese last work? I mean, https should't guarrantee
encrypted connections with a verified website?
All SSL certificates are come with industry standard 256 bit encryption and ensures about encrypted connections. There is varying upon their validation process as below.
Domain Validation Certificates - CA will follow automated validation process and confirm only your control over the domain. You will get this certificate in just minutes.
Business Validation Certificates - CA will check your business existence by verifying official documentations. CA will take 2 to 3 business days to issue your certificate.
Extended Validation Certificates - CA will follow strict validation process and validate legal, physical and operational identity of business. EV SSL will enable most visible sign “the company name in the green address bar”, it will increase trust of your website visitors.
I hope this will helpful for you!
So I got my own little project that I work on and I have a login for my friends to login and post news and update another thing. This site will never hold any personal information, it's just for my own education.
So my question is:
Do I need to create a self signed certificate and add that to my Web Host, or pay money for that or can I just use CryptoJS to create a hash and then when it's on server side use php's password_hash() before saving it in the database?
You are talking about two different things. First is SSL and encryption of network second is password hashing in db. To be secure you should use both SSL and password hashing. If you do not want to pay for signed certificate you can create own cert not signed by CA and give it to your friends (in secure manner) they should include it in browser or they should check certificate fingerprint each time they connect to site. Any one who do not have this cert or its fingerprint will not know it there is MITM and browser will complain about it.
For an administration interface we want to implement client authentication with SSL. The idea is that during the registration process every user generates a SSL certificate, which is registered in the browser and used for authenticating the client to the server. It is important that the private key never leaves the client. Hence it is no solution to generate the certificate on the server and send it to the client.
Is it possible to generate a SSL cert in the browser (e.g. IE 9+, Firefox 12+, Chrome) using JavaScript? Is it possible to register a certificate?
You can't really generate a certificate in the browser, but you can generate a certificate request (or equivalent) in the browser: the key-pair is generated within the browser and the private key never leaves it.
(Note that if you generated a certificate directly within the browser, it would at best be self-signed, since the CA wouldn't give you its private key. That's why you only get to have a certificate-request, since there's little demand for generating self-signed certificates. I think there's a Firefox extension that could do it, though.)
The certificate request is sent to the server, but the format depends on the browser and the method used. What you'll get on the server side is the public key, it's up to the service you implement to turn it into a certificate (unless you use an existing service of course). You can find more details about this in this answer.
Once the certificate is generated on the server, it can be re-imported back to be associated with the private key.