Welcome to the rather complex world of SSL certificates using Let’s Encrypt (and in your case Apache/Tomcat!). It’s genuinely complicated, especially if you have tried to configure it all before.
- You need to serve a public challenge response for Let’s Encrypt to read on http port 80
- When you do get a certificate you will need to convert it from PFX into a cert and private key etc for tomcat to use. v5 (in development) has more support for these types of servers but for v4.x you need to do the work yourself with scripting.
- There are more than two potential problems
Disable the built in tests
If the built-in validation tests are preventing you progressing (including checking your website is accessible on port 80 - if it’s not then Let’s Encrypt will not validate the domain) you can disable the apps own tests under Authorization, un-checking
Perform challenge response config checks. I assume this is whats failing for you (you can provide the log file which would say more).
You can redirect to other ports but port 80 must be open and accepting http://yourdommain/.well-known/acme-challenge requests.
Serving a challenge response file to Let’s Encrypt
When the app asks Let’s Encrypt to provide a certificate for your domain(s) using http validation it will tell the app that each domain must server a challenge response text file at the path http:///.well-known/acme-challenge/example12345 the app will then attempt to work out how to arrange for that file to be served up depending on your configuration.
By default Certify The Web runs it’s own http challenge server on port 80 using http.sys, so you don’t need to have IIS installed, but if you have apache installed and using port 80 then this http challenge listener won’t be able to start and your website on port 80 (presumably handled by apache) will have to handle the challenge response itself, that’s where your website root directory comes in. Place a test file (text, no .txt extension) in your website root folder (htdocs?) and see if you can open that file in a browser, if not then Let’s Encrypt won’t be able to check it either. So if you solve that configuration problem then http validation will continue as normal.
The other possibility is that your Apache is not using port 80 at all and the 404 error you got was from Certify’s own http challenge server (which only runs temporarily) you can check that by browsing to http://localhost/.well-known/acme-challenge/configcheck and if you get ‘OK’ then it was the built in server that responded.
Another alternative is to use DNS validation (where you use an automated DNS provider or temporarily use a manual DNS update to set a TXT record to a given value). This has the advantage of also not needing to run on the same machine your website is on.
If you get as far as generating a certificate pfx file then your next step is to script the conversion of that file to the files you need for apache/tomcat SSL configuration. If you search OpenSSL on this forum you will see some example scripts.
I am assuming that your domain is a public domain and not localhost. Let’s Encrypt only issues certificates for public domains or ones it can see in public DNS.
Note that our apps ‘happy-path’ use case is for users who are using the IIS web server on their own public server and they just want to add https to an existing site, that only takes a couple of clicks and you’re all set. More exotic configurations like yours require more work.