讓我們用 Bitnami 加密，有一些奇怪的埠號
我最近（我認為它是在 ServerFault、StackOverflow 或其他一些 StackExchange 論壇上）發現 Bitnami 堆棧提供了一種使用 Let’s Encrypt 的工具，它顯然使用了 certbot 以外的東西（叫做“樂高”，是嗎？ ？）。
我們有一個在 AWS EC2 實例（原始 Amazon Linux）上執行的 Bitnami Trac/SVN 堆棧。我注意到盒子上顯然有兩個單獨的 httpd 實例；Bitnami 堆棧中的一個是活動的，託管 Trac 和 SVN。（我想我幾個月前開始了另一個，與嘗試使 certbot 工作失敗有關，並且可能已經放棄了它，但它實際上並沒有做任何事情。）
Bitnami httpd 在埠 81（目前無法從外部訪問）上設置 HTTP，在埠 8000（可訪問）上設置 HTTPS，並且目前使用 Comodo 的證書，該證書將於 7 月到期。
而且我不記得 Bitnami 堆棧中 httpd 的原始“傳遞”埠配置是什麼。
我一直在閱讀這個“bncert-tool”的說明，我想知道它是否適用於我們的設置。從我對 certbot 的失敗實驗中，我的印像是 Let’s Encrypt 期望在 80 上找到打開的 http。
任何人都可以對此有所了解嗎？
5月18日更新
我終於在我真正可以投入一些時間的時候想起了這個項目。我將該實例複製到一個現場實例，然後（1）禁用 Linux 附帶的“stock”httpd，（2）將 Bitnami 堆棧中的 httpd 更改為監聽 80。當我執行 bncert-tool 時，我得到了這：
使用 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:怎麼辦？
（我已經保存了日誌文件。）
5月22日更新
我突然想到，由於目前配置了伺服器，因此沒有密碼就不可能訪問任何內容。
所以我嘗試了另一個現場實例。經過一番折騰，我對其進行了配置，使其無需密碼即可偵聽 80，並在該埠上提供靜態頁面，該埠遠離 SVN 和 Trac 數據。
但結果和以前完全一樣。和以前一樣，我終止了現場請求並刪除了 Route 53 A 記錄作為清理的一部分。
在一天的實驗之後，我研究了設置原始實例時使用的任何我的 Spot 實例，並發現了一些相當奇怪的東西：我能看到的所有 Bitnami SVN 和 Trac AMI 都是 Debian 或 Ubuntu。但這是在Amazon Linux（原始版本，而不是 Amazon Linux 2）上。因此，要麼它來自一個不再存在的 AMI，要麼我從一個“普通”Amazon Linux AMI 啟動實例，然後在其上安裝 Bitnami SVN/Trac 堆棧。
我會注意到，包括 bncert-tool 在內的堆棧不在/opt/bitnami 中，而是在 /opt/trac-1.2.3-11
因此，由於無法檢查“傳遞時”的配置，我環顧四周，想知道 bncert-tool 使用什麼來查找堆棧，最終我找到了 /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自安裝以來似乎沒有變化（/opt/trac-1.2.3-11 中的所有內容都具有 2019 年 6 月 6 日的日期戳）。
可能是 bncert-tool 使用了該配置文件，並且已經告訴 Let’s Encrypt 使用埠 81 而不是 80？
我會注意到，與上述配置文件相反，httpd 的 Bitnami 實例在 8000 上偵聽 SSL/TLS，而不是 443，Tomcat 伺服器（獨立於 Bitnami 堆棧）在 8443 上偵聽（並顯示在 netstat -l – numeric-ports as) 8443，通過 iptables 映射到 443，沒有任何東西直接監聽 443 埠。
我最終在 Martos 先生提供的連結中使用了“替代方法”，並在說明中未提及一些更改：
如果涉及埠映射（例如，8443 通過 iptables 從外部顯示為 443），則嘗試將參數“–http.port :80 –tls.port :8443”（或您的映射需要的任何內容）添加到樂高呼叫。一旦添加了這些參數，樂高就完美地工作了。另請注意，在使用 Lego 時關閉伺服器很重要：它需要短暫接管埠。
此外，如果您需要將證書提供給 Tomcat 伺服器，而 Tomcat 拒絕它們，您可以使用 openssl 將它們轉換為 PKCS12 密鑰庫（這要感謝 Tomcat 使用者列表伺服器上的 Tomcat 開發人員 Christopher Schultz )，這對 Tomcat 來說更容易處理。
Bitnami 工程師在這裡，
你是對的。Bitnami HTTPS 配置工具使用 Lego，一個用 Go 編寫的 Let’s Encrypt 客戶端。我們的工具使用埠 80 啟動樂高伺服器（讓 Let’s Encrypt 驗證它），以便可以從您的網路外部訪問該埠。如果不是這種情況，您將需要使用其他工具（您可以直接使用樂高）並設置您要用於執行驗證的埠。例如，您可以下載樂高工具並通過執行以下命令嘗試使用埠 81：
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這應該生成一個新證書。您將需要稍後在 Apache 的配置中配置它們。您可以在這裡找到更多資訊
https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/#alternative-approach