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. https://crt.sh/?q=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:
*.liqid.com (never provided this when I ran the command)
I ran this command:
sudo /usr/local/bin/certbot-auto certonly --apache
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Could not choose appropriate plugin: The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(âCannot find Apache executable apache2ctlâ,)
The apache plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(âCannot find Apache executable apache2ctlâ,)
My web server is (include version):
Tomcat 8.5.47
The operating system my web server runs on is (include version):
Ubuntu 19.10
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I donât know):
yes
Iâm using a control panel to manage my site (no, or provide the name and version of the control panel):
No.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if youâre using Certbot):
certbot 0.40.1
Iâm pretty sure Tomcat isnât the same as the webserver called Apache. It might be called âApache Tomcatâ, but thatâs just the company name. Iâm also pretty sure the --apache plugin doesnât understand a bit of Tomcat.
Yes, certbot --apache is not suitable for use with Tomcat, unless you want to run a separate Apache web server which proxies connections to your Tomcat server (which may be an appropriate way to go about things).
Simplest: Use --webroot -w /path/to/your/tomcat/root (instead of --apache)
Does not require any Tomcat config modifications nor stopping service for cert issuance.
[Cert replacement requires reload - Initial activation will require TLS config inclusion]
Easy: Use --standalone method
Requires temporary shutdown of Tomcat to spin up a web server and process the cert request.
Complicated: Install a dedicated proxy to terminate TLS connections (Apache | NGINX).
May require moving ports around (firewall forwarding or listening ports)
Does not require any Tomcat config modifications nor service interruptions [after cut-over].
[Cert replacement requires proxy reload - Initial activation will require proxy TLS config inclusion]
Harder: Use a DNS authentication method.
Requires DNS service allowing automated updates (API) or manual actions (not recommended)
Insane: Write a custom program that integrates seamlessly with your Tomcat implementation.
Requires in-depth knowledge of ACME client and your Tomcat implementation, etc.
The extra difficulty in these methods is converting the certificates into the format that Tomcat understands and configuring them (what you referred to as "initial activation will require TLS config inclusion", but also note that the certificate may have to be converted again after each renewal).
Straight forward?
Did I miss something, uses iptables to redirect 80 > 8080 and 443 > 8443.
But what listens on 8080 and 8443?
[I read through it twice]
On the third read, it looks like the secret sauce is mostly the use of: --webroot --webroot-path â${CATALINA_BASE}/webapps/ROOT" openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain] -out [p12file]
Page 39: Scripting will set you free* * The actual script has a lot more detail that wonât fit here.
I do applaud him for trying to make a difficult thing simpler, but I think it may still be less than complete (at least for a novice).
I agree with both of you! Automating Certbot with Tomcat can be straightforward for someone whoâs familiar with all of the underlying technologies, and weâve seen on this forum that itâs often a significant challenge for someone whoâs trying to rely only on built-in Certbot functionality.
Just a question for clarity please. Ubuntu has a package/port called âtomcat-with-sslâ. The description says:
"Apache Tomcat with SSL activated and managed by Certbot.
Intended to use as a part to install Apache Tomcat with SSL enabled and the required certificate automatically managed by certbot (Lets Encrypt) including automatic renewals.
Note: currently if a renewal occurs tomcat will be restarted without warning.
So my question: Did you install tomcat from source, or a package manager?
In my experience, @rg305 âINSANEâ method was the solution that worked. But in the time required to debug and test it you can spin up an apache server with dozens of virtual hosts and certificates to boot. @schoen politely touches on the core of the issue. This is a âsignificant challengeâ even for a seasoned enterprise admin.
webroot can work.
certonly is a pain but can work also @Osiris posted a good link you might seriously consider looking in to.
My doctor equates tomcat with chemotherapy. Unless you have been running your server for years and just love your experience with tomcat, consider a friendlier server or take a look at Brett Suttonâs **tomcat-with-ssl option. I havenât seen anyone on this forum using it (might be wrong)
Whatever you do please update this thread so we can see the progress and learn from your experience.
Finished my rant.
I think 'certonly' is implied anyway, because there is no installer plugin for Tomcat. When you're using certbot run without an installer plugin, de facto you're running certbot certonly
