Получаем сертификаты Let’s Encrypt при помощи Certbot – Записки IT специалиста

Получаем сертификаты Let's Encrypt при помощи Certbot - Записки IT специалиста Сертификаты
Содержание
  1. Почему лучше рассчитывать на sni?
  2. Основные преимущества
  3. Что такое let’s encrypt – let’s encrypt
  4. Cert-manager
  5. Nginx
  6. №1. самоподписанный сертификат
  7. №3. wildcard le с валидацией через dns
  8. №4. использование специальных аннотаций ingress
  9. Obtaining and renewing let’s encrypt ssl certificate
  10. Webroot
  11. Yet another инструкция по получению ssl-сертификата let’s encrypt
  12. Выдача let’s encrypt
  13. Генерация ключа по алгоритму диффи-хеллмана
  14. Если нужно добавить поддомен или домен в сертификат
  15. Зачем нужен ssl-сертификат let’s encrypt
  16. Использование let’s encrypt для внутренних серверов
  17. Использование плагина webroot
  18. Какие ip-адреса использует let’s encrypt для проверки моего web-сервера?
  19. Каков срок действия сертификатов let’s encrypt? какое время они будут считаться действительными?
  20. Какую техническую поддержку вы предлагаете?
  21. Настраиваем конфигурацию nginx для ssl
  22. Недостатки let’s encrypt
  23. О недостатках let’s encrypt
  24. Подготовим nginx к получению сертификатов
  25. Получение wildcard сертификата
  26. Получение сертификата без использования веб-сервера
  27. Получение сертификата с использованием nginx
  28. Преимущества let’s encrypt
  29. Пример обновления сертификатов веб-сервера из хранилища сертификатов
  30. Пример перезапуска nginx при обновлении сертификатов
  31. Продление ssl сертификата
  32. Создаем сниппет конфигурации с устойчивыми настройками шифрования
  33. Создание и поверка собственных сертификатов
  34. Устанавливаем ssl сертификат let’s encrypt (инструкция)
  35. Шаг 2: создание сертификата
  36. Шаг 3. настраиваем tls/ssl на веб-сервере
  37. Шаг 5. подключаем изменения в nginx
  38. Шаг 6. настраиваем автоматическое обновление
  39. Шаг 0. подготовка
  40. Вместо заключения
  41. Заключение

Почему лучше рассчитывать на sni?

  1. Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.

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

Например, так можно посмотреть домены в сертификате Тематических Медиа:

Основные преимущества

бесплатно:
любой владелец сайта (в частности, доменного имени) может получить и установить доверенный TLS-сертификат Let’s Encrypt (TLS — наследник SSL);
автоматизация:
все функции установки, конфигурации и обновления проводятся в автоматическом режиме;
безопасность:
все методы шифрования Let’s Encrypt отвечают текущим стандартам;
прозрачность:
публичная доступность информации о выпуске и отзыве каждого сертификата для любого желающего;
свободно:
будет использован принцип open standard для протоколов взаимодействия с CA (certificate authority).

Что такое let’s encrypt – let’s encrypt

Let’s Encrypt – бесплатный, автоматизированный и открытый Центр Сертификации, созданный на благо всего общества организацией Internet Security Research Group (ISRG).

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

О наших успехах за последний год вы можете узнать, скачав наш годовой отчёт.

Ключевые принципы Let’s Encrypt:

  • Бесплатность: Любой владелец домена может использовать Let’s Encrypt для получения SSL/TLS сертификатов, не тратя ни копейки.
  • Автоматизированность: Программное обеспечение Let’s Encrypt, запущенное на web-сервере, само позаботится о выпуске, настройке и обновлении сертификатов.
  • Безопасность: Let’s Encrypt будет платформой для передовых технологии в области TLS безопасности, как для Центра Сертификации, так и для web-серверов.
  • Прозрачность: Все выданные или отозванные сертификаты будут сохранены, в том числе и для любых проверок безопасности.
  • Открытость: Протокол выпуска и обновления сертификатов будет опубликован как открытый стандарт, готовый ко внедрению.
  • Взаимодействие: Как и сами протоколы по обмену данными, лежащие в его основе, Let’s Encrypt – это результат объединённых усилий сообщества, без диктата какой-либо одной организации.

Более подробно о Центре Сертификации Let’s Encrypt вы можете узнать на странице как работает Let’s Encrypt.

Cert-manager

— специальный проект для Kubernetes, представляющий собой набор CustomResourceDefinitions (отсюда

на минимально поддерживаемую версию K8s — v1.12) для конфигурации CA (удостоверяющих центров) и непосредственного заказа сертификатов. Установка CRD в кластер тривиальна и

к применению одного YAML-файла:

Nginx

Nginx – второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:

location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
   return 404;
}

Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:

№1. самоподписанный сертификат

Ресурс Issuer будет выглядеть так:

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}


А чтобы выпустить сертификат, необходимо описать ресурс

Certificate

, где указывается, как произвести выпуск (см. раздел

issuerRef

ниже) и где размещен приватный ключ (поле

secretName

). После этого в Ingress потребуется сослаться на этот ключ (см. раздел

tlsspec

№3. wildcard le с валидацией через dns


Усложним задачу, выписав сертификат сразу на все поддомены сайта и воспользовавшись на этот раз DNS-проверкой (через CloudFlare).

Для начала получим в панели управления CloudFlare токен для работы через API:

  1. Profile → API Tokens → Create Token.
  2. Выставляем права доступа следующим образом:
  3. Копируем полученный после сохранения токен (например: y_JNkgQwkroIsflbbYqYmBooyspN6BskXZpsiH4M).

Создадим Secret, в котором будет храниться этот токен, и сошлемся на него в Issuer:

№4. использование специальных аннотаций ingress

Помимо прямого пути по созданию сертификатов в cert-manager есть возможность воспользоваться компонентом под названием

и явно не создавать ресурсы

Certificate

. Идея заключается в том, что с помощью специальных аннотаций Ingress’а сертификат будет автоматически заказан с помощью указанного в них

Issuer

. В результате получается примерно следующий ресурс Ingress’а:

Obtaining and renewing let’s encrypt ssl certificate

Не так давно в промышленную эксплуатацию был запущен центр сертификации Let’s Encrypt.

От всех прочих провайдеров SSL сертификатов его отличает две главные особенности.

Во-первых, Let’s Encrypt позволяет получить (и в ряде случаев даже установить) полученный сертификат в вашу систему в автоматическом режиме, а, во-вторых, сделать это совершенно бесплатно.

Сочетание этих двух факторов даёт возможность легко получить, быстро установить и забыть об обновлении полученного (одного или нескольких) SSL сертификатов в будущем.

Итак, небольшой how-to который был подготовлен на базе настройки этого самого блога.

Webroot

Данная опция подходит тем, кого не устраивает standalone. При указании ключа –webroot необходимо также будет указать и директорию, где располагаются файлы, которые обрабатывает веб-сервер.

$ ./letsencrypt-auto certonly --webroot -webroot-path /var/www/mydomain/

При работе с данной опцией необходимо настроить веб-сервер на чтение файлов соответствующим образом.

Yet another инструкция по получению ssl-сертификата let’s encrypt

Тема получения сертификата Let’s Encrypt уже подымалась на хабре (см.

тут

), да и в сети можно найти много рецептов разного качества.

Читал я и ужасался: одни пишут, что то нужно nginx или apache остановить («на пару минуточек всего»), другие предлагают файлы подкладывать в папку веб-сервера (в соседней ssh-сессии), третьи — о том, как важно соблюсти правильный Content-type для файлов проверки домена…

Давайте попробуем обойтись без всего этого: чтобы не было мучительно больно ни на стадии установки, ни очередном продлении — даже если придётся обновлять сразу много доменов. Собственно, вот и вся цель моей небольшой заметки: это не пошаговый степ-бай-степ, не длинная теоретическая статья о том, как функционирует Let’s Encrypt — просто описывается правильный на мой взгляд подход, который будет правилен для конфигурации любой сложности.

Вся суть в двух словах: пусть Let’s Encrypt запустит веб-сервер на 9999 порту, а мы допишем конфиг nginx, чтобы он пробросил запрос на этот бекенд. Кому интересны детали — прошу под кат

Установка Let’s Encrypt в настоящее время рекомендуется из репозитория на гитхабе:

git clone https://github.com/letsencrypt/letsencrypt && cd letsencrypt

Для некоторых операционок уже есть готовые пакеты (более того — вместо команды letsencrypt-auto (которая по сути есть лишь обёртка для letsencrypt) можно использовать letsencrypt), но установка из репозитория меня, как программиста вполне устраивает.

Далее — нужно подготовить наш сервер.

В принципе, всё, что от нас требуется — это чтобы по адресу mysubdomain.mydomain.tld/.well-known/acme-challenge/6il4rb2ErDWuBnUsTw_qrJc_tXGNv43p2a4kQQc0CvE отдавался заранее определённый контент с нужными заголовками.

Переложим эту работу на сам Let’s Encrypt: пусть сам подымет на 127.0.0.1:9999 собственный веб-сервер, а мы — лишь допишем в конфиг nginx правило для проброса запросов на этот бекенд. Не нужно ни останавливать ничего, ни тем более создавать файлы вручную.

Итак. Создаём файл /etc/nginx/template/letsencrypt.conf следующего вида:

location ~ ^/(.well-known/acme-challenge/.*)$ {
    proxy_pass http://127.0.0.1:9999/$1;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

И подключим в конфиг-файлы нужных поддоменов:

     include template/letsencrypt.conf;

Собственно, это всё. Дальше можно запустить одну-единственную команду — собственно запустить Let’s encrypt:

letsencrypt-auto --agree-tos --renew-by-default --standalone --standalone-supported-challenges http-01 --http-01-port 9999 --server https://acme-v01.api.letsencrypt.org/directory certonly -d mydomain.tld -d www.mydomain.tld -d i1.mydomain.tld -d i2.mydomain.tld

Здесь я получаю сертификат сразу для четырёх поддоменов, указываю, что нужно запустить веб-сервер на порту 9999, согласиться с лицензионным соглашением. (В принципе, можно указать в командной строке е-мейл, чтобы вообще не пришлось в интерактивный режим входить и довносить эту информацию: читайте описание ключей в документации)

В принципе, больше описывать нечего. Как внести сертификат в конфиг-файл nginx достаточно хороших и правильных описаний.

Единственное — осталось добавить в cron команду автоматического продления:

letsencrypt-auto renew >> /dev/null 2>&1

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

Вот и всё. От себя добавлю, что очень не люблю быть в первых рядах новой технологии («пока не выйдет первый сервис-пак — нет смысла обновлять винду на новую»), но в принципе, вижу, что Let’s Encrypt уже можно потихоньку начинать использовать в продакшн.

PS В качестве основы для своей заметки я взял статью Дмитрия из его блога. Не знаю, есть ли он на хабре, в любом случае от меня — большое спасибо.

Выдача let’s encrypt

Запрос на Let’s Encrypt желательно выполнить на сервере с Zimbra, чтобы получить сертификат SSL, CA Intermediate и Private Key. Для этого необходимо остановить службу почтового сервера (порты 80 и 443):

1. Останавливаем службы.

zmproxyctl stop zmmailboxdctl stop

2. Загружаем пакет Let’s Encrypt и заходим в каталог letencrypt:

Примечание. В RedHat и CentOS 6 перед установкой вам нужно будет включить репозиторий EPEL.

Генерация ключа по алгоритму диффи-хеллмана

Для повышения безопасности вам необходимо сгенерировать ключ по алгоритму Диффи-Хеллмана. Для генерации ключа длиной 2048 бит используйте такую команду:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Процесс может занять несколько минут.

Если нужно добавить поддомен или домен в сертификат

Если вы вдруг забыли указать поддомен www, или вам нужно добавить другой домен или поддомен в сертификат (которых может быть до 100 в одном сертификате), то это легко сделать после получения сертификата. Просто запустите команду еще раз, добавив требуемое имя:

Зачем нужен ssl-сертификат let’s encrypt

SSL-сертификат — это цифровая подпись сайта, которая требуется для безопасного соединения. Посмотрите в строку браузера.

На нашем сайте подключен SSL-сертификат: строка — Сертификат (действительный). И есть значок «Безопасное подключение». Это значит, что данные, которые оставляют клиенты на нашем сайте, защищены специальным шифрованием и недоступны мошенникам и прочим злоумышленникам.


Сертификаты Let’s Encrypt — это обычные сертификаты, которые подтверждают домен. Они предназначены для любых серверов с доменным именем: веб-серверов, почтовых серверов, FTP-серверов и других.

Использование let’s encrypt для внутренних серверов

Let’s Encrypt — это центр сертификации, который предоставляет бесплатные сертификаты в полностью автоматизированном процессе. Эти сертификаты выдаются по протоколу ACME. За последние два года в Интернете широко использовалась технология Let’s Encrypt — более 50% веб-сертификатов SSL / TLS теперь выдает Let’s Encrypt.

В этом посте описывается, как выдавать сертификаты Let’s Encrypt для внутренних серверов.

Хотя и существует множество инструментов для автоматического обновления сертификатов для общедоступных веб-серверов (certbot, simp_le, я писал о том, как это сделать), трудно найти какую-либо полезную информацию о том, как выдавать сертификаты для внутренних серверов, не подключенных к Интернету, и / или устройства с Let’s Encrypt.

В Datto мы выдали сертификат на каждую из наших 90 000 устройств BCDR, использующих именно этот механизм.

Содержание

  1. Как это работает?
  2. Пример: внутренний сервер 10.1.1.4, он же. xi8qz.example.com
    2.1. Предварительные требования: назначение домена для каждой машины (шаги 1-3)
    2.2. Запрос сертификата (шаги 4-14)
  3. Рекомендации по развертыванию: ограничения скорости Let’s Encrypt.

Hello Hacker News, впервые на главной странице HN! Для меня это большая честь! Я ответил на все вопросы в разделе комментариев.

Если вы ищете реализацию этой идеи, вам может быть интересен localtls. Я сам не тестировал, но похоже, что он делает то же самое, что я здесь описываю.

  1. Как это работает?
    Чтобы выпустить сертификат с помощью Let’s Encrypt, вы должны доказать, что вы либо являетесь владельцем веб-сайта, для которого хотите выпустить сертификат, либо владеете доменом, на котором он работает. Обычно автоматизированные инструменты, такие как certbot, используют HTTP-запрос для подтверждения права собственности на сайт с использованием .well-known каталога. Хотя это прекрасно работает, если сайт подключен к Интернету (и Let’s Encrypt может проверять файлы HTTP-запросов с помощью простого HTTP-запроса), он не работает, если ваш сервер работает на 10.1.1.4 или на любом другом внутреннем адресе.

    DNS решает эту проблему, позволяя подтвердить право собственности на домен с помощью TXT-записи DNS _acme-challenge.example.com. Let’s Encrypt проверит, что запись соответствует ожидаемому, и выдаст ваш сертификат, если все сложится.

    Итак, действительно волшебными ингредиентами для выдачи сертификатов для внутренних компьютеров, не подключенных к Интернету, являются:

  2. Пример: внутренний сервер 10.1.1.4, он же. xi8qz.example.com

    На следующей диаграмме показано, как мы реализовали интеграцию Let’s Encrypt для наших устройств резервного копирования Datto. Каждое устройство (читайте: внутренний сервер) находится за NAT и имеет собственный локальный IP-адрес.

    Общий подход прост: устройство регулярно обращается к нашему серверу управления, чтобы обеспечить доступ к нему через его собственный поддомен. Если его локальный IP-адрес изменяется, он запускает обновление своего собственного поддомена. Кроме того, он регулярно проверяет, действителен ли сертификат, и запрашивает обновление, если он устарел.

Вот немного подробностей об этом процессе:

Получаем сертификаты Let's Encrypt при помощи Certbot - Записки IT специалиста

Участники этого процесса:

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

2.1. Предварительные требования: назначение домена для каждой машины (шаги 1-3)

Как упоминалось выше, нам нужно дать каждому устройству правильное доменное имя, чтобы иметь возможность подтвердить право собственности на Let’s Encrypt, поэтому нам нужно купить домен (здесь: example.com) и делегировать его NS-записи нашему серверу DDNS:

$ dig  short NS example.com
ddns1.mycompany.com.

Вдобавок к этому нам нужна возможность динамически добавлять и удалять записи из него (через какой-то API). Я ранее писал о том, как развернуть собственный DDNS-сервер, если вам интересно.

После того, как все это настроено, нам нужно убедиться, что запись A машины обновляется при изменении ее IP-адреса. Для нашей внутренней машины давайте назначим xi8qz.example.com в качестве домена. Если все работает правильно, вы сможете разрешить этот домен по его IP-адресу, используя обычный DNS-запрос:

$ dig  short xi8qz.example.com
10.1.1.4

2.2. Запрос сертификата (шаги 4-14)

Предполагая, что теперь вы полностью контролируете зону DNS для example.com и можете быстро редактировать ее динамически, у вас все готово для фактической выдачи сертификатов для вашего локального домена устройства через Let’s Encrypt.

В нашем примере устройства оно будет регулярно проверять, действителен ли существующий сертификат (шаг 4). Если сертификата нет или срок действия существующего скоро истечет, устройство сгенерирует пару ключей и запрос на подпись сертификата (CSR), используя назначенное ему имя хоста (здесь: xi8qz.example.com) в качестве CN, и оно отправит этот CSR на управляющий сервер (шаг 5).

После авторизации запроса (важный шаг, не показанный на схеме!), Управляющий сервер запрашивает DNS-запрос для данного домена из ACME API через вызов Pre-Authorization / new-authz API (шаг 6). ACME API отвечает запросом DNS (шаг 7). Если все идет хорошо, это выглядит примерно так:

{
  "identifier": {
    "type": "dns",
    "value": "xi8qz.example.com"
  },
  "status": "pending",
  "expires": "2021-04-15T21:26:29Z",
  "challenges": [
    {
      "type": "dns-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/VtjihR4X8nLAj4MDwI...",
      "token": "aLptEKAeUOajkiGrx-kkbjUX4b1MC..."
    },
    // ...
  ],
  // ...
}

Используя этот ответ, управляющий сервер должен установить запись DNS TXT на _acme-challenge.xi8qz.example.com (шаг 8) и уведомить ACME API о том, что ответ на запрос был размещен (шаг 9).

После того, как ответ на запрос был проверен с помощью Let’s Encrypt (шаг 10-11), сертификат можно, наконец, запросить с помощью CSR (шаг 12-13).

После того, как Let’s Encrypt ответит сертификатом, вы увидите на проводе что-то вроде этого:

-----BEGIN CERTIFICATE-----
MIIGEjCCBPqgAwIBAgISAyk2izMz7OXSqHeZhg rUR5uMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
...

Если декодировать с помощью openssl, мы увидим, что это настоящая сделка:

$ openssl x509 -in www.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:29:36:8b:33:33:ec:e5:d2:a8:77:99:86:0f:ab:51:1e:6e
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Validity
            Not Before: Jul 18 23:37:35 2021 GMT
            Not After : Oct 16 23:37:35 2021 GMT
        Subject: CN=xi8qz.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:be:69:df:28:04:9c:2b:e9:94:72:c3:de:a6:fd:
                    a4:38:93:be:43:a7:81:8b:dc:9a:be:19:0d:c0:d1:
...

Этот сертификат затем возвращается в машину (шаг 14). После перезапуска веб-сервера устройства / сервера к его веб-интерфейсу можно будет получить доступ через HTTPS в браузере или из командной строки:

$ curl -v https://xi8qz.example.com/login
*   Trying 10.1.1.4...
* TCP_NODELAY set
* Connected to xi8qz.example.com (10.1.1.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=xi8qz.example.com
*  start date: Jul 18 23:37:35 2021 GMT
*  expire date: Oct 16 23:37:35 2021 GMT
*  subjectAltName: host "xi8qz.example.com" matched cert's "xi8qz.example.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET /login HTTP/1.1
> Host: xi8qz.example.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sun, 05 Aug 2021 17:38:49 GMT
< Server: Apache/2.4.18 (Ubuntu)
...

  1. Рекомендации по развертыванию: ограничения скорости Let’s Encrypt.

    Важно отметить, что если вы планируете реализовать этот механизм для большого количества серверов, вы используете staging среды Let’s Encrypt для тестирования и, что более важно, учитываете лимиты выдачи сертификатов.

    По умолчанию Let’s Encrypt позволяет выдавать только 20 сертификатов (в 2021 году) в неделю для одного и того же домена или одной и той же учетной записи. Чтобы увеличить это число, вы должны либо запросить более высокий лимит выдачи, либо добавить свой домен в список общедоступных суффиксов (обратите внимание: добавление вашего домена здесь имеет другие последствия!).

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

  2. Резюме

    Как видите, это не так уж и сложно.

    Сначала мы присвоили каждому устройству (так называемому внутреннему серверу) публичное доменное имя, используя наш собственный динамический DNS-сервер и выделенную зону DNS. Используя домен, назначенный серверу (здесь: xi8qz.example.com), мы затем использовали предложение бесплатного сертификата Let’s Encrypt и их запрос DNS, чтобы выпустить сертификат для этого сервера.

Сделав это для всех внутренних серверов, мы можем обеспечить безопасную связь в нашей внутренней ИТ-инфраструктуре без необходимости развертывания настраиваемого сертификата CA или необходимости платить за сертификаты.

Интересные Github проекты по этой теме:

https://github.com/RealTimeLogic/SharkTrust

https://github.com/joohoi/acme-dns

https://github.com/skoerfgen/CertLE

https://github.com/Corollarium/localtls

Немного рекламы: На платформе https://rotoro.cloud/ вы можете найти курсы с практическими занятиями:

Использование плагина webroot

Алгоритм работы Webroot включает в себя создание специального файла в директории /.well-known. Она размещается в корневом каталоге веб-сервера (document root) и может быть открыта сервисом Let’s Encrypt для проверки. В зависимости от ваших настроек, вам может понадобиться явно разрешить доступ к папке /.well-known.

Если вы ещё не установили Nginx, сделайте это, следуя руководству по установке Nginx на Ubuntu 16.04.

Чтобы убедиться в том, что папка доступна сервису Let’s Encrypt, внесем небольшие изменения в конфигурацию Nginx. По умолчанию файл конфигурации находится в папке /etc/nginx/sites-available/default. Мы будем использовать редактор Nano для внесения изменений:

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

Внутри блока server добавьте такой блок location:

# Добавить в SSL-блок server

location ~ /.well-known {
    allow all;
}

Вам также стоит посмотреть, где расположен корневой каталог веб-сервера (document root), так как этот путь необходим при работе с Webroot. Если вы используете стандартный файл конфигурации, она будет расположена в /var/www/html.

Сохраните и закройте файл.

Проверьте вашу конфигурацию на синтаксические ошибки:

sudo nginx -t

Если ошибок нет, перезапустите Nginx, используя эту команду:

sudo systemctl restart nginx

Какие ip-адреса использует let’s encrypt для проверки моего web-сервера?

Мы не публикуем такой список IP-адресов, потому что эти IP-адреса могут измениться в любое время.
В перспективе, мы будем выполнять проверку web-сервера с нескольких IP-адресов одновременно.
Обратите внимание на этот пост
для получения подробной информации.

Каков срок действия сертификатов let’s encrypt? какое время они будут считаться действительными?

Наши сертификаты действительны в течение 90 дней с момента выпуска. Почему именно 90 дней? Узнайте в статье из нашего блога.

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

Какую техническую поддержку вы предлагаете?

Let’s Encrypt – небольшая компания, мы полагаемся на автоматизацию для снижения издержек. Поэтому мы не можем предложить непосредственную техническую помощь каждому из наших пользователей. Но у нас есть другие способы помочь вам:

  1. Полноценная документация
  2. Активный и полезный форум сообщества. Члены нашего сообщества ведут активную работу по поиску ответов на вопросы, и, скорее всего, на ваш вопрос уже найден ответ.

Вот видео, которое нам нравится – о значимости большого сообщества.

Настраиваем конфигурацию nginx для ssl

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

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

Перед тем, как двигаться дальше, давайте сделаем резервную копию нашего текущего файла с блоками server:

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

Теперь откройте файл с блоками server для внесения изменений:

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

Внутри ваш блок server, вероятно, начинается так:

server {
 listen 80 default_server;
 listen [::]:80 default_server;

# Конфигурация SSL

# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;

. . .

Недостатки let’s encrypt

  1. Ограниченный срок действия, который составляет всего 90 дней. Хоть обновление лицензии и проходит автоматически, клиентам рекомендуется все равно следить за своевременным обновлением сертификата, чтобы избежать ошибок и проблем со стороны центра сертификации.
  2. Данные сертификаты совместимы с большинством браузеров, однако некоторые из них все-таки могут не поддерживать Let’s Encrypt.
  3. Так как Let’s Encrypt является в первую очередь некоммерческой организацией, они не дают никаких гарантий и компенсаций за ошибки.
  4. Let’s Encrypt не выпускает сертификаты OV (Organization Validation, подтверждение организации) и EV (Extended Validation, сертификаты высокой надежности).

О недостатках let’s encrypt

В конце этой статьи хотим отметить, что несмотря на все преимущества данного типа сертификата, существуют недостатки, которые нужно учитывать при выборе SSL:

  1. Бесплатный сертификат Let’s Encrypt кратковременный и рассчитан на срок не более 90 дней, в отличии от платного, который можно выпустить сроком до 3 лет. Вы можете , конечно, перевыпускать сертификат каждые 3 месяца, но обязательно следите за сроками. Перевыпуск сертификата можно осуществить тремя способами: вручную, за счет настройки планировщика задач cron или автоматически.

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

    Планировщик задач cron – это способ настройки автоматического обновления. Способ хорош для тех, кто владеет навыками администрирования Linux и умеет работать с кронами. Нужно еще учитывать, что в работе крона не исключены ошибки, которые могут помешать перевыпуску сертификата. Вывод: следить за обновлением все равно придется.

    Автоматическое обновление. Этот способ подразумевает, что вы принимаете автоматические настройки, предусмотренные Центром сертификации. И тут нужно понимать, что вы таким образом, даете свое согласие на то, что ЦС может вносить изменения по своему усмотрению в ПО и настройки вашего сервера.

  2. Не все домены можно защитить бесплатным Let’s Encrypt. Данный сертификат рассчитан только на защиту одного домена без проверки компании, так называемые DV SSL (Domain Validation).

    Так, при помощи Let’s Encrypt нельзя создать следующие типы сертификатов:

    – WildCard сертификат для защиты поддоменов определённого домена;
    – Сертификаты OV SSL(organization validation), предполагающие проверку не только домена, но и компании;
    – Сертификаты EV SSL (extended validation). Сертификат с максимальной степенью защиты и зелёной адресной строкой браузера;
    – Multi-Domain сертификат типа UCC;

  3. Важный момент — нет никаких финансовых гарантий использования Let’sEncrypt . Если вдруг произойдет взлом бесплатного сертификата, то денежную компенсацию никто вам не предоставит.

Подготовим nginx к получению сертификатов

В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location:

location /.well-known {
    root /var/www/html;
}

Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.

# cat /etc/nginx/acme 
location /.well-known {
    root /var/www/html;
}

Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:

include acme;

Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.

Перезагрузим nginx и проверим что наш тестовый файл виден:

Получение wildcard сертификата

Подтверждение сертификатов Wildcard-доменов происходит через DNS. Для проверки наличия записей будет использоваться утилита

. Поставьте пакет .

emerge -a net-dns/bind-tools

Выполните регистрацию Let’s Encrypt ACME аккаунта второй версии, указав почтовый адрес, на который в будущем будут приходить важныe сообщения:

Выполните команду для получения сертификата для доменов

example.orgwww.example.org
. В ходе выполнения программа запросит создать в DNS TXT-записи. Их нужно добавить вручную через DNS-хостинг.

Для проверки наличия TXT-записи используйте следующую команду:

Автоматическое обновление сертификатов, полученных вручную, не поддерживается, поэтому их необходимо обновлять отдельно.

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

Данная схема подходит, если на указанной машине нет веб-сервера.

Выполните следующую команду для получения сертификата для домена

example.org

Здесь и далее по тексту вместо

example.org
подставьте свой домен. Сертификат и закрытые ключи будут находиться в каталоге
/etc/letsencrypt/live/example.org/

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

Данная схема подходит, если на указанной машине уже работает сервер Nginx.

Создайте настройки для включения в конфигурации серверов:

mkdir /var/calculate/www/acme

Включите ACME в настройку необходимого сервера

example.org
и перезапустите Nginx:

Выполните следующую команду для получения сертификата для доменов

example.orgwww.example.org:

Преимущества let’s encrypt

  1. Бесплатность. Let’s Encrypt — некоммерческая организация, которая позволяет пользоваться услугами на безвозмездной основе. Поэтому их сертификаты пользуются популярностью у молодых сайтов, которые не обладают бюджетом на платные SSL-сертификаты.
  2. Простота получения. Большинство хостинг-провайдеров предлагают подключить Let’s Encrypt автоматически в пару кликов.
  3. Автоматическое продление. Также многие хостеры предлагают автоматическое продление Let’s Encrypt сертификата, что снимает нужду в постоянном контроле.
  4. Надежность и безопасность. Несмотря на бесплатность, уровень шифрования не уступает платным аналогам.

Пример обновления сертификатов веб-сервера из хранилища сертификатов

В данном примере скрипт

при обновлении сертификата для
example.org
будет вызывать скрипт, который обновит сертификаты на
webserver
, а также перезапустит на нём Nginx.

Установите права на выполнение скрипта:

chmod 700 /etc/letsencrypt/renewal-hooks/deploy/push-to-nginx

Пример перезапуска nginx при обновлении сертификатов

Этот пример подойдёт, если получение сертификата осуществляется через Nginx, находящийся на этой же машине.

Установите права на выполнение скрипта:

chmod 700 /etc/letsencrypt/renewal-hooks/deploy/restart-nginx

Продление ssl сертификата

Ранее я уже упоминал о том, что бесплатные SSL сертификаты “живут” только 90 дней, поэтому после их истечения необходимо будет запускать процедуру продления, благо это тоже бесплатно 🙂

Что же из себя представляет процесс продления?

Как утверждают в Let’s Encrypt, перед истечением, на почту, указанную при создании, приходит соответствующее письмо-уведомление о том, что пора бы продлить сертификат. Чтобы это сделать вручную достаточно запустить команду:

$ ./letsencrypt-auto

И следовать инструкциям на экране. Автоматическое же продление можно настроить используя конфигурационный файл и обычный crontab. Желательно настроить крон таким образом, чтобы продление происходило не чаще 1 раза в месяц.

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

Создаем сниппет конфигурации с устойчивыми настройками шифрования

Следующим шагом мы создадим другой сниппет, определяющий некоторые настройки SSL. Это позволит Nginx подключить устойчивый «набор шифров» SSL (англ. cipher suite) и некоторые дополнительные функции, которые помогут обеспечить безопасность нашего сервера.

Прим. перев. Cipher Suite — это совокупность алгоритмов, используемых в конкретной TLS/SSL-сессии:

  • алгоритм выработки сессионных ключей шифрования;
  • алгоритм, используемый для аутентификации сервера;
  • непосредственно сам симметричный алгоритм шифрования трафика;
  • и алгоритм контроля целостности (MAC, message authentication code).

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

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

Для настройки безопасной связки Nginx-SSL мы будем использовать рекомендации сайта Cipherli.st. Он создан для предоставления быстрого доступа к готовым настройкам шифрования популярного программного обеспечения. Дополнительная информация доступна в руководстве по настройке SSL для Nginx.

Примечание. Предлагаемые стандартные настройки на сайте Cipherli.st обеспечивают устойчивую безопасность, но иногда это приводит к ухудшению совместимости. Если вам необходимо поддерживать более старые версии клиентов, используйте альтернативный список настроек, доступный при нажатии на значок «Yes, give me a ciphersuite that works with legacy/old software.» Составить такой список можно и вручную.

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

Сперва добавим DNS-резолвер. Используем для нашего руководства тот, что предлагает Google. Затем установим в качестве параметра ssl_dhparam указатель на файл ключа Диффи-Хеллмана, который мы сгенерировали ранее.

Создание и поверка собственных сертификатов

Любой может выпустить собственный сертификат без обращения к УЦ. Единственное различие будет в том, что выпущенные вами сертификаты не будут приниматься кем-либо ещё. Для локальной разработки этого достаточно.

Простейший способ сгенерировать закрытый ключ и самоподписанный сертификат для localhost – выполнить следующую команду из пакета openssl:

openssl req -x509 -out localhost.crt -keyout localhost.key 
  -newkey rsa:2048 -nodes -sha256 
  -subj '/CN=localhost' -extensions EXT -config <( 
   printf "[dn]nCN=localhostn[req]ndistinguished_name = dnn[EXT]nsubjectAltName=DNS:localhostnkeyUsage=digitalSignaturenextendedKeyUsage=serverAuth")

Вы можете сконфигурировать локальный web-сервер, используя файлы localhost.crt и localhost.key, добавив localhost.crt в список доверенных корневых сертификатов.

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

Также, вы можете использовать доменное имя с точками внутри (например, www.localhost), добавив в файл /etc/hosts как алиас адреса 127.0.0.1. Этот подход чуть изменит способ обработки браузерами хранилища для cookie.

Устанавливаем ssl сертификат let’s encrypt (инструкция)

Рассмотрим использование сертификата применительно к серверам , используемым на нашем хостинге.

Подавляющее большинство наших серверов используют версию Plesk 12.5 где данный модуль уже включён в дистрибутив Plesk 12.5 и установка его проста и удобна. Достаточно зайти в панель плеск в раздел «Сайты и домены », кликнуть на модуль Let’s Encrypt,

выбрать нужные опции и после нажатия кнопки «Установить», установка произойдёт менее чем за минуту.

Так как данный сертификат рассчитан на срок не более 90 дней, то в панели плеск создана соответствующая задача cron в разделе Инструменты и настройки – Планировщик задач

Стоит заметить, что существуют некоторые ограничения на генерацию сертификата:

  • дублирующие сертификаты — не более 5 в неделю;
  • количество попыток генерации сертификата не более 5 раз в час.

Шаг 2: создание сертификата

Откройте командную строку (cmd) от имени администратора и поочерёдно введите следующие команды:

  1. Выполните C:wacswacs.exe.
  2. Далее выберите:
  3. Укажите ваше доменное имя и два раза нажмите Enter для подтверждения.
  4. Затем последовательно выберите:
  5. Укажите папку для сохранения сертификатов C:wacscrt.
  6. После этого выберите:
  7. Укажите адрес электронной почты для уведомлений об ошибках.
  8. На дополнительные вопросы отвечайте следующим образом:

Шаг 3. настраиваем tls/ssl на веб-сервере

Теперь, когда у вас есть SSL-сертификат, необходимо настроить веб-сервер Nginx так, чтобы он начал его использовать.

Внесем некоторые изменения в нашу конфигурацию:

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

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

Шаг 5. подключаем изменения в nginx

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

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

sudo nginx -t

В случае успеха ваш результат должен выглядеть следующим образом:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo systemctl restart nginx

Шаг 6. настраиваем автоматическое обновление

Сертификаты от Let’s Encrypt действуют только в течение 90 дней. Это побуждает пользователей к автоматизации процесса обновления. Нам понадобится создать регулярно запускающуюся команду для проверки и автоматического обновления сертификатов, срок которых истекает.

Для запуска проверки ежедневных обновлений мы будем использовать Cron — стандартный системный сервис для запуска повторяющихся задач. Задачи Cron указываются в файле под названием crontab:

sudo crontab -e

Вставьте следующую строчку в конец файла, затем сохраните и закройте его:

Шаг 0. подготовка

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

У вас должен быть установлен сервер на Ubuntu 16.04, и создан пользователь (не root), для которого настроены sudo привилегии. Узнать, как это сделать, вы можете, следуя руководству по первичной настройке сервера на Ubuntu 16.04.

Вы должны быть владельцем доменного имени, для которого планируется использовать сертификат, или иметь доступ к его настройке. Если у вас нет зарегистрированного доменного имени, вы можете сделать это, используя один из регистраторов (например, Namecheap или GoDaddy).

Вместо заключения

Путём несложных манипуляций с CRD мы научились выписывать автопродляемые, самоподписанные и бесплатные SSL-сертификаты от проекта Let’s Encrypt для доменов сайтов, запущенных в рамках Ingress’ов в Kubernetes-кластерах.

В статье приведены примеры решения наиболее частых в нашей практике задач. Однако функции cert-manager не ограничиваются описанными выше возможностями. На сайте утилиты можно найти примеры работы с другими сервисами — например, связка с Vault или же использование внешних выпускающих центров (issuers).

Заключение

Подводя итоги, можно сказать, что Центр Сертификации Let’s Encrypt достаточно успешный проект, популярность которого растет с каждым годом среди пользователей сети.

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

Тем не менее, мы рекомендуем крупным компаниям, интернет-магазинам, банкам и другим e-commerce проектам устанавливать коммерческие SSL – сертификаты от известных Центров сертификации, таких как, например, GlobalSign, Comodo.Так вы заручитесь доверием пользователей и покажете, что вы серьезная компания, которая заботится о безопасности данных клиентов.

Про сертификаты:  В отели Владимира и Суздаля поселят только с прививками или отрицательными ПЦР-тестами - Общество - ТАСС
Оцените статью
Мой сертификат
Добавить комментарий