How can I automate renewals of certificate with Tomcat?
Well, I haven’t used Tomcat since before Let’s Encrypt existed, but I guess you could use the tools Certbot provides to automate the renewal procedure described in the tutorial…
Create a script file containing the copy commands:
#!/bin/bash cd /etc/letsencrypt/live/foo.example.com cp cert.pem /opt/tomcat/conf cp chain.pem /opt/tomcat/conf cp privkey.pem /opt/tomcat/conf
Save it as, say,
/root/update-tomcat-cert.sh and make it executable with
chmod +x /root/update-tomcat-cert.sh
Then you can renew the cert manually one last time, specifying the automation options:
certbot certonly --standalone -d foo.example.com --pre-hook "service tomcat stop" --post-hook "service tomcat start" --renew-hook "/root/update-tomcat-cert.sh"
If your cert isn’t yet due for renewal, you can add the
--force-renewal option to force it to renew early. If that works… if you installed certbot from the Ubuntu PPA as described in the tutorial, it should renew automatically after that. If you installed it from git or certbot-auto instead, you’ll need to create a cron job or systemd timer to run
certbot-auto renew twice a day (preferably at a randomly chosen minute, not exactly on the hour).
Note that this will take Tomcat offline briefly during the renewal process (only when the cert is due for renewal, that is, once every two months, not twice a day when the cron job runs). There may be an alternative procedure that wouldn’t require taking Tomcat offline, but you’d have to ask someone with less-stale Tomcat knowledge about that.
I run a few Tomcat services in prod, and my 2 cents is to not bother. Run a reverse proxy in front of Tomcat (haproxy, nginx, whatever) to handle both the automated certificate issuance part, as well as SSL termination itself.
There’s a problem with each Tomcat installation being a bit of a unique snowflake when it comes to the routing of requests. It’s not clear to me that there’s a generalized approach to facilitate the webroot challenges without the user having a sophisticated understanding of their own Tomcat configuration (or being lucky), at which point they wouldn’t be asking these questions anyway.
There are other problems, like the question of reloading the certificate without downtime (possible to re-bind the HTTPS connector but it’s obnoxious) and even ensuring that you’re running the correct “production” SSL provider.