The issue was resolved.
To be confident that your server is really www.austinapps.net, Let’s Encrypt uses “challenges”.
The TLS-SNI-01 challenge that Let’s Encrypt is trying to perform according to your error message needs for your HTTPS web server to know how to complete this challenge. Today most popular web servers do not know. If you weren’t running a HTTPS server, the certbot software would function as one, and solve the challenge for itself, but even if you did that to get an initial cert, you’d have to stop Tomcat every time you renew which is annoying. Still, if you’re just anxious to see something work at all, stopping Tomcat should allow this to work (if it doesn’t please include as much error text as possible).
HTTP-01 is another challenge you can ask Let’s Encrypt to do instead, to solve that you need to be able to reply to an HTTP GET for something starting /.well-known/acme-challenge/ with the correct answer, the easy way for most servers is to have them just serve up files from a matching directory in the filesystem and then the certbot software is told where the files need to go and it creates any files needed to solve the challenge. But I do not know if you can use Tomcat this way, if so, the feature you need is “webroot” mode and hopefully instructions you’re reading mentioning this.
If Tomcat doesn’t know how to serve up files from the filesystem or you don’t like that approach, a final option is DNS-01 but the certbot software doesn’t (I believe) yet know how to solve that challenge. Several clients written in shell scripting languages can though, they’re listed near the top of this list:
However you may need to develop your own shell scripts to use Google domain APIs to modify your DNS records in order to pass this challenge, so that could be pretty intimidating if you’re not a confident programmer.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.