Использование Lets Encrypt SSL для нескольких серверов Apache с распределенным трафиком
У меня возникли проблемы с настройкой Let's Encrypt для пары веб-сайтов, которые установлены на двух разных серверах, и трафик распределяется между ними через HAProxy.
На серверах есть несколько VHosts / доменов, для каждого из которых потребуются сертификаты SSL. Ради этого сообщения, допустим, они:
- foo.some-site.com
- bar.some-site.com
Обе эти записи A настроены с двумя IP-адресами. Я могу проверить с помощью nwtools.com или просто nslookup, что обе записи A foo.some-site.com и bar.some-site.com разрешают одни и те же два IP-адреса. И я знаю, что Let's Encrypt требует, чтобы у виртуального хоста была действительная запись, чтобы он мог выполнять поиск.
Я планировал запустить настройку Lets Encrypt на обоих серверах для всех vhosts, и на одном из них это сработало, но когда я перешел на второй, я получил сообщение об ошибке:
[root@server httpd]# /opt/letsencrypt/letsencrypt-auto --apache -d foo.some-site.com
Checking for new version...
Requesting root privileges to run letsencrypt...
/root/.local/share/letsencrypt/bin/letsencrypt --apache -d foo.some-site.com
Failed authorization procedure. foo.some-site.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: foo.some-site.com
Type: connection
Detail: Failed to connect to host for DVSNI challenge
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
Может быть, это из-за того, что он выполняет поиск или пытается свернуть foo.some-site.com , и он может быть направлен на другой сервер? Я не уверен, какое это имеет значение, поскольку на обоих есть одинаковые VHosts, если только LetsEncrypt не прослушивает соединение, которое оно устанавливает ...
Что меня сбивает с толку, так это то, что у одного из них он отлично сработал (скажем, bar.some-site.com ), так почему же он работал на одном сайте, а на другом не работал с точным такая же установка?
Если кто-нибудь знает, как настроить Lets Encrypt для одних и тех же виртуальных хостов на двух разных серверах, мы будем очень благодарны за помощь!
Возможно, это из-за того, что он делает поиск или пытается скрутить foo.some-site.com, и он может быть направлен на другой сервер?
Да, скорее всего.
LE должен подключиться обратно к серверу, на котором вы запускаете LE-клиента, как часть процесса проверки домена с ответом на вызов-ответ. Не вдаваясь в подробности, LE-клиент на самом деле временно делает определенный файл доступным на вашем веб-сервере, который LE-сервер должен быть в состоянии использовать для проверки владения доменом.
Выполнение этой команды на всех внутренних серверах является ненужным и громоздким. Запустите ее один раз, а затем скопируйте ключ и цепочку сертификатов на остальные внутренние серверы.
Что меня сбивает с толку, так это то, что она отлично работает на одном из них (скажем, на другом). bar.some-site.com), так почему же он работает на одном сайте, но не работает для еще один с точно такой же установкой?
Потому что тебе повезло? :) Возможно, что случайно ваш балансировщик нагрузки один раз направил запросы LE в нужное место, но не сделал этого во второй раз.
Существует несколько подходов к сценариям, включающим несколько веб-серверов / серверов приложений / балансировщиков нагрузки. Вы можете прочитать о некоторых из них в Официальном руководстве по интеграции Let's Encrypt для более крупных сред.
Есть несколько изящных способов сделать это, например:
- перенаправление всех запросов проверки на один хост проверки / host pool
- выполнение всего управления сертификатами в автономном режиме (т.е. запрос, обновление и распространение ключей с вашего хоста управления, а не на ваших веб-серверах)
Что имеет смысл для вас, будет зависеть от ваших предпочтений и конкретной среды требования.