Вопрос: Лучшее место для SSL-сертификата и частных ключей на Ubuntu


На Ubuntu, похоже, лучшее место для закрытого ключа, используемого для подписания сертификата (для использования nginx), находится в /etc/ssl/private/

Эта ответ добавляет, что сертификат должен /etc/ssl/certs/ но это похоже на небезопасное место. Делать .crt файлы должны храниться в безопасности или считаться общедоступными?


50
2018-04-13 15:56


Источник


Вы можете .crt если хотите, на рекламном щите Times Square. - ceejayoz


Ответы:


Файл .crt отправляется на все, что подключается; это публично. (chown root:root а также chmod 644)

Добавить к локальному ключу; убедитесь, что вы его правильно закрепляете, а также располагаете там. (chown root:ssl-cert а также chmod 640)


42
2018-04-13 16:06



Интересно, почему этот каталог по умолчанию не является g + s. - Collin Anderson
Это не обязательно; каталог равен 0750, поэтому нет возможности, чтобы пользователи, не входящие в группу, переходили в каталог для чтения файлов. - womble♦
Для большинства приложений, которые я использую, я вижу поведение, описанное в связанном ответе: они используют пользователя root для загрузки сертификата. Но разрешения здесь хорошо объяснены. - SimonSimCity
Похоже, ssl-cert - это недопустимое имя группы на ubuntu. Может быть, это должен быть chown root: root вместо этого - Atifm


Это действительно не имеет значения, где вы ставите их, пока вы должным образом защищаете свои закрытый ключ файл (ы). публичный сертификат является общедоступной; не требуется защита - привилегии сервера или иначе.

Чтобы расширить ответ, я не использую местоположение по умолчанию /etc/ssl,
 Мне легче держать все мои в отдельной области из-за резервных копий + по другим причинам.

Для Apache SSL я держу свой /etc/apache2/ssl/private или аналогичной «корневой области» в /etc/,

Пример настройки

Этот пост ориентирован на Ubuntu (Debian) + Apache, но должен работать на большинстве систем -
 Просто примените разрешения и местоположение / путь обновления в заданной конфигурации (apache / nginx / etc).
  Если файлы ключей SSL защищены правильно (каталог и файлы), все будет в порядке. Обратите внимание на заметки!

Создание каталогов:

sudo mkdir /etc/apache2/ssl
sudo mkdir /etc/apache2/ssl/private
sudo chmod 755 /etc/apache2/ssl
sudo chmod 710 /etc/apache2/ssl/private

Заметка:
chmod 710 опоры ssl-cert группы под Ubuntu.
 (См. Комментарии)
Установка разрешения на 700 на /etc/apache2/ssl/private также будет работать нормально. 

Установить владельца:

sudo chown -R root:root /etc/apache2/ssl/
sudo chown -R root:ssl-cert /etc/apache2/ssl/private/

Заметка:
Если у вас нет SSL-сертификат группе, просто используйте «root: root» в строке выше или пропустите вторую строку.

Разместить файлы SSL:

Положил общественности www ssl (ы) вместе с промежуточным сертификатом (сертификатами) в     /etc/apache2/ssl
  Положил частный ssl key (s) в /etc/apache2/ssl/private

Установить разрешения:

Открытый сертификат (ы)

sudo chmod 644 /etc/apache2/ssl/*.crt

Закрытый ключ (ы)

sudo chmod 640 /etc/apache2/ssl/private/*.key

Заметка:
Разрешение группы устанавливается на READ (640) из-за группы Ubuntu ssl-cert. «600» отлично.

Включить модуль Apache SSL

sudo a2enmod ssl

Отредактируйте любые файлы сайта Apache и включите

(см. последний абзац) *

sudo nano /etc/apache/sites-available/mysiteexample-ssl.conf
sudo a2ensite mysiteexample-ssl
#             ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)

Перезапустить службу Apache2

sudo service apache2 restart

или

sudo systemctl restart apache2.service

Готово. Проверьте свой новый сайт SSL.

* Снова это выходит за рамки вопроса, но вы можете скопировать файл конфигурации сайта Apache SSL по умолчанию (sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf) в качестве хорошей отправной точки / примера директив / каталогов по умолчанию, обычно используемых в простом (Ubuntu / Debian) файле Apache / SSL 'conf'. Обычно это указывает на самоподписанный сертификат SSL + key (snakeoil), пакеты CA, а также общие директивы используется для данного сайта SSL.

После копирования просто отредактируйте новый .conf-файл и добавьте / удалите / обновите его по мере необходимости с помощью новой информации / путей выше, затем выполните sudo a2ensite mysiteexample-ssl чтобы включить его.


29
2017-10-21 17:17



не знаете, почему вы предложили бы установить 710 для разрешений для / etc / apache2 / ssl / private. Установка бит выполнения для каталога (для группы) без установки бит чтения для каталога (для группы) не имеет для меня большого смысла. Вы хотели установить его как 750? - chriv
@chriv Я просто устанавливаю разрешения на основе того, как я вижу, что он настроен в области SSL по умолчанию Ubuntu. См. / Etc / ssl / certs & / etc / ssl / private & ssl-certs. Видеть stackoverflow.com/a/23408897/503621 - bshea


Все ответы здесь кажутся правильными, но я хочу упомянуть, что одна вещь, которую я нашел, является проблемой ... Если вам нужно объединить свой сертификат с промежуточными звеньями или корнями, чтобы создать цепочный файл, не поместите это в /etc/ssl/certs, потому что когда c_rehash , он может создавать символьные ссылки хэша на ваши сертификаты из-за корней или промежуточных элементов внутри них.

Затем позже по дороге, если срок действия ваших сертификатов истек, и вы удалите их, и не знаете, чтобы снова запустить c_rehash, у вас могут быть сломанные символические ссылки на хэш /etc/ssl/certs каталог и странные вещи начинают происходить, когда ваш локальный компьютер пытается подключиться к себе через SSL, и он не может найти корни для проверки. Например, с завитом я вдруг начал получать:

curl: (60) SSL certificate problem: unable to get issuer certificate

Вскоре после очистки некоторых старых .crt и конкатенированных файлов .pem у меня было /etc/ssl/certs,

Хранение, по крайней мере, ваших цепей в другом месте позволяет избежать этой проблемы. Я закончил /etc/ssl/local_certs держать мои сертификаты и цепи, чтобы они не были потеряны в беспорядке сертификатов CA, которые вы найдете в /etc/ssl/certs


8
2018-03-23 14:58





На самом деле небезопасное место, если разрешение для отдельных файлов / каталога установлено на что-то вроде chown root :0 private.key а также chmod 600 private.key так что только root может его прочитать. CSR и файлы сертификатов менее чувствительны, как вы говорите.

С этими разрешениями указанные вами пути и / usr / local / ssl должны быть точными.


2
2018-04-13 16:08



Часто приложения, обращающиеся к закрытым ключам, работают как пользователи без полномочий root. Я бы предложил сохранить доступ к группе ssl-cert. - Shane Madden♦
Понял, но веб-серверы, такие как Apache, порождают корневой «родительский» процесс, и если предположить, что nginx тоже уместен. - Jonathan Ross