SystemdDoctor
служба не работает сертификаты права

Служба не читает закрытый ключ TLS

Закрытый ключ должен быть недоступен посторонним, но доступен службе. Решается это группой, а не расширением прав: ключ остаётся с правами 0640, а служба входит в группу-владельца.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Ключ доступен только root, а служба работает от другого пользователя

    Обычная схема для веб-серверов — главный процесс от root — тут не работает: приложения на языках высокого уровня читают ключ уже от своего пользователя.

  2. Закрыт каталог с ключами

    Каталог /etc/ssl/private часто имеет права 0700. Даже при верных правах на файл войти в каталог нельзя.

  3. Ключ перезаписан обновлением сертификата

    Автообновление создаёт новые файлы с правами по умолчанию, и настроенный доступ теряется. Служба перестаёт работать через два месяца после настройки.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Права на каждом уровне пути.

namei -l /путь/к/ключу

Проверка доступа от имени пользователя службы.

sudo -u app test -r /путь/к/ключу && echo читается || echo отказ

Сообщение службы о невозможности прочитать ключ.

journalctl -u myapp.service -n 20 --no-pager | grep -iE "key|permission"

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Ключ доступен только root, а служба работает от другого пользователя
Почему происходит
Обычная схема для веб-серверов — главный процесс от root — тут не работает: приложения на языках высокого уровня читают ключ уже от своего пользователя.
Как проверить
Посмотрите права и пользователя службы. 
sudo ls -l /etc/ssl/private/site.key
systemctl show myapp.service -p User
Как исправить
Создайте группу для доступа к сертификатам, включите в неё пользователя службы и назначьте её владельцем ключа с правами 0640. 
sudo groupadd -f tls-readers
sudo chgrp tls-readers /etc/ssl/private/site.key
sudo chmod 640 /etc/ssl/private/site.key
2. Закрыт каталог с ключами
Почему происходит
Каталог /etc/ssl/private часто имеет права 0700. Даже при верных правах на файл войти в каталог нельзя.
Как проверить
Пройдите по пути целиком. 
namei -l /etc/ssl/private/site.key
Как исправить
Дайте группе право на вход в каталог (бит x) либо положите ключ в свой каталог с нужными правами.
3. Ключ перезаписан обновлением сертификата
Почему происходит
Автообновление создаёт новые файлы с правами по умолчанию, и настроенный доступ теряется. Служба перестаёт работать через два месяца после настройки.
Как проверить
Посмотрите время изменения файла и права. 
sudo ls -l --time-style=full-iso /etc/letsencrypt/live/*/privkey.pem 2>/dev/null
Как исправить
Добавьте перехватчик после обновления, который приводит права в порядок, — иначе проблема вернётся при следующем обновлении.

Пример вывода

Служба от обычного пользователя не читает ключ. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

myapp[4600]: fatal: load key: open /etc/ssl/private/site.key: permission denied

$ sudo ls -l /etc/ssl/private/site.key
-rw------- 1 root root 1704 Sep 10 11:20 /etc/ssl/private/site.key

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация certbot: перехватчики после обновления документация программы
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено ключом 0600 от root при службе от обычного пользователя.     собственная проверка, systemd 255
    сверено 15 сентября 2026