[QUOTE]Это не так, мы ничего не удаляем из конфигов, если попытка была неудачная, rollback там отсутствует. До валидного завершения операций с LE - мы не добавляем настройки сертифкатов в конфиги веб-серверов.
[/QUOTE]
угу детально разобрал, но сути не меняет.
[QUOTE]
Но согласна, мы можем получать новый сертификат с отдельным конфигом и только потом добавлять его в основной для всех. Зафиксирую это кейс, исправим.[/QUOTE]
Нет, это ничего не изменит
Что произойдет если хоть один из доменов добавить ААА запись? или изменит А запись на другй сервер ( не удаляя сайт)
Правильно фейл при генерации, и мы опять получаем невозможность ПОВТОРНОГО получения сертификата для всех сайтов.
Да новые сертификаты будут выдаваться, а вот старые в общем списке опять не смогут обновиться по той же причине, эта шляпа "dehydrated" останавливает генерацию сертификатов из списка при первой же ошибке а не продолжает для остальных доменов.
[QUOTE][TABLE][TR][TH]Цитата[/TH][/TR][TR][TD][URL=https://dev.1c-bitrix.ru/community/webdev/user/108113/]Виктор Таран[/URL] написал:
Так же битрикс ВМ уже видит сертификаты но они не подключены, и для подключения естественно выкинет ошибку полной проверки, в общем маразм крепчал.[/TD][/TR][/TABLE]Не понимаю о чем Вы говорите, ВМ видит сертифкаты только если они подключены к сайту, до этапа получения сертифкатов от LE они не будут прописаны в сайт. Мы не ведем учет сертифкатов, которых нет в конфигах веб-сервера.[/QUOTE]
Все просто, ключ сгенерирован, и список ключей к сайту вм уже видит выводя эти ключи в общий список. Однако, "-с --forse" - дало фейл и в результате записи в конфигах nginx не сделалны.
В результате вм показывает что ключи есть и сайт с ssl но их там нет, а удосужиться удалить данные о этих ключах при фейле в конце так же никто не удосужился.
В этом месте должна быть проверка которая видит реальные сертификаты и обходит dehydrated стороной вообще не трогая его поскольку есть уже все данные и дергать кривой демон нет необходимости. Но такой проверки нет в результате мы получаем что сертификаты уже есть но поставить вм их не в состояни
[QUOTE][TABLE][TR][TH]Цитата[/TH][/TR][TR][TD][URL=https://dev.1c-bitrix.ru/community/webdev/user/108113/]Виктор Таран[/URL] написал:
0 12 * * 6 root /opt/webdir/bin/bx-dehydrated
0 2 * * 6 root /opt/webdir/bin/bx-dehydrated[/TD][/TR][/TABLE]Только второй наш и я не помню, чтобы мы использовали 12 часов дня, хоть раз.
И в скрипте только[/QUOTE]
без комментариев:
Bitrix virtual appliance version 7.4.0[CODE]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
* * * * * bitrix test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1
0 12 * * 6 root /opt/webdir/bin/bx-dehydrated
0 2 * * 6 root /opt/webdir/bin/bx-dehydrated[/CODE]
Bitrix virtual appliance version 7.4.1
[CODE][root@dev ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
* * * * * bitrix test -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php && { /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php; } >/dev/null 2>&1
0 2 * * 6 root /opt/webdir/bin/bx-dehydrated[/CODE]Ну для совести я не сказал на какой версии ВМ
[QUOTE][TABLE][TR][TH]Код[/TH][/TR][TR][TD] --cron (-c) Sign/renew non-existent/changed/expiring certificates.[/TD][/TR][/TABLE]Без нее он выпустит только сертификаты, которые устареют в ближайшие 20 дней:[/QUOTE]
Простите а какая у нас задача, я забыл?
Еще раз Рыба отдельно, котлеты отдельно. Задача создать сертификат для данного сайта " и в меню так и называется" ни про какие обновления сертификатов
ни про какие сертификаты для других сайтов разговора не шло.
Задача выпустить сертификат 1 сайту и применить его к 1 домену ни больше ни меньше НИКАКИХ общих проверок быть не должно, это вообще другая задача![QUOTE][TABLE][TR][TH]Цитата[/TH][/TR][TR][TD][URL=https://dev.1c-bitrix.ru/community/webdev/user/108113/]Виктор Таран[/URL] написал:
too many certificates already issued for exact set of domains: site.ru,[URL=http://www.site.ru/]www.site.ru[/URL][/TD][/TR][/TABLE]Только сценарий ansible и выпуск сертифката содержит --force.
По косвенным данным предположу, у Вас всего скорее была обратная ситуация, когда сертификат Вы выпустили, но что-то не срослось на уровне nginx конфигов (возможно, был какой-то ручной кастом), когда исправили кастом и начали выпускать сертификат - нарвались уже на ошибку LE.
[/QUOTE]
ЧИСТАЯ ВМ ситуацию эмалировал на разных серверах, ошибка возникает постоянно! И да сертификат на который он уже потратил ошибки реально есть и судя по датам сертификатов, они появились практически моментально.
И главное ЭТО НЕ ТОТ ДОМЕН КОТОРЫЙ В ДАННЫЙ МОМЕНТ ГЕНЕРИРУЕТСЯ!!!!
Если бы это был хотя бы он, вопросов бы небыло, это активный и рабочий домен, если его из списка обновлений то на следующий день следующий домен по списку выдает такое веселое сообщение, такое ощущение что по крону кто-то реально тратит попытки.
А теперь смотрим на дары сертификатов
[CODE]-rw------- 1 bitrix bitrix 3247 Sep 18 13:02 privkey-1568800962.pem
-rw------- 1 bitrix bitrix 3243 Sep 18 13:04 privkey-1568801057.pem
-rw------- 1 bitrix bitrix 3243 Sep 18 13:07 privkey-1568801275.pem
-rw------- 1 bitrix bitrix 3243 Sep 18 13:20 privkey-1568802027.pem
-rw------- 1 bitrix bitrix 3247 Sep 18 13:57 privkey-1568804234.pem
-rw------- 1 bitrix bitrix 3243 Sep 18 13:57 privkey-1568804249.pem
-rw------- 1 bitrix bitrix 3243 Sep 18 14:12 privkey-1568805145.pem
-rw------- 1 bitrix bitrix 3243 Sep 20 12:49 privkey-1568972979.pem
-rw------- 1 bitrix bitrix 3243 Sep 20 12:58 privkey-1568973490.pem
-rw------- 1 bitrix bitrix 3247 Sep 20 13:04 privkey-1568973881.pem[/CODE]они действительно сожрали все попытки.
И я сегодня добавлял сертификаты и вижу что даже для сайта который уже имел сертификат были попытки, хотя он был сделан 18 числа и даты там явно нормальные.
Итого:
Нужно полностью отказаться от общего списка доменов, вешать на крон обновление каждого сайта индивидуально, будем реалистами LE не является приоритетом для bitrix как и сама VM и косяков останется в этом месте миллион, пусть они будут хотя бы изолированы друг от друга а не вешать весь механизм генерации.
Нужна проверка на физическое существование сертификата в данный момент с активной датой, и вообще не трогать dehydrated, поскольку попыток мало это обезопасит от повторных генераций существующего сертификата, офтоп из за чего так происходит, просто если сертификат уже есть локально не нужно шевелить кривого демона.
Генерация и поддержка актуальных состояний сертификатов это разные задачи !
Поисковые систему ТРЕБУЮТ ssl подписанных сертификатов не просят не рекомендуют а ТРЕБУЮТ
Как следствие сертификат должен выпускаться по умолчанию как только будет техническая возможность на это (А запись + успешная попытка генерациию)
Если сертификат не может выпуститсья только тогда самоподписанный.
Кастом и есть кастом без изменений.
НО дефолт LE
В идеале перейти на certbot он как минимум официальный софт и имеет драй ран.
Ну а теперь самое главное.
1. Когда ждать фикса в релизе как минимуму сертификат должен возвращять статус только по себе !