I have created an application in Java that requires Tomcat and a certificate to work.
I have two VPS, the first one with Ubuntu 18.04 while the second one with Windows Server 2016.
As a URL to access the application I use the public IP of the server.
Can I use letsencrypt on both operating systems?
Can I get a url like this?
https://server-ip
Do I absolutely have to get a domain name?
Are there any step-by-step guides for beginners like me in Italian or English?
Thank you
P.S .: I am not a system administrator and I have great difficulty with English. Fortunately, you exist and there is also Google Translate. 
Yes - you can find some Windows options here: ACME Client Implementations - Let's Encrypt
No, it must be a proper domain.
Yes. You can get "free" (with some caveats) domains from Freenom - Freenom - Un Nome per Tutti .
For your Linux VPS - https://certbot.eff.org/lets-encrypt/ubuntubionic-other
For your Windows VPS - you must choose an appropriate client and follow its instructions. What web server do you use on Windows, is it Tomcat or IIS?
1 Like
On Windows I use Tomcat 9.
Thanks for all your help.
It seems like people have increasingly found it easier to use a reverse proxy to terminate the TLS connection and then pass the connections through to the Tomcat application. (It’s definitely possible to load a certificate directly in Tomcat, and there are lots of discussions about how to do it here on this forum, but the software support for this is less extensive and less convenient.)
In this case you would use some Let’s Encrypt client application to configure HTTPS support in nginx, for example, and then use a proxy_pass directive to pass through requests to your Tomcat instance on localhost. I believe this option will save time and effort for most people, and also make it easier to get help in case of problems, because the HTTPS setup in nginx is simpler and more people are familiar with it.
1 Like
@mholt, is there a way to use Caddy as a reverse proxy? (If so, that might be an even more convenient option for people who are developing Java web apps.)
for my case, guides are needed
Yes, definitely! I recommend this when you want robust TLS in front of your app.
Create a Caddyfile like this:
# replace with your site's domain name
example.com
# replace / with the base path you want to proxy
# replace localhost:1234 with the local Tomcat address
proxy / localhost:1234
Caddy tutorial: https://caddyserver.com/tutorial/beginner
Proxy docs: https://caddyserver.com/docs/proxy
(Edit: see my reply below for a config-file-less version of this same thing.)
1 Like
So, I think this is a pretty good option for people developing Java web apps, in that case! If we get some reports of people making this work well, I might start suggesting it as a convenient option in the future.
I wonder if it would be useful to have a trimmed-down “caddyproxy” tool (but maybe the existing and future tooling and configuration language around Caddy makes it more useful or straightforward to do this with the Caddyfile, since it can then be customized in other ways if necessary, and run using normal integrations with the operating system).
1 Like
All respect to Caddy but its licensing is an ops nightmare (not available from repos, no free commercial use permitted unless you compile the source by hand).
I’d be happy to work on a reverse-proxying guide for “uncooperative” webservers like Tomcat or those lacking any SSL support, at some point.
There are community-contributed images/repos for Docker, brew, Debian, and other popular tools.
no free commercial use permitted unless you compile the source by hand
That's not quite true.
There are binaries on GitHub you can use which are Apache licensed: Releases · caddyserver/caddy · GitHub
If your business is using Caddy and you would like to use our download page for officially-licensed binaries, purchasing is very easy: https://caddyserver.com/products/licenses -- this is the recommended way to get Caddy for business use, especially with plugins, because it is so easy.
We can't afford to keep the download page running reliably for businesses without them paying for it. I'm still in college, after all -- I don't have a full time job that I can afford to just pay for all that infrastructure out of pocket.
But our commercial support plans are very good, for companies of all sizes.
Caddy is a popular choice for reverse proxying because it just works and is so easy to use, as well as performing very highly for most use cases.
Caddy has been thrown in front of enterprise apps in the last few hours before audits to save companies' PCI compliance... more than once. 
For the most basic (and still highly functional) reverse proxying, you can even do it without a config file (called a Caddyfile) by specifying it on the command line entirely:
$ caddy -host example.com "proxy / localhost:8080"
Et voila! (Works on Windows, too. Of course you gotta deal with permissions on your system like making sure Caddy can bind to low ports, etc., but that problem is external to Caddy.)
Sounds like you have a better idea of what you mean by this than I do.. 
Would be happy to discuss it further though to see where it goes.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.