Самоподписные сертификаты кровавого энтерпрайза против вашего лампового CI/CD / Хабр

1: создание ssl-сертификата

Для работы TLS/SSL использует комбинацию открытого сертификата и закрытого ключа. Закрытый ключ хранится на сервере и не разглашается. SSL-сертификат используется открыто и доступен всем пользователям, запрашивающим контент.

Чтобы создать самоподписанный сертификат и ключ, запустите команду:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Команда задаст ряд вопросов. Рассмотрим компоненты команды подробнее:

• openssl: базовый инструмент командной строки для создания и управления сертификатами, ключами и другими файлами OpenSSL.
• req: эта подкоманда указывает, что на данном этапе нужно использовать запрос на подпись сертификата X.509 (CSR). X.509 – это стандарт инфраструктуры открытого ключа, которого придерживаются SSL и TLS при управлении ключами и сертификатами. То есть, данная команда позволяет создать новый сертификат X.509.
• -x509: эта опция вносит поправку в предыдущую субкоманду, сообщая утилите о том, что вместо запроса на подписание сертификата необходимо создать самоподписанный сертификат.
• -nodes: пропускает опцию защиты сертификата парольной фразой. Нужно, чтобы при запуске сервер Nginx имел возможность читать файл без вмешательства пользователя. Установив пароль, придется вводить его после каждой перезагрузки.
• -days 365: эта опция устанавливает срок действия сертификата (как видите, в данном случае сертификат действителен в течение года).
• -newkey rsa:2048: эта опция позволяет одновременно создать новый сертификат и новый ключ. Поскольку ключ, необходимый для подписания сертификата, не был создан ранее, нужно создать его вместе с сертификатом. Данная опция создаст ключ RSA на 2048 бит.
• -keyout: эта опция сообщает OpenSSL, куда поместить сгенерированный файл ключа.
• -out: сообщает OpenSSL, куда поместить созданный сертификат.

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

Самой важной строкой является Common Name (введите полное доменное имя  сервера (FQDN) или свое имя). Как правило, в эту строку вносят доменное имя, с которым нужно связать сервер. В случае если доменного имени нет, внесите в эту строку IP-адрес сервера. В целом эти поля выглядят примерно так:

2: настройка nginx для поддержки ssl

Итак, на данном этапе ключ и сертификат созданы и хранятся в каталоге /etc/ssl. Теперь нужно отредактировать настройки Nginx:

1. Создать сниппет, указывающий место хранения файлов SSL-сертификата и ключа.
2. Добавить настройки SSL.
3. Настроить блоки server для обслуживания запросов SSL и поддержки новых настроек.

3: настройка брандмауэра

Если вы включили брандмауэр ufw (согласно руководству по начальной настройке), на данном этапе его нужно настроить для поддержки трафика SSL. К счастью, веб-сервер Nginx регистрирует при установке несколько своих профилей в ufw.

Чтобы просмотреть доступные профили, введите:

4: обновление настроек nginx

Итак, теперь настройки веб-сервера и брандмауэра откорректированы. Перезапустите Nginx, чтобы изменения вступили в силу.

Сначала нужно проверить синтаксис на наличие ошибок.

sudo nginx -t

Если ошибок не обнаружено, команда вернёт:

nginx: [warn] “ssl_stapling” ignored, issuer certificate not foundnginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful

Обратите внимание на предупреждение в начале. Как говорилось ранее, веб-сервер будет возвращать предупреждение в случае использования самоподписанного сертификата. Соединения всё рано шифруются правильно.

Если в синтаксисе обнаружены ошибки, исправьте их. Затем перезапустите веб-сервер:

sudo systemctl restart nginx

5: тестирование настроек

Теперь нужно убедиться, что трафик между сервером и клиентом шифруется. Откройте в браузере следующую ссылку:

6: постоянный редирект

Если все настройки сервера работают должным образом, настройте постоянный редирект вместо временного.

Откройте файл блока server:

sudo nano /etc/nginx/sites-available/default

Найдите в нём return 302 и замените значение строки на return 301.

New-selfsignedcertificate: командлет powershell для генерации самоподписанного сертификата

Для создания самоподписанного сертификата в PowerShell нужно использовать командлет New-SelfSignedCertificate, входящий в состав модуля PKI (Public Key Infrastructure).

Чтобы вывести список всех доступных командлетов в модуле PKI, выполните команду:

Get-Command -Module PKI

Самоподписанные сертификаты рекомендуется использовать в тестовых целях или для обеспечения сертификатами внутренних интранет служб (IIS, Exchange, Web Application Proxy, LDAPS, ADRMS, DirectAccess и т.п.), в тех случая когда по какой-то причине приобретение сертификата у внешнего провайдера или разворачивание инфраструктуры PKI/CA невозможны.

Для создания сертификата нужно указать значения –DnsName (DNS имя сервера, имя может быть произвольным и отличаться от имени localhost) и —CertStoreLocation (раздел локального хранилища сертификатов, в который будет помещен сгенерированный сертификат).

Использование самоподписанного ssl сертификата sha-256 в iis

Обратите внимание, что при создании самоподписанный сертификат для IIS через консоль Internet Information Manager (пункт меню Create Self-Signed Certificate), создается сертификат с исопльзованием алгоритма шифрования SHA-1.

Вы можете привязать самоподписанный сертификат SHA-256, созданный в PowerShell, к сайту IIS. Если вы с помощью PowerShell создали SSL сертификат и поместили его в хранилище сертификатов компьютера, он будет автоматически доступен для сайтов IIS.

Запустите консоль IIS Manager, выберите ваш сайт, затем в настройке Site Binding, выберите созданный вами сертификат и сохраните изменения.

Использовать образы со вшитыми сертификатами

Рано или поздно многие компании обнаруживают потребность контролировать свою инфраструктуру. Админам надоедает отвечать на одинаковые вопросы разработчиков («почему у меня не качает с гитхаба?, «что значит x509?»), безопасникам надоедает наблюдать за тем, как все докер-файлы начинаются со строчки FROM vasyapupkin/zvercd, а разработчикам надоедает решать головоломки с изменчивыми промежуточными сертификатами и прочими вещами вне их области экспертизы. Тогда ответственные за платформу идут и пишут много-много докер-файлов наподобие такого:

Как создать закрытый ключ openssl

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

Этот закрытый ключ необходим для подписи вашего SSL-сертификата.

Вы можете изменить my_key в приведенной ниже команде на свое собственное значение.

$ sudo openssl genrsa -out my_key.key

Вот что означают флаги команды:

• genrsa Создать закрытый ключ RSA
• -out Выходной файл

Если вы не указали другое местоположение, ваш закрытый ключ будет храниться в текущем рабочем каталоге.

Как создать запрос на подпись сертификата

Следующим шагом является создание запроса на подпись сертификата (CSR).

CSR – это то, что вы обычно отправляете в УЦ.

Но в этом случае вы собираетесь подписать его самостоятельно.

При создании CSR вас попросят предоставить некоторую информацию.

Некоторые поля можно оставить пустыми, нажав клавишу ETCD_CLIENT_CERT_AUTH

Теперь запустите команду, показанную ниже, чтобы начать создание CSR.

$ sudo openssl req -new -key my_key.key -out my_csr.csr

Вот что обозначает каждый флаг команды

• req Сделать запрос на подпись сертификата
• -new Новый запрос
• -key Путь, где хранится ваш файл закрытого ключа
• -out Выходной файл

Местонахождение ключа и сертификата

Создайте новый сниппет Nginx в каталоге /etc/nginx/snippets.

Рекомендуется указать в названии файла его назначение (к примеру, self-signed.conf):

sudo nano /etc/nginx/snippets/self-signed.conf

В этот файл нужно добавить директиву ssl_certificate, которая будет указывать путь к сертификату, и директиву ssl_certificate_key, которая задаёт путь к соответствующему закрытому ключу.

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

Монтирование с хостов

Если прописать в config.toml

[[runners]]
  executor = "kubernetes"
  (...)
  [runners.kubernetes]
    (...)
    [runners.kubernetes.volumes]
      [[runners.kubernetes.volumes.host_path]]
        host_path = "/usr/local/share/ca-certificates"
        mount_path = "/usr/local/share/ca-certificates"
        name = "certs-volume"
        read_only = true

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

[runners.docker]
  (...)
  volumes = ["/usr/local/share/ca-certificates:/usr/local/share/ca-certificates:ro"]

Минус подхода в том, что ответственность за актуальность сертификатов сдвигается на конфигурацию инфраструктуры, поэтому подход удобен, если вы этой инфраструктурой управляете. Если же вы, например, работаете в отдельной команде, которая в многопользовательском кластере Kubernetes сама подняла свой раннер, но не имеет админского доступа туда, вы не можете быть уверены в актуальности сертификатов на хосте, да и можете вовсе не иметь прав на монтирование hostPath.

 kubectl create secret generic -n runner-namespace certs --from-file=/usr/local/share/ca-certificates

а config.toml исправить следующим образом:

[[runners]]
  executor = "kubernetes"
  (...)
  [runners.kubernetes]
    (...)
    [runners.kubernetes.volumes]
      [[runners.kubernetes.volumes.secret]]
        name = "certs"
        mount_path = "/usr/local/share/ca-certificates"
        read_only = true

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

Один из плюсов такого подхода в том, что можно делать следующее:

build:
  stage: build
  image: docker:stable
  services:
    - name: docker:18.09.6-dind
      entrypoint:
        - /bin/sh
      command:
        - -c
        - update-ca-certificates && dockerd-entrypoint.sh

Ключевой шаг, естественно, update-ca-certificates.

Поскольку для сервисных контейнеров нельзя прописать последовательность команд аналогично script, а писать длинные скрипты для установки сертификатов под ключом command не очень удобно, меньшим из зол является подобное монтирование сертификатов и сравнительно короткая последовательность команд.

Настройка nginx для поддержки ssl

Примечание: В руководстве предполагается, что вы используете виртуальный хост (блок server) default, который хранится в каталоге /etc/nginx/sites-available. Если вы используете другой файл, пожалуйста, укажите его имя.

Для начала создайте резервную копию файла блока server.

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

Затем откройте файл блока server в текстовом редакторе:

sudo nano /etc/nginx/sites-available/default

Файл должен выглядеть примерно так:

server {listen 80 default_server;listen [::]:80 default_server;# SSL configuration# listen 443 ssl default_server;# listen [::]:443 ssl default_server;. . .

Настройка ssl

Теперь нужно создать другой сниппет, предназначенный для настроек SSL. Он позволит серверу Nginx использовать надёжный механизм шифрования и включит некоторые дополнительные функции безопасности.

Эти установленные параметры можно повторно использовать в будущих конфигурациях Nginx, потому этому файлу лучше дать какое-нибудь общее имя:

sudo nano /etc/nginx/snippets/ssl-params.conf

Для безопасной настройки SSL обратимся к рекомендациям Remy van Elst на сайте Cipherli.st. Этот сайт предназначен для распространения простых и надёжных параметров шифрования для популярного программного обеспечения. Больше параметров для Nginx можно найти здесь.

Примечание: Данный список настроек подходит для более новых клиентов. Чтобы получить настройки для других клиентов, перейдите по ссылке Yes, give me a ciphersuite that works with legacy / old software.

Скопируйте все предложенные параметры. Остаётся только добавить в них DNS распознаватель для восходящего канала запросов. В руководстве для этого используется Google.

Также нужно добавить параметр ssl_dhparam, чтобы настроить поддержку ключей Диффи-Хеллмана.

Отступление про сборку docker-образов

Если вы в пайплайнах собираете докер-образы, то, независимо от того, используется docker-in-docker, kaniko или другой сборщик в пайплайне, в контексте сборки сертификаты снова отсутствуют, если их не вшили в базовый образ. Предположим, что каким-либо образом в контейнер пайплайна сертификаты были доставлены (либо примонтированы с хоста, либо получены из другого источника командами в before_script). Тогда конфигурация пайплайнов должна будет выглядеть так:

build:
  stage: build
  # допустим, сборка докером
  image: docker:stable
  services:
    - name: docker:18.09.6-dind
      entrypoint:
        - /bin/sh
      command:
        - -c
        - update-ca-certificates && dockerd-entrypoint.sh
  # before_script:
  #   - script_to_get_certs.sh
  script:
    - mkdir -p certs
    - cp /usr/local/share/ca-certificates/* certs/
    - docker build (...) # или канико или что угодно ещё
    - (...)

а в докер-файлах придётся всегда указывать что-нибудь вроде

Пайплайны

Действия выше выполняются относительно редко, однако если используется Docker или Kubernetes экзекьютор, то каждый джоб будет выполняться в свежесозданном контейнере, в котором снова нет нужных сертификатов. Поэтому необходим способ динамически доставлять сертификаты в контейнеры. Есть несколько таких способов:

Подпишем сертификат самостоятельно

Когда вы запустите команду, показанную ниже, будет создан самоподписанынй сертификат, который будет действителен в течение 365 дней.

$ openssl x509 -req -days 365 -in my_csr.csr -signkey my_key.key -out my_cert.crt

Получать сертификаты из первоисточника

Если источник корневых сертификатов предоставляет удобный API для их получения, можно не утруждать себя хранением сертификатов на своих серверах с последующим монтированием в пайплайны. Допустим, корневой сертификат можно получить командой

Предпосылки

Машина Linux и пользователь с привилегиями sudo.

Проверим сертификат

Вы можете проверить детали сертификата в текстовом формате с помощью команды:

openssl x509 -text -noout -in my_cert.crt

Проверить и купить доменное имя, бесплатно ssl сертификаты для сайта и сервера

Создадим самоподписанный сертификат, используя существующий закрытый ключ и csr

В некоторых ситуациях, когда у вас есть закрытый ключ и csr, будет достаточно следующих шагов.

Создать самоподписанный сертфикат типа code signing для подписывания кода

В PoweShell 3.0 командлет New-SelfSifgnedCertificate позволял генерировать только SSL сертификаты, которые нельзя было использоваться для подписывания кода драйверов и приложений (в отличии сертификатов, генерируемых утилитой MakeCert).

В версии PowerShell 5 новая версия командлета New-SelfSifgnedCertificate теперь может использоваться для выпуска сертификатов типа Code Signing.

Для создания самоподписанного сертфиката для подписывания кода приложений, выполните команду:

$cert = New-SelfSignedCertificate -Subject “Cert for Code Signing” -Type CodeSigningCert -CertStoreLocation cert:LocalMachineMy

Теперь можно подписать ваш PowerShell скрипт эти сертификатом:

Set-AuthenticodeSignature -FilePath C:PStest_script.ps1 -Certificate $cert

Если при выполнении команды появится предупреждение UnknownError, значит этот сертификат недоверенный, т.к. находится в персональном хранилище сертификатов пользователя.

Нужно переместить его в корневые сертификаты (не забывайте периодически проверять хранилище сертификатов Windows на наличие недоверенных сертфикатов и обновлять списки корневых сертификатов):

Установка openssl

OpenSSL доступен по умолчанию во всех основных дистрибутивах Linux.

Выполните приведенную ниже команду, чтобы убедиться, что OpenSSL уже установлен на вашем компьютере с Linux.

$ openssl version

Если вы не видите вывода, показывающего подробную информацию о версии OpenSSL, выполните следующую команду, чтобы установить OpenSSL.

Заключение

Теперь сервер Nginx может шифровать передаваемые данные, что защитит взаимодействие сервера с клиентами и предотвратит перехват трафика злоумышленниками.

Конечно, при разработке сайта рекомендуется подписать SSL-сертификат в надежном центре сертификации, что позволит избежать появления отпугивающих предупреждений.

Tags: