Score:-1

Enable HTTPS on my server

gd flag

I have a Ubuntu Server running an application that I can access through my web browser at http://x.x.x.x:8500.

I want to enable the HTTPS protocol on this server. How can I make the users type in https://x.x.x.x.x without port and redirect to port 8500?

Or maybe try to configure https://x.x.x.x:8500?

Do I need to create a virtual host in apache?

Thanks in advance

Score:1
cn flag
raj

Is your application on port 8500 running under Apache or is it provided by some other webserver? Because below I provide instructions for Apache.

You can't have HTTP and HTTPS on the same port. So if you have HTTP on port 8500, you need to use some other port for HTTPS. Normally, the default port for HTTP is 80, and for HTTPS 443 - that's what browsers assume if you don't specify a port in the URL.

As for enabling HTTPS in Apache:

First you need to install Apache SSL module and enable it in Apache configuration, if it's not automatically enabled after installation. It is usually done by creating symlinks in /etc/apache2/mods-enabled directory that point to ssl.* files from /etc/apache2/mods-available directory (these files should be installed as a part of Apache SSL module).

Then you need to create a virtual host for the HTTPS-enabled site. In /etc/apache2/sites-available directory you usually find two template files default and default-ssl. These define a basic initial configuration for HTTP and HTTPS virtual host. The file default usually already has a symlink in /etc/apache2/sites-enabled directory. You need to symlink the other file as well (again, if this hasn't been done automatically upon installation of SSL module).

The file default-ssl contains path to files containing your certificate and private key (or both combined in one file, if you choose to use that format). You need a certificate to make your HTTPS site work. Your installation may come with some default self-signed certificate already generated - this certificate will trigger a warning in your browser, as the browser doesn't know the issuer of this certificate, but after clicking through the warning you should be able to access the site without problems and test if it works.

If you don't already have a certificate on your system, you could generate one using OpenSSL - there are a lot of tutorials on the Net how to do that. You will of course get the same warnings from your browser.

To avoid these warnings, for production use you would need a certficate issued by a Certification Authority (CA) known to your browser - there are two popular ones that provide certificates for free - LetsEncrypt and ZeroSSL. However, those free certificates are valid only for 90 days, so they need to be often renewed (with paid certficates, you can usually buy a certificate for 1 year). Both these websites contain instructions how to obtain a certificate, including installing software for automated certificate renewal.

The key point here is that you need to modify the mentioned paths in the default-ssl file to point to the file(s) where your actual certificate is stored.

Of course you probably made some customizations to your default file (like maybe changing DocumentRoot, adding some Alias, ScriptAlias or Redirect statements, changing some permissions etc.) - you need to make the same customizations to default-ssl.

Restart Apache after all modifications are done to be sure the new configuration has been picked up.

Bananas17 avatar
gd flag
Can i also use nginx reverse proxy for the same purpose? Like using proxy_pass http://xxxx.8500
raj avatar
cn flag
raj
I havent used nginx. If you can make nginx present HTTPS-enabled site on the outside while connecting internally to port 8500, you probably can. But for this kind of application, you probably don't even need nginx. stunnel ( https://www.stunnel.org ) will probably do the job. But you'll still need a certificate.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.