We need an advice about the structure to implement SSL and the needs we have here.
We have a webserver hosted on the internet that needs to communicate with a web application that we host on our internal network. We wish for this communication to be made in https after authentication on the website. The use of letsencrypt certificates is being studied to see if the situation applies nicely. So our present situation is:
The website ( hosted outside ) still has no SSL certificate;
Our internal server on our network has a self signed certificate that we have to install locally on each browser to allow https and stop the warnings;
Problems:
Problem 1. When a user is accessing the website, that has a part of the page with content being part of our internal application, since the user doesn’t have access to our internal self signed certificate, SSL will be broken on that part. How can we address this problem? Is it possible using Let’s Encrypt structure to issue a certificate to our internal server so that it is usable internally on our network independently from the website and also for our internal application to be used inside a page on our website maintaining SSL?
Problem 2. To bridge and allow communication between the Website ( hosted on the web ) and our ( internal application ) we are thinking of using either a SSH Tunnel or to make the internal server visible to the website webserver with NAT port forwarding and firewall rules to limit access - We have both options on our router. So can you advise which one works best with Let’s Encrypt?
It doesn’t really seem to me like a publicly-trusted certificate is absolutely necessary to solve your problem, since you could presumably have the outside server receive the content somehow and then add it to the pages it serves. If necessary, you could use a proxy like Squid listening on a different TCP port (still speaking HTTPS with the same certificate and key!), and generate links to URLs containing that port number. E.g. your regular server could listen on https://www.example.com/ and the Squid proxy (which connects to your internal server) could listen on https://www.example.com:4443/.
Let’s Encrypt can issue certificates for your internal server, as long as it’s referred to by a publicly-visible DNS name and you can prove your control over that name to Let’s Encrypt (via one of the three supported verification methods, involving making certain changes to HTTP responses on port 80, HTTPS responses on port 443, or DNS records). Usually the DNS method is most convenient for internal servers if the public can’t make arbitrary web requests to those servers over the Internet.
I don’t believe the Let’s Encrypt technology has any particular preference about the second question, although, again, to get the certificate in the first place you have to prove your control over the server either by allowing port 80 or 443 requests to something responding to that DNS name, or by making associated DNS record changes.