We have an Amazon Linux (not Amazon Linux 2) instance, running a fairly old Bitnami Trac/SVN stack, and also running a Tomcat server. It has two instances of httpd: the one that's part of the Bitnami stack, and the one that came with the OS. Tomcat is running independently. Lego is already present, as is bncert-tool, but the Bitnami directory is not "/opt/bitnami," but "/opt/trac-1.2.3-11."
The OS httpd, when up, listens on 80, unsecured. The Bitnami httpd listens on 8000, secured, and can also listen on 81. The Tomcat server runs independently of httpd, and listens on 8443, secured (with an iptables redirection from 443) and 7443 (also secured).
Working on a spot instance, cloned from the most recent backup of the live server, with a domain mapped to it in Route 53, and ports 80 and 443 open to the world in one of the assigned security groups, I've been attempting to follow the instructions under "Alternative Approach" on the page at https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach without success.
Skipping step 1 in the procedure, since Lego is already present, and going straight to step 2, I stopped Bitnami with "ctlscript.sh stop." I then (running under root authority) attempted to get the cert, using the command given in the procedure, adjusted to match the circumstances. (Note that the domain name has been changed, "to protect the innocent.")
sudo /opt/trac-1.2.3-11/letsencrypt/lego --tls --email="[email protected]" --domains="test.bar.net" --path="/opt/trac-1.2.3-11/letsencrypt" run
I got this:
2020/08/04 18:01:29 No key found for account [email protected]. Generating a P384 key.
2020/08/04 18:01:29 Saved key to /opt/trac-1.2.3-11/letsencrypt/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys/[email protected]
2020/08/04 18:01:30 Please review the TOS at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
Do you accept the TOS? Y/n
Y
2020/08/04 18:01:43 [INFO] acme: Registering account for [email protected]
!!!! HEADS UP !!!!
Your account credentials have been saved in your Let's Encrypt
configuration directory at "/opt/trac-1.2.3-11/letsencrypt/accounts".
You should make a secure backup of this folder now. This
configuration directory will also contain certificates and
private keys obtained from Let's Encrypt so making regular
backups of this folder is ideal.
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: Obtaining bundled SAN certificate
2020/08/04 18:01:43 [INFO] [test.bar.net] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6317334421
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: use tls-alpn-01 solver
2020/08/04 18:01:43 [INFO] [test.bar.net] acme: Trying to solve TLS-ALPN-01
2020/08/04 18:01:50 [INFO] Unable to deactivated authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6317334421
2020/08/04 18:01:50 Could not obtain certificates:
acme: Error -> One or more domains had a problem:
[test.bar.net] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge, url:
I then tried shutting down the OS httpd instance, and repeating the command. I got the same result, from the "Obtaining bundled SAN certificate" message on down.
Then, I tried shutting down Tomcat. This time, I got a different message for the last line:
[test.bar.net] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Connection refused, url:
Clearly something is wrong here, but what is my next step?
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" to the lego invocation.
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, which is much easier for Tomcat to deal with.