CODEWITHSUNDEEP
sslhttpsweb-deployment
Merha
Merha

Reputation: 119

How to certify a local server? SSL/TLS HTTPS

Prequel: I created a web application which should interact with our company website. I work remote from the other developer (different company branch), who takes care of the website. I am completely new to web development and have no experience in 'going live'.

My application runs on a local company server using tomcat 8.5. There is a html page which is included in the company website that loads different JavaScript files (& css) from my Server. The interaction with my application happens there. I used to do this via HTTP and everything worked fine. For example: 

<script src="http://172.17.123.123/MyProject/js/script.js"></script>

The Problem: Now the developer told me, I should get a certificate and use HTTPS to make communication between my server and the company web server more secure. This is what he does, as the website he manages is accessible on the Internet and he could easily generate a certificate from a trusted CA. He didn't know how to do this for a local sever.

I managed to enable HTTPS and use a self-signed certificate. Now I use

<script src="https://172.17.123.123:8443/MyProject/js/script.js"></script>

but I get this error:

Failed to load resource: net::ERR_CERT_AUTHORITY_INVALID

I want to use a certificate for my server from a CA but read about that it is impossible to get one for localhost. But I found nothing about a local server. I guess the same principle applies.

Question: Is it beneficial to use HTTPS for communication between a webserver and local company server? If so, how could I generate a trusted certificate? Would a self signed certificate be sufficient?

Upvotes: 0

Views: 2731

Answers (1)

dave_thompson_085
dave_thompson_085

Reputation: 38990

You talk about communication between your server and the web server but there isn't any; the web server is serving a page to the browser that includes references to resources on your server, so the browser is communicating with your server, and it is the browser which distrusts your self-signed cert.

HTTPS on the communication between the browser and your server is beneficial if the network between the browser and your server is either actually insecure (e.g. includes a DMZ or other untrusted zone or insecure link) or must be treated as insecure (e.g. handling payment-card data under PCI DSS). It's impossible to evaluate that from the information you've given, and your company almost certainly shouldn't permit you to publish the information that would make it possible -- plus it wouldn't be useful to anyone else, which is against the StackExchange philosophy. You should be consulting with the people in charge of security on your company's network as to whether HTTPS is required, and probably what options are possible and what they might support or assist with.

It's true you can't get a publicly-trusted cert for localhost, but that doesn't matter because you aren't using localhost. You are using a private (rfc1918) aka 'intranet' address, which is quite different, but you can't get a publicly-trusted cert for those either.

The apparent technical options are:

  • use a self-signed cert (for the address) and configure every browser that will use this application to trust that cert. This may vary depending on what your users will be like, and how many they are. If they are all on domain-joined Windows and using IE/Edge or Chrome but not Firefox, the central admins might just create a GPO that 'pushes' the cert and you're done. If there are thousands on a dozen platforms and located around the world, you may need to spend months of effort to train and assist all of them to import the cert, possibly including getting people to translate into foreign languages.

    In case you aren't already aware, if any of your users use Chrome, the cert must have the authority-name, here the address, in Subject Alternative Name (SAN) as well as Subject CommonName. Other browsers don't currently require this, but may in the future because it's been CABforum policy for quite a while. Many tools commonly used to create selfsigned certs, like OpenSSL commandline and Java keytool, don't do this automatically. (Public CAs do.) There's lots of Qs on this already, you can search for them if applicable.

    Also for this approach, unless you already know, you should verify the address assigned will remain stable. Some company networks need to rearrange their address assignments from time to time, for reasons like offices were opened or expanded or closed, major projects were moved, etc. If thousands of people have to repeat the unfamiliar and arcane cert import several times every year, you will become pretty unpopular.

  • get a (sub)domain name for your system under the company's domain that resolves on the company's internal network only to your machine's address -- that resolution doesn't need to be, and shouldn't be, public. Then get a publicly-trusted cert for that subdomain name. LetsEncrypt using DNS-01 can issue you a cert for a domainname even though no system using that domainname is reachable from the public Internet, as long as you control the DNS for it. OTOH if your company already has a web presence and certs, it should already have a process established for obtaining them; the network security people I mentioned above should know about that.

Upvotes: 5

Related Questions