Недавно я (и я думаю, что это было на ServerFault, StackOverflow или другом форуме StackExchange) обнаружил, что стеки Bitnami предоставляют инструмент для использования Let's Encrypt, который, очевидно, использует что-то другое, кроме certbot (что-то под названием «lego», не так ли? ?).
У нас есть стек Bitnami Trac / SVN, работающий на инстансе AWS EC2 (оригинальный Amazon Linux). Замечу, что на коробке явно присутствуют два отдельных экземпляра httpd; тот, что находится в стеке Bitnami, является активным, на нем размещены Trac и SVN. (Думаю, я запустил другой несколько месяцев назад в связи с неудачной попыткой заставить certbot работать, и, возможно, оставил его, но на самом деле он ничего не делает.)
Bitnami httpd настроен для HTTP на порту 81 (который в настоящее время недоступен извне) и HTTPS на порту 8000 (который доступен), и в настоящее время использует сертификат от Comodo, срок действия которого истекает в июле.
И я не помню, какой была исходная конфигурация порта «как доставлено» для httpd в стеке Bitnami.
Я читал инструкции к этому «bncert-tool», и мне интересно, будет ли он работать с нашей установкой. После неудачных экспериментов с certbot у меня сложилось впечатление, что Let's Encrypt ожидает обнаружить http открытым на 80.
Кто-нибудь может пролить свет на это?
Я наконец вспомнил об этом проекте в то время, когда действительно мог посвятить ему некоторое время. Я клонировал экземпляр в спотовый экземпляр, а затем (1) отключил "стандартный" httpd, поставляемый с Linux, и (2) изменил httpd в стеке Bitnami для прослушивания на 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:
Что теперь?
(Я сохранил файл журнала.)
Мне пришло в голову, что, поскольку сервер в настоящее время настроен, невозможно добраться до что-нибудь без пароля.
Итак, я попробовал другой спот. Поработав немного, я настроил его так, чтобы он прослушивал 80 без пароля и обслуживал статическую страницу на этом порту, расположенную далеко от данных SVN и Trac.
Но результаты были точно такими же, как и раньше. Как раньше я прекратил спотовый запрос и удалил запись Route 53 A как часть очистки.
После дневного эксперимента я попытался настроить свой спотовый экземпляр из того, что я использовал, когда настраивал оригинал, и обнаружил кое-что довольно странное: все Bitnami SVN и Trac AMI, которые я мог видеть, являются либо Debian, либо Ubuntu. Но этот находится на Amazon Linux (оригинальном, а не Amazon Linux 2). Так что либо это из AMI, которого больше не существует, либо я создал экземпляр из «ванильного» AMI Amazon Linux, а затем установил на него стек 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 имеет дату 6 июня 2019 г.).
Может быть, bncert-tool использует этот файл конфигурации и уже есть говорите Let's Encrypt использовать порт 81 вместо 80?
Замечу, что, в отличие от приведенного выше файла конфигурации, экземпляр Bitnami httpd прослушивает SSL / TLS на 8000, а не на 443, сервер Tomcat (независимо от стека Bitnami) прослушивает 8443 (и отображается в netstat -l - numeric-ports как) 8443, преобразованный в 443 через iptables, и ничего слушает напрямую порт 443.
Bitnami Engineer здесь,
Ты прав. Инструмент настройки Bitnami HTTPS использует Lego, клиент Let's Encrypt, написанный на Go. Наш инструмент запускает сервер lego (чтобы Let's Encrypt проверил его), используя порт 80, так что порт должен быть доступен из-за пределов вашей сети. Если это не так, вам нужно будет использовать другой инструмент (вы можете использовать lego напрямую) и установить порт, который вы хотите использовать для выполнения проверки. Например, вы можете загрузить инструмент lego и попробовать использовать порт 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
В конце концов, я использовал «альтернативный подход» из ссылки, предоставленной г-ном Мартосом, с некоторыми изменениями, не упомянутыми в инструкциях:
Если задействовано сопоставление портов (например, 8443 отображается как 443 извне через iptables), попробуйте добавить параметры «--http.port: 80 --tls.port: 8443» (или все, что требуется для сопоставления) в lego призыв. Как только эти параметры были добавлены, Lego заработало отлично. Также обратите внимание, что выключение серверов важно при использовании Lego: он должен ненадолго занять порты.
Кроме того, если вам затем нужно сделать сертификаты доступными для сервера Tomcat, а Tomcat отклоняет их, вы можете использовать openssl для преобразования их в хранилище ключей PKCS12 (это благодаря разработчику Tomcat Кристоферу Шульцу на сервере списка пользователей Tomcat ), с которым Tomcat справиться намного проще.