I have a little server in my local network running some web services, pihole and a nextcloud instance. All services are available via http only and it would be nice if I could switch to https instead, i.e. add encryption.
All the instructions I found in the internet assume that the server is available through the internet and that one wants to encrypt this connection. But I definitely don't want to have the server exposed to the internet.
Could someone maybe share a tutorial or so on how to do this? Thanks in advance!
You would have to create a self-signed SSL certificate and install that on your devices to achieve HTTPS
Steps would be:
create a self-signed certificate, you may follow this guide
Install the certificate on your devices
Configure your webserver to use this certificate, (it will vary depending on what web server you use)
Related
Case
I own a singular VPS hosting account at Hostgator and also a shaired hosting account. This question is mostly intended to gain knowledge, so I would so much appreciate a good explanation than a how-to.
I truly apolagise for mentioning their name but I had to say it so that someone who knows has the required information to help me.
With any type of their accounts, an SSH login is provided but, only with VPS Hosting root access to the same is available.
What I want to do
I want to create a private tunnel to encrypt my browsing data between external servers and my home PC so that my ISP cannot modify or read the data that belong to me.
Question
If I have SSH supported by provider on the server side, does it mean that I have SOCKS5 too?
What else is needed for me to set-up my secure tunnel to find way out using my existing web server account?
If SOCKS5 doesnt come for shaired hosting servers for free or if its not possible, how can one use Socks5 with such servers and establish a secure connection?
SSH supports creating a SOCKS tunnel with the -D option. See http://wiki.vpslink.com/Instant_SOCKS_Proxy_over_SSH for for more details on how to use it. But, this will only be a SOCKS4, not a SOCKS5 tunnel, which means that DNS lookups still will be done outside the tunnel.
I've read a bit about SSL certificates, and in particular I've read that an SSL certificate "requires a dedicated IP address". Now, I'm unsure of the meaning of this; does it mean that the certificate requires a dedicated IP address separate from the IP address used for normal HTTP communication, or just that it can't share the IP address with other SSL certificates?
To clarify, I have a VPS with a dedicated IP address. The VPS is hosting quite a few different sites, including several subdomains of the main site, but only the main site and the subdomains requires SSL. Can I simply purchase an SSL certificate for *.example.com using my current IP address, or do I need to get one that is separate from the other sites on the VPS? Or even worse, do I need to get one that is separate from all HTTP traffic on the server? Keep in mind that none of the other sites needs SSL.
Thanks for any clarification on the topic.
Edit: Some sources for my worries:
http://symbiosis.bytemark.co.uk/docs/symbiosis.html#ch-ssl-hosting
Is it necessary to have dedicated IP Address to install SSL certificate?
There's no such thing as "SSL certificate". The term is misleading. X.509 certificates can be issued for different purposes (as defined by their Key Usage and Extended Key Usage "properties"), in particular for securing SSL/TLS sessions.
Certificates don't require anything in regards to sockets, addresses and ports as certificates are pure data.
When securing some connection with TLS, you usually use the certificate to authenticate the server (and sometimes the client). There's one server per IP/Port, so usually there's no problem for the server to choose what certificate to use.
HTTPS is the exception — several different domain names can refer to one IP and the client (usually a browser) connects to the same server for different domain names. The domain name is passed to the server in the request, which goes after TLS handshake.
Here's where the problem arises - the web server doesn't know which certificate to present. To address this a new extension has been added to TLS, named SNI (Server Name Indication). However, not all clients support it. So in general it's a good idea to have a dedicated server per IP/Port per domain. In other words, each domain, to which the client can connect using HTTPS, should have its own IP address (or different port, but that's not usual).
SSL certificates do not require a dedicated IP address. SSL certificates store a so called common name. Browser interpret this common name as the DNS name of the server they are talking to. If the common name does not match DNS name of the server that the browser is talking to, the browser will issue a warning.
You can get a so called wildcard certificate, that would be admissible for all hosts within a certain domain.
...following up on #Eugene's answer with more info about the compatibility issue...
According to this page from namecheap.com SNI does not work on:
Windows XP + any version Internet Explorer (6,7,8,9)
Internet Explorer 6 or earlier
Safari on Windows XP
BlackBerry Browser
Windows Mobile up to 6.5
Nokia Browser for Symbian at least on Series60
Opera Mobile for Symbian at least on Series60
Web site will still be available via HTTPS, but a certificate mismatch error will appear.
Thus, as we enter 2016 I would venture to stick my neck out there and say, "If you're building a modern website anyway (not supporting old browsers), and if the project is so small that it cannot afford a dedicated IP address, you'll probably be fine relying on SNI." Of course, there are thousands of experts who would disagree with this, but we're talking about being practical, not perfect.
The ssl certificate commmon name has to match the domain name. You don't have any requisite over the ip address, unless it's a limitation imposed by the certificate provider or the http server software.
Edit: looking into the web, it seems that the rumor has been spread because Apache's ssl plugin doesn't have (at least it didn't have in 2002) any mechanism to use different certificate based on the hostname. In such scenario you would have to run two different Apache web servers on the two different IP addresses.
Anyway in your configuration you shouldn't have any problem using only one IP because you don't have to use two different certificates (because you plan to use a wildcard certificate).
I would try anyway configuring the webserver with a self signed certificate before spending money for a second ip or certificate.
Edit 2: reference apache documentation:
http://httpd.apache.org/docs/2.2/vhosts/name-based.html
It seems like now (apache >= 2.2.12) it is supported
Here is our current infrastructure:
2 web servers behind a shared load balancer
dns is pointing to the load balancer
web app is done in asp.net, with wcf services
My question is how to set up the SSL certificate to support https connection.
Here are 2 ideas that I have:
SSL certificate terminates at the load balancer. secure/unsecure communication behind the load balancer will be forwarded to 2 different ports.
pro: only need 1 certificate as I scale horizontally
cons: I have to check secure or not secure by checking which port the request is
coming from. doesn't quite feel right to me
WCF by design will not work when IIS is binded 2 different ports
(according to this)
SSL certificate terminates on each of the server?
cons: need to add more certificates to scale horizontally
thanks
Definitely terminate SSL at the load balancer!!! Anything behind that should NOT be visible outside. Why wouldn't two ports for secure/insecure work just fine?
You don't actually need more certificates at all. Because the externally seen FQDN is the same you use the same certificate on each machine.
This means that WCF (if you're using it) will work. WCF with the SSL terminating on the external load balancer is painful if you're signing/encrypting at a message level rather than a transport level.
You don't need two ports, most likely. Just have the SSL virtual server on the load balancer add an HTTP header to the request and check for that. It's what we do with our Zeus ZXTM 5.1.
You don't have to get a cert for every site there are such things as wildcard certs. But it would have to be installed on every server. (assuming you are using subdomains, if not then you can reuse the same cert across machines)
But I would probably put the cert on the load balancer if not just for the sake of easy configuration.
Is it possible to have a FTP server using SSL on a application server that does not use SSL?
How would you setup an ASP.NET 2.0 to consume a SSL certificate?
This certianly sounds possible but is it advisable, is it good practice?
The choice on using SSL us made on a per connection level, usually determined by the IP port being used (i.e. will be set up between client and server before any application code involved).
The same service/content could be set up on multiple ports each with a different choice for SSL.
The certificate is per host name, but servers can generally support appearing under different names.
To use SSL with ASP.NET takes nothing special, it just works once the IIS web site is configured to support SSL (or to require it: when connections to port 80 for HTTP are redirected to the SSL port); this choice can be made on a per folder basis.
FTP is at the application layer, and SSL is lower, at the presentation layer. The SSL sessions are on a per connection basis. Take a look at the Wikipedia page. The SSL connection is established before anything happens with your application. Your FTP server probably isn't running inside your .NET application server, is it? You should be able to setup an SSH server listening for SCP connections separately. If it really does run from inside your app server, you should be able to listen on a separate port for the SSL connection.
Short of any of that, heres a good link for configuring SSL in IIS. You don't have to make the certificates mandatory. That way you can allow unsecured traffic and secure traffic if that fits in with your application model.
While protecting an application with SSL is always a good idea, it is technically not trivial.
Having a web application protected with SSL requires the webserver to be reachable on a new port (443/https instead of 80/http). This has to be configured "system-wide". Also, there may be only one certificate per IP-address, which is often a problem when hosting multiple domains on the same server.
In my project I need to connect to an intra-net web service but we need SSL connection between the two machines.
Because this is an intra-net site the certificate of the web service might be a self-signed certificate.
The web service and the web page that loads my Flex application resides on the same web server (tomcat) so when I load the web page of the application with HTTPS I been asked to confirm the certificate, I confirm it but this confirmation does not apply on the Flex application (on Internet Explorer and Firefox).
I tried Google's Chrome and it actually asked me twice for confirmation, one for the web page and one for the connection to the web service so it worked great.
Is there a way to tell Flash player to accept also self-signed certificates of is it entirely concern the browser and Adobe guys can't do nothing about it?
In other words, is there a way to connect to a self-signed certificates HTTPS web services from Adobe Flex???
Thanks.
When I put on my security hat the answer would be I hope not. I don't want browser plugins to bypass my browser security settings. I'd consider that a vulnerability.
There might be a way for standalone Air applications, but in browser Flash should honor browser settings.
In your company, you could create your own root CA, add its certificate to all machines that will access the intranet, and then have the CA issue your web service a certificate. The certificate will no longer be self-signed. The two main issues are: (1) managing the private key of your CA, (2) distributing the CA's root certificate to client PCs.
You need to download the cert and install it on both IE and Firefox.
To install a cert on IE:
http://www.markwilson.co.uk/blog/2008/11/trusting-a-self-signed-certificate-in-windows.htm
To install a cert on FF:
Go to Tools->Options and click on the Encryption tab. Click "View Certificates", then "Import".
In my experience, the cert has to be either verified or installed in the browser in order to get Flash to work properly. The cert also needs to have a valid hostname, but you can just edit your client's hostfile if you need to do this for testing.
Well, the flash player should just use the browser to make the connection and be done with it. We have a similar setup here. We use self-made certs, and communicate with the an AMF channel over HTTPS. My guess is though that our setup is different in that we load the flash application itself over an HTTPS channel, so it's talking from HTTPS to the same HTTPS server. Maybe you could try that? This is the setup for our Tomcat server:
Tomcat Server/Client Self-Signed SSL Certificate