Файлы server.crt и server.key используются веб-сервером для установки TLS-соединения и должны быть размещены в строго определённых каталогах файловой системы. Ошибка в выборе пути или прав доступа приводит к невозможности запуска сервиса либо к утечке закрытого ключа. Поэтому размещение сертификата и ключа – это не вопрос удобства, а вопрос корректной конфигурации и безопасности сервера.
На большинстве Linux-систем сертификаты принято хранить в каталоге /etc/ssl/certs, а приватные ключи – в /etc/ssl/private. Такое разделение не случайно: каталог с ключами по умолчанию имеет ограниченные права доступа и недоступен обычным пользователям. Веб-серверу (Nginx, Apache) предоставляется доступ либо через группу, либо через запуск от привилегированного пользователя на этапе инициализации.
При использовании Nginx и Apache пути к server.crt и server.key указываются напрямую в конфигурационных файлах виртуальных хостов. Сертификат может быть доступен для чтения, тогда как ключ должен иметь права не шире 600 или 640. В системах с SELinux или AppArmor дополнительно требуется корректный контекст безопасности, иначе сервер не сможет открыть файлы даже при правильных UNIX-правах.
В сценариях с Let’s Encrypt и Certbot сертификаты размещаются в /etc/letsencrypt/live/домен/ и представляют собой симлинки на актуальные версии файлов. Перемещать их вручную не рекомендуется: вместо этого веб-сервер настраивается на чтение файлов из этого каталога. В контейнерных окружениях (Docker) сертификаты обычно монтируются как volume, чтобы избежать хранения ключей внутри образа.
Стандартные каталоги для хранения server.crt и server.key в Linux
В Linux приняты раздельные каталоги для публичных сертификатов и приватных ключей. Такое разделение упрощает контроль доступа и снижает риск чтения закрытого ключа посторонними процессами. Большинство дистрибутивов придерживается единой структуры, которую ожидают веб-серверы и утилиты управления сертификатами.
Публичные сертификаты размещаются в каталогах, доступных для чтения системными сервисами:
- /etc/ssl/certs/ – основной каталог для файлов .crt и цепочек сертификатов в Debian, Ubuntu и производных системах;
- /usr/local/share/ca-certificates/ – используется для добавления собственных корневых и промежуточных сертификатов с последующим обновлением хранилища CA;
- /etc/pki/tls/certs/ – типовой путь в RHEL, CentOS, Rocky Linux, AlmaLinux.
Приватные ключи должны храниться отдельно, в каталогах с жёсткими ограничениями прав:
- /etc/ssl/private/ – стандартное место для server.key в Debian-подобных системах, обычно с правами 700 на каталог;
- /etc/pki/tls/private/ – аналогичный каталог в системах семейства Red Hat;
- /root/ssl/ или отдельный каталог в /etc/ – допустим при ручной настройке, если обеспечены права не шире 600 для файла ключа.
Для server.key рекомендуется:
- Устанавливать владельцем пользователя root.
- Назначать группу веб-сервера (например, www-data или nginx) только при необходимости.
- Использовать права 600 или 640, исключая доступ на чтение для остальных пользователей.
Файлы server.crt могут иметь более широкие права, обычно 644, так как они не содержат конфиденциальных данных. Размещение сертификата и ключа в одном каталоге не рекомендуется даже при корректных правах, поскольку это усложняет аудит и сопровождение конфигурации.
Размещение SSL-сертификатов для Nginx: пути и требования
Nginx не использует фиксированные пути для SSL-файлов, однако на практике ожидается размещение server.crt и цепочки сертификатов в /etc/ssl/certs/, а приватного ключа server.key – в /etc/ssl/private/. Такое расположение совместимо с системными ограничениями доступа и не требует нестандартных разрешений при запуске сервиса.
В конфигурации виртуального хоста указываются абсолютные пути к файлам:
ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;
Файл сертификата должен включать полный набор: серверный сертификат и промежуточные CA в правильном порядке. Если используется отдельный файл цепочки, он объединяется с server.crt в один файл, так как Nginx читает только путь, указанный в директиве ssl_certificate.
Для server.key обязательны строгие права доступа. Ключ должен принадлежать пользователю root и иметь права не шире 600. Nginx получает доступ к ключу на этапе старта процесса, после чего привилегии сбрасываются. При невозможности чтения ключа сервер не запускается, что фиксируется в error.log без указания деталей содержимого файла.
Если используется SELinux, файлам требуется корректный контекст, например httpd_sys_content_t для сертификата и httpd_config_t или специально разрешённый тип для ключа. Без этого Nginx не сможет открыть файлы даже при корректных UNIX-правах. Изменение пути хранения без обновления контекста приводит к ошибке загрузки TLS-конфигурации.
Где хранить server.crt и server.key при использовании Apache
Apache ожидает, что SSL-сертификаты и ключи будут размещены в системных каталогах, доступных на этапе запуска демона. Наиболее распространённая схема – хранение server.crt в каталоге с сертификатами и server.key в отдельном защищённом каталоге, недоступном обычным пользователям.
Типовые пути зависят от дистрибутива и пакета Apache, но соответствуют устоявшимся стандартам:
| Тип файла | Debian / Ubuntu | RHEL / CentOS / AlmaLinux |
|---|---|---|
| server.crt | /etc/ssl/certs/ | /etc/pki/tls/certs/ |
| server.key | /etc/ssl/private/ | /etc/pki/tls/private/ |
В конфигурации виртуального хоста Apache указываются прямые пути к файлам:
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
Файл сертификата может иметь права 644, так как не содержит секретных данных. Для server.key допустимы только права 600 или 640, владелец – root. Apache читает ключ при инициализации модуля mod_ssl, поэтому доступ группе сервера требуется только в случаях нестандартного запуска процесса.
Размещение ключа внутри каталога виртуального хоста или рядом с конфигурационными файлами не рекомендуется. Apache не накладывает жёстких ограничений на путь, но системные политики безопасности и инструменты аудита ориентируются на стандартные каталоги, что упрощает сопровождение и проверку сервера.
Права доступа и владелец файлов server.crt и server.key
Файл server.key содержит закрытый ключ и должен быть защищён жёстче любых других компонентов TLS-настройки. Рекомендуемый владелец – root, так как веб-серверу требуется доступ к ключу только на этапе запуска. Стандартные права для файла – 600, что разрешает чтение и запись исключительно владельцу.
В случаях, когда веб-сервер запускается не от имени root, допускается назначение группы процесса, например www-data или nginx, с правами 640. При этом каталог, в котором находится ключ, должен иметь права не шире 750. Расширение доступа для остальных пользователей недопустимо, даже если ключ зашифрован паролем.
Файл server.crt не содержит конфиденциальных данных и может быть доступен для чтения. На практике используются права 644 с владельцем root. Это позволяет системным сервисам и инструментам проверки сертификатов читать файл без дополнительных привилегий.
Отдельное внимание требуется для каталогов. Даже при корректных правах файла server.key сервер не сможет его открыть, если отсутствует право на выполнение (x) у каталога. Для каталогов с ключами обычно применяются права 700 или 750, что исключает обход ограничений через прямой доступ к файловой системе.
При использовании SELinux или AppArmor стандартных UNIX-прав недостаточно. Файлы сертификата и ключа должны иметь разрешённый контекст безопасности, иначе доступ будет заблокирован на уровне политики, независимо от владельца и прав доступа.
Хранение server.key при использовании Let’s Encrypt и Certbot
Каталог /etc/letsencrypt по умолчанию принадлежит пользователю root и имеет строгие ограничения доступа. Файл приватного ключа создаётся с правами 600, что исключает чтение другими пользователями системы. Изменять владельца или права доступа вручную не рекомендуется, так как Certbot может перезаписать их при следующем обновлении сертификата.
Веб-серверы Nginx и Apache настраиваются на чтение ключа напрямую из каталога live. Копирование privkey.pem в другие директории нарушает механизм автоматического продления и приводит к использованию устаревшего ключа после ротации сертификата. Единственно корректный вариант – указание пути к симлинку.
При необходимости ограничить доступ веб-сервера к ключу используется запуск процесса с правами root на этапе инициализации или добавление сервиса в группу, имеющую доступ к каталогу. Создание отдельных копий ключа или ослабление прав каталога /etc/letsencrypt недопустимо.
Резервное копирование каталога /etc/letsencrypt должно выполняться с сохранением прав, владельца и структуры симлинков. Потеря файла privkey.pem делает невозможным использование выпущенного сертификата и требует его перевыпуска.
Отличия размещения server.crt и server.key в Docker и контейнерах
В контейнерных средах server.crt и server.key не размещаются внутри образа на этапе сборки. Хранение ключа в Dockerfile или слое образа приводит к его утечке через registry и делает невозможной ротацию без пересборки контейнера. Корректный подход – передача файлов в контейнер во время запуска.
На практике используются volume-монтирования. Сертификат и ключ располагаются на хост-системе, например в /etc/ssl/ или /etc/letsencrypt/live/домен/, и подключаются в контейнер по заданному пути, который ожидает веб-сервер. Для Nginx это часто /etc/nginx/ssl/, для Apache – /etc/apache2/ssl/, но путь определяется конфигурацией, а не стандартом Docker.
Файл server.key должен монтироваться в контейнер в режиме read-only. Это исключает его изменение изнутри контейнера и снижает риск компрометации при уязвимостях приложения. Для server.crt также допустим режим только для чтения, так как он не требует записи.
При использовании Docker Compose или Kubernetes сертификаты часто передаются через secrets. В этом случае ключ и сертификат доступны в виде файлов в специально выделенном каталоге, с правами, ограниченными на уровне оркестратора. Такой механизм предпочтительнее обычных volume для приватных ключей.
Обновление сертификатов, например от Let’s Encrypt, выполняется на стороне хоста или отдельного сервиса. Контейнеру не требуется перезапуск, если веб-сервер поддерживает перечитывание файлов, либо выполняется мягкий reload. Это возможно только при внешнем размещении server.crt и server.key, а не при их встраивании в образ.
Вопрос-ответ:
Можно ли хранить server.crt и server.key в одном каталоге?
Технически веб-серверу достаточно корректных путей и прав доступа, однако совместное хранение не рекомендуется. Сертификат допускает чтение многими процессами, а приватный ключ должен быть изолирован. Разделение каталогов упрощает контроль доступа, аудит и снижает риск случайного раскрытия ключа при ошибках в правах.
Почему server.key нельзя класть рядом с конфигурацией сайта?
Каталоги с конфигурацией виртуальных хостов часто доступны для чтения системным пользователям или инструментам автоматизации. Если ключ лежит в том же месте, он может быть прочитан или скопирован при резервном копировании. Для ключа предназначены каталоги с ограниченным доступом, такие как /etc/ssl/private или /etc/pki/tls/private.
Что произойдёт, если у server.key будут слишком широкие права?
При правах вроде 644 или 666 любой пользователь системы сможет прочитать закрытый ключ. Это позволяет расшифровывать трафик и подменять сервер при атаках. Некоторые веб-серверы в таком случае отказываются запускаться, но полагаться на это нельзя — контроль прав должен выполняться администратором.
Нужно ли копировать файлы из /etc/letsencrypt/live в другое место?
Нет. Каталог live содержит симлинки на актуальные версии сертификата и ключа. Копирование приводит к тому, что после продления веб-сервер продолжает использовать старые файлы. Правильный вариант — указывать путь напрямую на privkey.pem и fullchain.pem внутри live.
Где должны лежать server.crt и server.key при запуске сервера в Docker?
Файлы размещаются на хосте и подключаются в контейнер через volume или secrets. Хранение ключа внутри образа недопустимо, так как он попадает в слои и registry. Контейнер должен получать доступ к файлам только на чтение и только по тем путям, которые указаны в конфигурации веб-сервера.
Можно ли перенести server.crt и server.key в нестандартный каталог?
Да, веб-серверу без разницы, где физически лежат файлы, если в конфигурации указан корректный абсолютный путь. Проблемы начинаются при сопровождении: нестандартные каталоги часто не учитываются в резервном копировании, для них забывают настраивать SELinux или AppArmor, а новые администраторы тратят время на поиск файлов. Поэтому перенос допустим, но требует документирования и ручного контроля прав и контекста безопасности.
Почему веб-сервер может не читать server.key, хотя права выставлены правильно?
Чаще всего причина связана не с UNIX-правами, а с политиками безопасности системы. В системах с SELinux файл может иметь неподходящий контекст, из-за чего доступ блокируется. В контейнерах аналогичная ситуация возникает при монтировании volume без нужных флагов или при запуске процесса под другим пользователем. Логи сервера в таких случаях содержат ошибку открытия файла без указания конкретной причины.
Загрузка...
