Можно, конечно, воспользоваться сторонними библиотеками, но я не любитель ставить что-то стороннее, если можно обойтись своими силами. Поэтому пришлось потратить время на написание и тестирование bash-скрипта с именем authenticator.sh:<\/p>\n
#!\/bin\/bash\n\n#Основные параметры\ndomain="kini24.ru"\nusername="graywolf"\npassword="********"\n# Этот параметр менять не нужно\nsubdomain=""\n\n# Корректно задаем судбдомен\n# Если обрабатывается основной домен, то субдомен будет _acme-challenge\n# Если обрабатывается субдомен, то строка будет вида _acme-challenge.subdomain\nif [[ $CERTBOT_DOMAIN = $domain ]]\nthen\n subdomain="_acme-challenge"\nelse\n subdomain="_acme-challenge.${CERTBOT_DOMAIN%.$domain}"\nfi\n\n# Чисто для информации\n\/usr\/bin\/echo "Requesting $CERTBOT_DOMAIN"\n\n# Запрос на удаления текущих записей\ntxt_delete="input_format=json&input_data={\\"username\\":\\"$username\\",\\"password\\":\\"$password\\",\\"domains\\":[{\\"dname\\":\\"$domain\\"}],\\"subdomain\\":\\"$subdomain\\",\\"record_type\\":\\"TXT\\",\\"output_content_type\\":\\"plain\\"}"\n\n# Запрос на добавления записи\ntxt_add="input_format=json&input_data={\\"username\\":\\"$username\\",\\"password\\":\\"$password\\",\\"domains\\":[{\\"dname\\":\\"$domain\\"}],\\"subdomain\\":\\"$subdomain\\",\\"text\\":\\"$CERTBOT_VALIDATION\\",\\"output_content_type\\":\\"plain\\"}"\n\n#Можно проверить при желении\n#\/usr\/bin\/echo "Certbot parameters:"\n#\/usr\/bin\/echo "Current domain: $CERTBOT_DOMAIN"\n\/usr\/bin\/echo "Validation string: $CERTBOT_VALIDATION"\n#\/usr\/bin\/echo "Delete request: $txt_delete"\n#\/usr\/bin\/echo "Add request: $txt_add"\n\n# Запрос на удаление ВСЕХ TXT записей\nif [[ $CERTBOT_DOMAIN != $domain ]]\nthen\n #\/usr\/bin\/echo "Remove all TXT records"\n \/usr\/bin\/curl --silent --data "$txt_delete" "https:\/\/api.reg.ru\/api\/regru2\/zone\/remove_record"\nfi\n\n# Запрос на создание TXT записи\n#\/usr\/bin\/echo "Add new TXT record"\n\/usr\/bin\/curl --silent --data "$txt_add" "https:\/\/api.reg.ru\/api\/regru2\/zone\/add_txt"\n\n# Проверяем что нужная TXT запись появилась. Иначе ждем пока данные обновятся\n#answer=""\n#while [[ $answer != $CERTBOT_VALIDATION ]]\n#do\n# \/usr\/bin\/echo "Requesting DNS record"\n# answer=$(\/usr\/bin\/dig @77.88.8.8 $CERTBOT_DOMAIN txt +short | \/usr\/bin\/tr -d \\" | \/usr\/bin\/egrep $CERTBOT_VALIDATION)\n# \/usr\/bin\/sleep 60\n#done\n\nif [[ $CERTBOT_REMAINING_CHALLENGES -eq 0 ]]\nthen\n sleep 15m\nfi\n\n# Выводим количество доменов, которые осталось обработать\n\/usr\/bin\/echo "Remaining challenges: $CERTBOT_REMAINING_CHALLENGES"<\/code><\/pre>Логика скрипта следующая. В начале задаются основной домен, имя пользователя и пароль от личного кабинета reg.ru. Параметр subdomain<\/i> менять не нужно, он «вычисляется» по ходу выполнения скрипта. Далее если обрабатывается основной домен, то поддомен становится равным _acme-challenge<\/i>, иначе в конец еще добавляется поддомен. Формируется строка для удаления всех (!) текущих записей типа TXT, если обрабатыается поддомен. Записи для основного домена просто добавляются (тут да, небольшой косяк, нужно немного дописать скрипт).
\nЗатем, после добавления DNS-записи скрипт должен был запрашивать все записи TXT и, после появлении нужной, продолжать выполнение, но тут скрипт уходил в бесконечный цикл, поэтому я его закомментировал полностью. Сможете исправить — буду благодарен.
\nНа последнем шаге скрипт, если доменов для регистрации не осталось, ждет 15 минут (время обновления записей у reg.ru от 15 минут до 1 часа) и возвращает управление команде certbot.<\/p>\n
Вызывается скрипт примерной такой командой:<\/p>\n
certbot certonly --manual --agree-tos --manual-public-ip-logging-ok --email admin@kini24.ru --preferred-challenges dns --server https:\/\/acme-v02.api.letsencrypt.org\/directory --domain *.jabber.kini24.ru --domain *.meet.kini24.ru --domain *.kini24.ru --domain kini24.ru --rsa-key-size 2048 --key-type ecdsa --elliptic-curve secp256r1 --redirect --uir --staple-ocsp --must-staple --hsts --manual-auth-hook \/root\/authenticator.sh<\/code><\/pre>В этой команде следующие параметры:
\ncertonly<\/i> — только получение сертификата;
\nagree-tos<\/i> — принимаем пользовательское соглашение;
\nmanual-public-ip-logging-ok<\/i> — соглашаемся на публикацию нашего IP-адреса;
\nemail<\/i> — указываем свою электронную почту для уведомлений;
\npreferred-challenges<\/i> — выбираем тип проверки. Для wildcard-сертификатов это только DNS;
\nserver<\/i> — указываем сервер сертификации;
\ndomain<\/i> — перечисляем свои (суб-)домены;
\nrsa-key-size<\/i> — указываем «размер» ключа. Значение 2048 по умолчанию, оставил на всякий случай;
\nkey-type<\/i> — тип ключа. Снова указано значение по умолчанию;
\nelliptic-curve<\/i> — «кривые». Тут тоже значение по умолчанию;
\nredirect<\/i> — перенаправлять с http на https$
\nuir<\/i> — добавляет в ответ заголовок Content-Security-Policy<\/i> со значением upgrade-insecure-requests<\/i>;
\nstaple-ocsp<\/i> — «сшивание» сертификатов;
\nmust-staple<\/i> — обязательное «сшивание»;
\nhsts<\/i> — принудительная активация защищенного режима, т. е. https;
\nmanual-auth-hook<\/i> — запуск своего скрипта.<\/p>\n",
"date_published": "2023-12-16T16:16:55+07:00",
"date_modified": "2023-12-16T16:16:15+07:00",
"tags": [
"reg.ru",
"wildcard",
"автоматическое",
"обновление",
"рег.ру",
"сертификат",
"скрипт"
],
"_date_published_rfc2822": "Sat, 16 Dec 2023 16:16:55 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "271",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "208",
"url": "https:\/\/kini24.ru\/all\/obnovlenie-servera-2\/",
"title": "Обновление сервера",
"content_html": "
Итак, попало ко мне в руки хорошее «железо», что стало неплохим поводом обновить свой сервер. Так как конфигурация слишком сильно отличалась от прежней, то систему тоже пришлось ставить заново. Поначалу не могу понять почему установка проходит нормально, а сама система после этого не грузится. Потом припомнил, что Linux с картами Intel HD Graphics так и не научился нормально работать. Что поделать, пришлось отключать в BIOS встроенную видеокарту и ставить внешнюю. Плохо то, что эта внешняя видеокарта предназначалась для установки в компьютер жены. Старое «железо» из сервера тоже должно было пойти на апгрейд ее компьютера.
\nУвы, но на работе тоже было много работы, поэтому апгрейд двух систем несколько затянулся. Затем пришлось устранять ошибки в работе веб-сервера, ибо я заодно захотел поменять некоторые настройки. Сейчас его работоспособность почти полностью восстановлена за исключением двух субдоменов: «зеркала» обновлений NOD32 и облака. Последнее из них меня волнует меньше всего, доступ к нужным файлам я могу получить и другими способами. А вот «зеркало»... На него слишком много завязано. Работа над ним пока что ведется. Написал разработчику, описал проблему, пока что жду от него ответа.
\nТакже выяснилось, что dovecot не совсем корректно работает с wildcard-сертификатами. Если быть точней, то мне удалось настроить почти все нужные почтовые клиенты (веб-интерфейс, Outlook на телефоне), кроме Thunderbird, установленного на домашнем компьютере. При попытке просмотреть почту с его помощью dovecot ругается на сертификат. Проблема, как оказалось, не новая, но рабочего решения её пока не нашел.
\nУстановил пока что другую видеокарту в компьютер жены, но она оказалась с «битой» памятью, что приводило к периодическим перезагрузкам. Интересно, сможет сервер работать без видеокарты вообще? Пока что пара моих попыток заставить его работать в таком режиме не увенчались успехом — все время «ругался» спикером. Подозреваю, что придется покупать новую, хоть какую-нибудь. Главное, чтобы присутствовала в системе.<\/p>\n",
"date_published": "2018-08-11T14:38:11+07:00",
"date_modified": "2018-08-11T14:38:06+07:00",
"tags": [
"hd graphics",
"intel",
"linux",
"nod32",
"thunderbird",
"wildcard",
"апгрейд",
"видеокарта",
"железо",
"зеркало",
"обновление",
"почта",
"сервер",
"сертификат"
],
"_date_published_rfc2822": "Sat, 11 Aug 2018 14:38:11 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "208",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "194",
"url": "https:\/\/kini24.ru\/all\/wildcard-sertifikaty-ot-lets-encrypt\/",
"title": "Wildcard сертификаты от Let’s Encrypt",
"content_html": "
За всеми событиями в жизни как-то пропустил момент, когда Let’s Encrypt стали выдавать бесплатные «wildcard» сертификаты. Иными словами, вы можете получить один сертификат на свой основной домен и все его субдомены разом. Больше не нужно беспокоиться о том, что каждый раз при создании субдомена придется создавать и новый сертификат. Нужно будет просто в конфигурационном файле указать текущий.
\nВ отличие от «стандартного» для генерирования сертификата «wildcard» нужно вручную прописать сервер для запросов. Команда будет выглядеть примерно так:<\/p>\n
# certbot certonly --server https:\/\/acme-v02.api.letsencrypt.org\/directory -d kini24.ru -d *.kini24.ru --agree-tos -m admin@kini24.ru --manual --preferred-challenges dns --must-staple --hsts --uir --staple-ocsp<\/code><\/pre>Пройдемся по параметрам, чтобы было понятней:
\n—server — указывает на сервер, который мы хотим использовать для создания сертификата;
\n-d — указываем для каких доменов мы будем создавать сертификат. Советую вам первым указывать основной домен, а не его субдомены. Сэкономите немного времени;
\n—agree-tos — принимаем условия лицензионного соглашения;
\n-m — указываем свой адрес электронной почты. Он будет использоваться как логин;
\n—manual — используем «ручной» режим работы. Думаю, что можно было и не указывать, но я хотел проконтролировать процесс;
\n—preferred-challenges — указываем предпочтительный способ проверки, что именно вы имеете доступ к администрированию домена (являетесь его владельцем);
\nОстальные параметры не обязательны, можно их не указывать.
\nПосле ввода команды вас спросят не хотите ли вы получать новости от Electronic Frontier Foundation (EFF), основателя сервиса Let’s Encrypt. Ради интереса согласился, отписаться можно в любой момент. Затем был вопрос о том хочу ли я использовать указанный email в качестве логина. Соглашаемся. А вот дальше был один нюанс, который я поначалу не понял, но, в итоге, разобрался. Следующим шагом вас просят внести TXT-запись в ресурсные записи домена. Вносим и ждем, процесс занимает некоторое время. Обычно хватает 15 минут. Нажимаем Enter, чтобы скрипт проверил наличие записи. И вот тут он выдает точно такой же запрос на внесение записи TXT, но с другим значением. Это значение нужно также внести в ресурсные записи. Если быть точней, то первую запись нужно заменить на вторую. Этакая двойная проверка. Снова минуты ожидания и жмем Enter. Если проверка прошла, то сертификат будет создан.
\nТак как у меня также используется технология HPKP, то нужно еще и генерировать новые ключи для сертификата:<\/p>\n
# openssl rsa -in \/etc\/letsencrypt\/live\/kini24.ru\/privkey.pem -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64<\/code><\/pre>Вносим изменения в конфигурационный файл веб-сервера и перезапускаем его:<\/p>\n
# systemctl restart httpd2<\/code><\/pre>",
"date_published": "2018-05-16T09:58:04+07:00",
"date_modified": "2018-05-16T09:57:46+07:00",
"tags": [
"apache",
"certbot",
"HPKP",
"let's encrypt",
"wildcard",
"бесплатно",
"инструкция",
"сервер",
"сертификат"
],
"_date_published_rfc2822": "Wed, 16 May 2018 09:58:04 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "194",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
}
],
"_e2_version": 4134,
"_e2_ua_string": "Aegea 11.3 (v4134)"
}