LINUX.ORG.RU
Форум — Admin  

acme.sh - генерация сертификата под non-root user

 ,


0

1

Изначально на почтовом сервере SSL сертификат генерировался от root и все конфиги хранятся в /root/.acme.sh. Текущий сертификат валидный. Для генерации нового сертификата под новым юзером и установки acme.sh в /opt я выполнил следующие шаги:

# useradd -m -s /usr/sbin/nologin -r -U uzer
# chmod 700 /home/uzer
# visudo
uzer   ALL=(ALL) NOPASSWD: /bin/systemctl reload postfix.service
# chown uzer.postfix /etc/postfix/ssl
# chmod 710 /etc/postfix/ssl
# chown root.uzer /opt
# chmod 775 /opt

# sudo -s -u uzer bash
bash: /root/.bashrc: Permission denied
$ cd /opt/
$ git clone https://github.com/acmesh-official/acme.sh.git
$ cd acme.sh
$ cd /opt/acme.sh

Устанавливаю acme удачно

$ ./acme.sh --install --home '/opt/acme' --config-home '/opt/acme/config' --cert-home  '/opt/acme/cert' --accountemail  'uzer@domain.com' --accountkey '/opt/acme/account.key' --accountconf '/opt/acme/myaccount.conf' --useragent  "this is my client."

Но когда пытаюсь сгенерировать сертификат через DNS API

$ ./acme.sh --issue --dns dns_inwx -d domain.com -d domain2.com --force

ошибка прав доступа

grep: /root/.acme.sh/domain.com/domain.com.conf: Permission denied
[Mon Jan  9 18:55:24 CET 2023] Using CA: https://acme.zerossl.com/v2/DV90
mkdir: cannot create directory ‘/root’: Permission denied
mkdir: cannot create directory ‘/root’: Permission denied
mkdir: cannot create directory ‘/root’: Permission denied
[Mon Jan  9 18:55:24 CET 2023] Can not create path: /root/.acme.sh/ca/acme.zerossl.com/v2/DV90
[Mon Jan  9 18:55:24 CET 2023] Create account key error.
[Mon Jan  9 18:55:24 CET 2023] Create account key error.
[Mon Jan  9 18:55:24 CET 2023] Please add '--debug' or '--log' to check more details.
[Mon Jan  9 18:55:24 CET 2023] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

Может сначала нужно удалить первоначальный acme из /root/acme.sh и тогда сертификат сможет сгенерироваться в /opt/acme c настройками в ~uzer/.acme.sh? настораживает ошибка при запуске sudo

bash: /root/.bashrc: Permission denied

Как в общих чертах правильно настроить сабж? кажется я что-то упустил…

★

Последнее исправление: leave (всего исправлений: 2)
← Wireguard и Mikrotik
миднайт командер не отображается при подключении по ssh к серверу →

Ну так у тебя acme-клиент при запуске лезет в /root/.acme.sh, чего быть по идее не должно. Ну и тебе дали уже подсказочку:

Please add '--debug' or '--log' to check more details.

Глянь конфигурацию новой установки, запусти в отладочном режиме и глянь лог…

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 2)

… такое впечатление, что ты умудрился запустить клиент с рутовыми настройками, что в принципе возможно, если ты зашел в контекст нового юзера из-под рута через sudo и у тебя не отработал ~/.profile нового юзера, куда добавляется строчка подключения файла acme.sh.env.

Поскольку ты создал юзера без возможности нормального логина, то перед запуском acme.sh тебе нужно предварительно ручками подключать переменные из acme.sh.env.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Спасибо, но у меня вроде заработало без ручного подключения переменных из acme.sh.env (они наверное сохранились когда я ранее запускал acme.sh с параметром –staging). выполнил под юзером uzer

$ export HOME=/home/uzer

сразу после

# sudo -s -u uzer bash

А можно это как-то автоматизировать без ручного запуска команды export?

zorinquen ★
() автор топика
Ответ на: комментарий от zorinquen

Сейчас воспроизвёл у себя. Да, внезапно cron отработал простую тестовую команду и при такой конфигурации, забавно.

А вот команда вида

sudo -s -u uzer bash

не простроила полностью переменные окружения при переходе под пользователя, в итоге видна нехорошая мешанина (см. env)

Советую пересоздать сперва честного пользака, под ним поставиться, и потом уже поступательно ужимать в правах.

Я в принципе под непривилегированным тоже с acme.sh работаю обычно, всё отлично.

NDfan ★
()
Ответ на: комментарий от zorinquen

В файле acme.sh.env есть две переменные, которые необходимо задавать перед запуском клиента, поскольку при установке для них были указаны недефолтные значения:

export LE_WORKING_DIR="..."
export LE_CONFIG_HOME="..."

Если залезть в исходник acme.sh, то можно увидеть, каким образом присваиваются дефолтные значения:

PROJECT_NAME="acme.sh"
...
DEFAULT_INSTALL_HOME="$HOME/.$PROJECT_NAME"
...
if [ -z "$LE_WORKING_DIR" ]; then
  _debug "Using default home:$DEFAULT_INSTALL_HOME"
  LE_WORKING_DIR="$DEFAULT_INSTALL_HOME"
fi
...
if [ -z "$LE_CONFIG_HOME" ]; then
  LE_CONFIG_HOME="$LE_WORKING_DIR"
fi

Так что, одной установки $HOME в данном конкретном случае недостаточно для того, чтобы реально были задействованы опции --home '/opt/acme' --config-home '/opt/acme/config'. У тебя сейчас клиент отработал с использованием других директорий. Чтобы были использованы нужные директории, следует предварительно заэкпортировать переменные LE_WORKING_DIR и LE_CONFIG_HOME или указать их значения прямо в строке запуска клиента:

LE_WORKING_DIR="...."  LE_CONFIG_HOME="..." /opt/acme/acme.sh ...

Ну или просто напиши дополнительный shell-скрипт с соответствующей командой.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

а у меня вроде как обе переменные LE_WORKING_DIR и CONFIG_HOME автоматически прописались в acme.sh.env после ручного запуска acme.sh. А вручную я только экспортировал имя и пароль для DNS API провайдера. Мне кажется, что когда я запускаю установку сертификата с acme.sh под юзером uzer автоматически acme использует уже сохраненные значения переменных из acme.sh.env.

Еще интересен такой момент: послу ручной установки сертификата с помощью acme, автоматически генерируется крон для юзера uzer:

27 0 * * * "/opt/acme"/acme.sh --cron --home "/opt/acme" --config-home "/opt/acme/config" > /dev/null

и этого уже достаточно для процесса автоматического обновления сертификата? Раз в сутки ночью будет запускаться крон и если нужно acme обновит сертификат. А вот скопирует ли он его также автоматически в каталог /etc/postfix/ssl, куда скопировался сертификат, ключ и fullchain.cer?

zorinquen ★
() автор топика
Ответ на: комментарий от zorinquen

Ну в принципе выше vinvlad хорошо про починку уже рассказал.

Но если с чистого листа, то я бы делал так:

useradd -m -с 'ACME updater' -d /opt/acme -r -U acme

(для нестандартного домашнего каталога, в /opt, надо выполнить правку для SELinux - при его наличии в системе)

Дальше под ним спокойно раскатывать acme.sh, пробовать выпуск сертификата (лучше на сервере Staging).

Дальше забрать shell, запретить вход по ssh, настроить логирование то или иное. Ну дальше уже по степени убывания рисков можно продолжать, в зависимости от обоснованной паранойи ).

И проверить уже целевой сценарий, по cron.

NDfan ★
()
Ответ на: комментарий от zorinquen

Конечно, остаётся ещё вопрос стыковки конфигурации Postfix с сертификатами.

Например, добавить postfix в группу к uzer, и линкануть нужные сертификаты из его домашней директории в /etc/postfix/ssl/

Возможно, пригодится расширение прав, например: 

chmod 0750 ~uzer

NDfan ★
()
Ответ на: комментарий от zorinquen

Еще интересен такой момент: послу ручной установки сертификата с помощью acme, автоматически генерируется крон для юзера uzer … А вот скопирует ли он его также автоматически в каталог /etc/postfix/ssl … ?

Конечно нет. Если ты из соображений безопасности решил запускать acme.sh не под рутом, то распихивать сертификаты тебе придется самостоятельно. Предварительно потребуется установить владельца и группу соответствующих сертификатных файлов, а также соответствующий режим доступа к этим файлам. Для этих действий в любом случае потребуется root-режим. Ну т.е. нужно написать shell-скрипт, который будет запускаться по cron-у в root-режиме и который внутри будет выполнять соответствующие действия:

  • выполняет acme.sh через sudo или su;
  • проверяется наличие новых сертификатов и устанавливаются необходимые атрибуты этих файлов;
  • сохраняются бэкап-копии старых сертификатов и на их место кладутся новые сертификаты;
  • выполняется reload или restart сервисов, использующих эти сертификаты - чтобы были задействованы новые версии сертификатов.
vinvlad ★★
()
← Wireguard и Mikrotik
Admin
миднайт командер не отображается при подключении по ssh к серверу →