Can't get certs auto-renew on apache in front of tomcat

Help
1

Hi all,

I have a test server https://behit-dev.atomik.app and the auto-renew was failing (that's not the issue, see below).

We have Apache listening on ports 80/443 and forwarding to a Tomcat in the back via mod_jk (Working with mod_jk)

The only way the cert renew worked, was by manually removing the configuration on the site*.conf files for the mod_jk that makes Apache talk to Tomcat, that is:

<VirtualHost *:80>
	ServerAdmin pablo.pazos@cabolabs.com
	ServerName behit-dev.atomik.app
	ErrorLog /var/log/apache2/domains/behit-dev.atomik.app/error.log
	CustomLog /var/log/apache2/domains/behit-dev.atomik.app/access.log combined
	**JkMount /* atomik   <<< NEEDED TO COMMENT THIS**

Did the same on the ...le-ssl.conf site file, just commented the JkMount line.

With that the renew worked. Now my question: how can I automate the renewal without manually logging to the server and commenting the site config files?

Of course, after that, I need to uncomment everything manually again.

I don't know the internals of the certbot and the auto-renew process, I just see on my logs that a cron runs daily trying to renew, and some snap stuff. If I can access the script to add something that comments the JkMount line, that would be useful.

Also if you have any tips on how to automatically renew on this context it will be much appreciated, maybe I'm missing something.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

behit-dev.atomik.app

My web server is (include version):

Apache 2.4

The operating system my web server runs on is (include version):

Ubuntu 23.04

My hosting provider, if applicable, is:

Linode

I can login to a root shell on my machine (yes or no, or I don't know):

yes

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot --version

certbot 2.6.0

2

I would suggest that you handle the ACME challenge requests separately.
If a location statement is not enough, you may need to redirect them so that they are being handled by a separate vhost config.
OR
Try using --webroot.

Also:

that has no LTS.

3 Likes
3

Gracias Rudy!

Can you expand on that? I don't know about the internal processes of certbot, I'm just a basic user, and it seems the automatic renew was configured when I first installed certbot, I don't know where that cron job is located, how that works or how to change it. All I see is that some snap thing related to certbot runs daily by looking at the syslog.

What's a "location statement"?

What's that for?

Not sure what that means. All I know is that the renew worked OK after I removed the JkMount /atomik line from my sites-available config files, with that in, I was getting this from the snap job that runs daily:

2023-09-13T04:12:04.926868+00:00 localhost snapd[316559]: storehelpers.go:773: cannot refresh: snap has no updates available: "certbot", "core", "core20"
2023-09-13T06:42:05.251236+00:00 localhost snapd[316559]: storehelpers.go:773: cannot refresh: snap has no updates available: "certbot", "core", "core20"
2023-09-13T08:56:00.535921+00:00 localhost systemd[1]: Starting snap.certbot.renew.service - Service for snap application certbot.renew...
2023-09-13T08:56:16.161439+00:00 localhost certbot.renew[493408]: Failed to renew certificate behit-dev.atomik.app with error: Some challenges have failed.
2023-09-13T08:56:16.164693+00:00 localhost certbot.renew[493408]: All renewals failed. The following certificates could not be renewed:
2023-09-13T08:56:16.164979+00:00 localhost certbot.renew[493408]:   /etc/letsencrypt/live/behit-dev.atomik.app/fullchain.pem (failure)
2023-09-13T08:56:16.165277+00:00 localhost certbot.renew[493408]: 1 renew failure(s), 0 parse failure(s)
2023-09-13T08:56:16.243046+00:00 localhost systemd[1]: snap.certbot.renew.service: Main process exited, code=exited, status=1/FAILURE
2023-09-13T08:56:16.243312+00:00 localhost systemd[1]: snap.certbot.renew.service: Failed with result 'exit-code'.
2023-09-13T08:56:16.243714+00:00 localhost systemd[1]: Failed to start snap.certbot.renew.service - Service for snap application certbot.renew.
2023-09-13T08:56:16.244022+00:00 localhost systemd[1]: snap.certbot.renew.service: Consumed 1.207s CPU time.
1 Like
4

You can handle the ACME challenge requests differently that you handle the rest of the requests.
Ideally without the conflicting line.
The simplest way of doing that is by adding a location block and handling anything that matches that location as detailed within that block.

It is the line that starts the location block definition.
You might require two such blocks to get this working:

  • one to handle the ACME challenge requests
  • one to handle everything else

If that approach fails, you can:

--webroot is a type of authentication method that doesn't require any handling/modification of the web server configuration.
It merely directs certbot to the directory path where it should place the ACME challenge file.

LTS means Long Term Support.
If you plan on keeping that system around for some years, you might want to use an O/S that will be supported throughout that span of time.

3 Likes
5

Hi Rudy, thanks for taking the time to explain!

Now I got it. Though I'm guessing there are many acme domains, for instance while I was testing I got the challenges from https://acme-v02.api.letsencrypt.org

Is there a pattern I can use to match any of those domains?

No worries, this is a test server.

2 Likes
6

The match I speak of is inwards; Not outwards [to https://acme-v02.api.letsencrypt.org]

2 Likes
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.