Https and SSL issue with port 80 - node.js

Recently I just start using https:// for my server and the strange thing is that I can open if I explicitly type "https://www.example.com:80" but won't be able to connect if i type "https://www.example.com".
I am using NodeJS with Express 4 framework hosted on Digital Ocean.
What can I do to let people access my website normally? And also is it normal that they have to click "accept" first time they visit? Why for other https website I dont have to do that?
I am using RapidSSL.

Your question is light on details, but here are the two likely guesses:
If you want your SSL server to work by default when users type https://xxxx, then your server needs to be running on port 443, not port 80. That's the default port number reserved for https connections and is the port number that the browser will try if the user just enters a https://xxxx URL.
If the browser is prompting you for permission to connect to your site, then that is likely because the SSL certificate you are using is not signed by one of the certificate authorities that the browsers trust (perhaps it is a self signed certificate). You can solve that issue by getting a certificate from the right trusted source and using that certificate in your server. It's also a possibility that something else is wrong with your SSL configuration, but we'd need to see more detail about the situation to know.

Related

ERR_SSL_PROTOCOL_ERROR when making request to server IP

I got a nodeJS express API /w nginx up and running on an ubuntu server. I've set up everything but when I try to access the API (https://167.xx.xx.xx:80/get-all-products) directly or through my client I get this error:
ERR_SSL_PROTOCOL_ERROR
I've did some searching and I found out that this could be because my server does not have a valid ssl certificate but for a ssl certificate I would need to have a domain / be the owner of the ip adress which I guess i'm not as the server is hosted by another company.
How can I fix this error without having to buy a domain for my server?
https://167.xx.xx.xx:80/... ...
I've did some searching and I found out that this could be because my
server does not have a valid ssl certificate
This isn't the case here yet. The problem instead is that you are simply trying to switch from http:// on port 80 to https:// on port 80 without having the server setup for HTTPS. Thus the client will try to speak HTTPS while the server only understands HTTP - and this causes the failure you see.
To be able to use https:// in the URL you need to setup the server for this and the configuration must use a certificate which matches the URL (domain or IP) - no way around this.

Can't connect with HTTPS but HTTP works fine

I'm trying to secure my we server using HTTPS and SSL/TLS to access my website. Going to the site by www.-----.------.compute-1.amazonaws.com works and the connection is successful. But when I try https://www.-----.------.compute-1.amazonaws.com chrome says "This site can’t be reached" "www.-----.------.compute-1.amazonaws.com refused to connect". I am using an Amazon Linux instance. Where did I go wrong?
Typical problem. I am assuming some things here.
You launched a EC2 (or something similar) Instance
Didn't Open 443 port or Configure it further.
Using port 80 for serving pages.
I think you got the answer. Check this out.
I needed an SSL certificate from a CA (certificate authority). I was using a self-signed certificate which doesn't work in a browser.

self signed certificate for implementing https

I have a server with public IP and hold a website on it. I don't have a domain and my web server is IIS, then I created a self signed certificate in the server and bind it to my website. When I want to access to my website using a link like http://.../test. I can access to the website with https in localhost in the server. but I can't access to the website from a client browser with httpsand I get this error in client browser:ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Your server most likely doesn't support TLS (v1.0 or higher) but only SSLv3. That's a common cause for this error. SSLv3 is blocked in most browsers because of the POODLE vulnerability (CVE-2014-3566). You should review your server settings and upgrade them accordingly.
You can test your website at the awesome SSL Test from SSL Labs. This will point out errors like these and it helps you create a secure config. Please keep in mind that any score below A is in urgent need of improvement.
I found out to solve it. Port 443 was closed in the server.

How to implement valid https in web2py

I am using the following web2py slice in attempt to use https for a service worker function in a page.
http://www.web2pyslices.com/slice/show/1507/generate-ssl-self-signed-certificate-and-key-enable-https-encryption-in-web2py
I have tried opening web2py with the following line (with and without [-i IP and -p PORT]):
python web2py.py -c myPath/ssl_certificate.crt -k myPath/ssl_self_signed.key -i 127.0.0.1 -p 8000
but https is declared 'not private' and is crossed out. Because of this, I am getting a SSL certificate error when the registration of the service worker is attempted.
Please indicate what is going wrong or whether more information is needed
You mention "https is declared 'not private' and is crossed out". This has to do with browsers disliking not trusted (self-signed) certificates, because that's what trust is all about. If any hacker could just make up a certificate and the https client wouldn't respond with at least a frown, you could still be hacked or sniffed without noticing. Since you don't mention any other error, I assume you get otherwise valid results from the web2py server?
If so, you have setup your self-signed certificate well. If you don't get any valid html response (outside your browsers complaint, of course), you still have an issue with the setup.
If your service worker won't accept the certificate, what you can do (in a test environment at least) is import the self-signed certificate into the machine or service worker certificate repository. The process differs per OS and version.
Hope this helps. If it doesn't, please provide more detail.
The best way to use ssl with web2py is use of the deployment recipes with prodution-grade webservers like apache, nginx or Lighttpd.
Any of the mentioned scripts create a self-signed certificate, and then, you have to fix the generated server config files to a real certificate.
You can buy a real ssl certificate from any of many resellers or get for free from Let's Encript, if you have a real IP, like in a VPS or server.
A simple way to fix the config files is create a simbolic link from the real certificate to the one mentioned in the server config file.
To just test your service worker in your machine or a internal test server, just use a non-ssl port, or like Remco sugested, import the self-signed certificate to client environment.

SSL Https, is it that simple?

I'm just setting up an SSL area of a website, and was just wondering... is it as simple as adding HTTPS on the url?
(this is presuming I have a valid certificate of the hosting company?)
Or is there something more to it?
Thanks.
You have to setup the server to allow ssl connections. That includes generating a signed server request. You send this CSR to the cert authority (Verisign etc), and they send you a cert to install on the server. If you are behind a firewall you need to open port 443.
If you don't control the server i.e. shared hosting, there is probably a page in your control panel to do it all for you using a GUI.
When you replace http: in a URL with https: you are asking your web browser to do two things:
To attempt an encrypted (SSL) connection
To change which port to use on the remote server if none is specified in the URL
Most web browsers use port 80 for unencrypted traffic and port 443 for encrypted traffic by default. So, the first thing you need is a web server that is listening on port 443. If you are using a hosting company, this is probably already the case or becomes the case when you configure SSL.
You do not have to use port 443 but that is where browsers will be looking when users do not specify a port. You could also force everybody that connects at port 80 to use SSL as well though with the right configuration. That means that ALL traffic to your site would be encrypted.
To get the encryption up and running you generally need three things: a certificate, an encryption key, and a server request (CSR).
How you configure these is extremely dependent on how you are hosting the web server. Most hosting companies have 'control panels' that you log into for configuration. Common ones are Plex and CPanel. If either of those ring a bell you can post more information to get a better answer.
If you are managing the server yourself the big question is whether you are hosting on Windows or Linux. If it is windows, you are most likely going to want to configure IIS (Internet Information Server) while if it is on Linux you are probably going to configure Apache.
If you are using IIS, this link might help:
http://www.petri.co.il/configure_ssl_on_your_website_with_iis.htm
If it is Apache, Byron gave a good link above:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
You can use other web servers. For example, I use nginx:
http://rubypond.com/blog/setting-up-nginx-ssl-and-virtual-hosts
So, I guess the real step one is finding out more about your server. :-)
Once your web server has the SSL cert installed, it is as easy as using HTTPS on the URLs. There are some considerations to be aware of:
Port 443 must be open between the user and web server. (obvious)
Browser caching will be reduced to in-memory session cache and not stored on disk. Also, caching proxies in between will not be able to cache anything, since everything is encrypted. This means an increase in load times and bandwidth requirements of the web server.
When using HTTPS to receive sensitive data, be sure to disallow its use over HTTP. e.g. If you have a page that accepts credit card numbers in a POST, the app should fail validation if it was not done over HTTPS. This can be done in your code or in web server configuration. This prevents a bug or malware from systematically sending sensitive data in the clear without the user knowing.

Resources