1

I recently (and I think it was on either ServerFault, StackOverflow, or some other StackExchange forum) found out that Bitnami stacks provide a tool for using Let's Encrypt, one that apparently uses something other than certbot (something called "lego," is it?).

We have a Bitnami Trac/SVN stack running on an AWS EC2 instance (original Amazon Linux). I note that there are apparently two separate httpd instances present on the box; the one in the Bitnami stack is the active one, hosting Trac and SVN. (I think I started the other one, some months ago, in connection with a failed attempt to get certbot working, and may have left it up, but it isn't actually doing much of anything.)

The Bitnami httpd is set up for HTTP on port 81 (which is not currently reachable from the outside), and HTTPS on port 8000 (which is reachable), and is currently using a cert from Comodo, which expires in July.

And I don't remember what the original "as-delivered" port configuration was for the httpd in the Bitnami stack.

I've been reading the instructions for this "bncert-tool," and I'm wondering whether it's going to work with our setup. From my failed experiments with certbot, I was under the impression that Let's Encrypt expects to find http open on 80.

Can anybody shed any light on this?

May 18 Update

I finally remembered this project at a time when I could actually devote some time to it. I cloned the instance to a spot instance, and then (1) disabled the "stock" httpd that came with Linux, and (2) changed the httpd in the Bitnami stack to listen on 80. When I ran bncert-tool, I got this:

An error occurred creating certificates with Let's Encrypt:

acme: Error -> One or more domains had a problem:
[test.wintouch.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized 
:: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url:

Now what?

(I have saved the log file.)

May 22 Update

It occurred to me that as the server is currently configured, it is impossible to get to anything without a password.

So I tried another spot instance. After some futzing around, I configured it so that it listens on 80, without a password, and serves a static page on that port, located far away from the SVN and Trac data.

But the results were exactly the same as before. As before I terminated the spot request and removed the Route 53 A record as part of the cleanup.

After the day's experiment, I looked into setting up my spot instance from whatever it was I used when I set up the original, and discovered something rather odd: all of the Bitnami SVN and Trac AMIs I could see are either Debian or Ubuntu. But this is on Amazon Linux (original, not Amazon Linux 2). So either it's from an AMI that no longer exists, or I spun up the instance from a "vanilla" Amazon Linux AMI, and then installed the Bitnami SVN/Trac stack on it.

I will note that the stack, including bncert-tool, does not live at /opt/bitnami, but at /opt/trac-1.2.3-11

So then, stymied about inspecting an "as-delivered" configuration, I looked around, wondering what bncert-tool uses to find the stack, and I eventually found /opt/trac-1.2.3-11/properties.ini

hostname=
[Support]
installed_components=apache
apache_logs=apache{,2}/logs/error*log logs/error_log
apache_conf=apache{,2}/conf/{*.conf,bitnami/*.conf} etc/httpd.conf apps/*/conf/ht*.conf
apache_acl=apache apache2
[Apache]
apache_server_port=81
apache_user=daemon
apache_group=daemon
apache_server_ssl_port=443
apache_root_directory=/opt/trac-1.2.3-11/apache2
apache_htdocs_directory=/opt/trac-1.2.3-11/apache2/htdocs
apache_domainname=ip-172-31-8-195.us-east-2.compute.internal
apache_configuration_directory=/opt/trac-1.2.3-11/apache2/conf
apache_version=2.4.39
[Subversion]
subversion_port=3690
subversion_root_directory=/opt/trac-1.2.3-11/subversion

which appears unchanged since installation (everything in /opt/trac-1.2.3-11 has a datestamp of June 6, 2019).

Could it be that bncert-tool uses that configuration file, and already is telling Let's Encrypt to use port 81 instead of 80?

I will note that contrary to the above configuration file, the Bitnami instance of httpd listens for SSL/TLS on 8000, not 443, a Tomcat server (independent of the Bitnami stack) listens on 8443 (and shows up in netstat -l --numeric-ports as) 8443, mapped into 443 via iptables, and nothing listens directly on port 443.

hbquikcomjamesl
  • 219
  • 1
  • 13

2 Answers2

1

Bitnami Engineer here,

You are correct. The Bitnami HTTPS configuration tool uses Lego, a Let's Encrypt client written in Go. Our tool launches the lego server (for Let's Encrypt to verify it) using the port 80 so that port should be reachable from outside your network. If that's not the case, you will need to use other tool (you can use lego directly) and set the port you want to use to perform the verification. For example, you can download the lego tool and try to use the port 81 by running these commands:

cd /tmp
curl -Ls https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -
tar xf lego_v3.6.0_linux_amd64.tar.gz
sudo mkdir -p /opt/bitnami/letsencrypt
sudo mv lego /opt/bitnami/letsencrypt/lego

sudo /opt/bitnami/ctlscript.sh stop

sudo /opt/bitnami/letsencrypt/lego --http --http.port 81 --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run

This should generate a new certificate. You will need to configure them later in the Apache's configuration. You can find more information here

https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach

Jota Martos
  • 301
  • 1
  • 4
  • I finally remembered this project at a time when I could actually devote some time to it. See "May 18 Update" in question. – hbquikcomjamesl May 18 '20 at 22:19
  • The domain is not configured (https://www.whatsmydns.net/#A/test.wintouch.net). Please configure it before running the lego tool – Jota Martos May 19 '20 at 07:08
  • It was configured at the time I ran the experiment. I removed the "A" record when I terminated the test spot-instance. To do otherwise would be irresponsible, as the IP address could end up belonging to anybody. – hbquikcomjamesl May 22 '20 at 20:37
  • I ran another experiment today, and updated the question with what I found. – hbquikcomjamesl May 22 '20 at 23:10
0

I ultimately ended up using the "alternative approach" in the link Mr. Martos supplied, with a few changes not mentioned in the instructions:

If port mapping is involved (e.g., 8443 appearing as 443 from the outside, via iptables), then try adding parameters "--http.port :80 --tls.port :8443" (or whatever your mapping requires) to the lego invocation. Once those parameters were added, Lego worked perfectly. Also note that shutting down servers is important when using Lego: it needs to briefly take over the ports.

Also, if you then need to make the certs available to a Tomcat server, and Tomcat rejects them, you can use openssl to convert them to a PKCS12 keystore (this is thanks to Tomcat developer Christopher Schultz, on the Tomcat Users' list-server), which is much easier for Tomcat to deal with.

hbquikcomjamesl
  • 219
  • 1
  • 13