New to all this - need some help please

Question
1

Hi,
I have a server which I need to communicate with via Apache Tomcat 9 over SSL.
I’ve downloaded and set up Certify the Web and am trying to create an SSL certificate.

However when I add in what, to me, seem sensible entries for the cert domain, the authorisation settings and deployment, the test fails due to ‘could not verify URL is accessible’.

I gave a website root directory as my Tomcat ‘webapps’ folder and I can see that it creates the ‘.well-known’ folder there when testing. I get a 404 error if I try to navigate to localhost:80 in a browser on the server desktop so is it likely that I’ve disabled the default port for the HTTP check somehow?

I need this certificate to replace a self-signed one that was there already, so there has been some config of Tomcat to use HTTPS and some non-standard ports previously.

any help would be appreciated as I don’t know what I don’t know about all of this
thanks
Keith

2

Hi Keith,

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.

Two problems:

  • 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.

3

I don’t do a lot of development with Tomcat… but I feel like it is more difficult than Apache.

Tomcat usually listens on port 8080. If that remains true, Certify could take over port 80 temporarily to do the challenge responses. If Tomcat is reconfigured to use port 80, it becomes more difficult.

Tomcat is an application server and by default doesn’t serve static files. You will need to configure Tomcat to serve static files on a certain path rather than just dumping into the webapps folder.

You can try looking here, but I can’t confirm the validity as I have never done this…

You’ll have to do some gymnastics to get the paths to align correctly. For example, you’ll have to create an entry pointing at the local .well-known folder as the docBase named ‘.well-known’. Hopefully Tomcat doesn’t have an issue with that naming pattern. Then you point Certify at the folder’s parent so that it will re-use the existing sub-folder.

If that works, you can jump into the post-deployment scripting that normal Apache requires.

4

thanks very much for the reply - I’m out of the office until later in the week when I will get a chance to try your suggestions

5

Hi there, thanks for the very comprehensive reply - though sadly I managed to understand only a small part of it :slight_smile:
I’ve looked in the log file and can see a message ‘the remote name could not be resolved’. I take this to mean that this server may not be properly on our public domain. So I need to look into that first I imagine. (it does say it’s on the domain ‘xxx.local’ when i look at the computer properties).

Meanwhile I could try another tack - I know that another of our servers already has certify-the-web running successfully on it and managing certificates for our websites. One of those is a wildcard for our domain so should work for any server if I understand correctly. How would I go about finding the certificate file and importing it to another machine? I understand that it may not then be managed by certify-the-web on this second server, but for the moment I just need to prove connectivity to a third party system that relies on https

thanks
Keith

6

Hi Keith,

.local names won’t work at all with Let’s Encrypt issued certificates because it’s not a public domain they can verify.

Regarding the other server with the wildcard, you can export that (with the private key) from the computer certificates store then import it on the other server and add an https binding in IIS (assuming your using IIS), you want to set a host name in the binding and tick ‘use SNI’. Certificates from let’s Encrypt expire after 90 days so you need to renew/update the https binding again before then.

1 Like