Dehydrated letsencrypt: dehydrated-io/dehydrated: letsencrypt/acme client implemented as a shell-script – just add water

Пример простой автоматизации letsencrypt / Хабр

Удостоверяющий центр «Let’s Encrypt» (далее просто letsencrypt) вышел из беты пару месяцев назад, пообтерся в реальных условиях, избавился от детских болезней и оброс различными клиентами. И к этому моменту выдал 5 миллионов сертификатов. Самое время внедрять, т.е. получать сертификаты на свои домены и обновлять их в автоматическом режиме. Но как внедрить так, чтобы приблизиться к любимому админскому «поставил и забыл»? Чтобы было просто получать новые сертификаты, а старые при этом обновлялись автоматом? Ну и как добавить немного безопасности в этот процесс?

Ответ под катом.

TL;DR/Quick Start/шпаргалка

• Скачать и настроить скрипт

  sudo adduser --system --home /opt/letsencrypt le
  sudo -u le -s
  git clone https://github.com/lukas2511/letsencrypt.sh.git /opt/letsencrypt/
  mkdir /opt/letsencrypt/.acme-challenges
  echo CONTACT_EMAIL="your@email" > /opt/letsencrypt/config
  echo "ваш_домен" > /opt/letsencrypt/domains. txt
  

• добавить в конфиг виртуального хоста nginx строчку

  location /.well-known/acme-challenge/ { alias /opt/letsencrypt/.acme-challenges/; }
  

• запустить скрипт

  sudo -u le /opt/letsencrypt/letsencrypt.sh --cron
  

• добавить ещё три строчки в конфиг виртуального хоста

  listen 443 ssl;
  ssl_certificate /opt/letsencrypt/certs/ваш_домен/fullchain.pem;
  ssl_certificate_key /opt/letsencrypt/certs/ваш_домен/privkey.pem;
  

• добавить в крон пользователя le

  1 0 * * * /opt/letsencrypt/letsencrypt.sh --cron
  

Как я уже сказал, letsencrypt оброс различными клиентами, которые позволяют получить сертификат. Этих самых клиентов, кстати, уже десятки под разные системы и языки программирования. В статье будет рассказано про реализацию клиента на bash от lukas2511, letsencrypt.sh. Это один скрипт на bash, который лежит в своей папке и для работы ему нужен только openssl. Запускаться он будет под отдельным пользователем. Конечно, при желании, всегда можно ещё сильнее закрутить гайки в плане безопасности — запускать в chroot и т.д.

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

Предположим, что ОС — linux, веб сервер — nginx, рабочая папка скрипта — /opt/letsencrypt, а пользователь — le.

Создадим системного пользователя, из под которого будет работать скрипт. При создании системного пользователя в debian/ubuntu, ему выставляется оболочка /bin/false и назначается группа nogroup, что нам вполне подходит.

$ sudo adduser --system --home /opt/letsencrypt le

Теперь можно стать этим пользователем и все делать под ним (кроме настройки nginx).
Скачиваем скрипт и смотрим содержимое.

$ sudo -u le -s
$ git clone https://github.com/lukas2511/letsencrypt.sh.git /opt/letsencrypt/
$ ls -la /opt/letsencrypt/
total 84
drwxr-xr-x 4 le   le    4096 Jun 25 15:56 .
drwxr-xr-x 3 root root  4096 Jun 25 15:53 . .
-rw-r--r-- 1 le   le    1406 Jun 25 15:56 CHANGELOG
drwxr-xr-x 3 le   le    4096 Jun 25 15:56 docs
drwxr-xr-x 8 le   le    4096 Jun 25 15:56 .git
-rw-r--r-- 1 le   le     108 Jun 25 15:56 .gitignore
-rwxr-xr-x 1 le   le   37634 Jun 25 15:56 letsencrypt.sh
-rw-r--r-- 1 le   le    1080 Jun 25 15:56 LICENSE
-rw-r--r-- 1 le   le    3040 Jun 25 15:56 README.md
-rwxr-xr-x 1 le   le    8048 Jun 25 15:56 test.sh
-rw-r--r-- 1 le   le     107 Jun 25 15:56 .travis.yml

Для работы скрипту нужна папка, куда он будет складывать файлы для валидации доменов.
По умолчанию скрипт настроен использовать папку /opt/letsencrypt/.acme-challenges и будет падать с ошибкой, если такой папки нет.
Так же желательно создать конфиг с нужными параметрами. Параметры для работы скрипт пытается брать из файла /opt/letsencrypt/config. По умолчанию файла нет и скрипт использует значения по умолчанию, но есть хорошо документированный конфиг в папке с документацией, который можно взять за основу.
Создаем папку и копируем конфиг

$ mkdir /opt/letsencrypt/.acme-challenges
$ cp /opt/letsencrypt/docs/examples/config /opt/letsencrypt/config

Чтобы посмотреть, с какими значениями работает скрипт, его можно вызвать с ключем --env

$ /opt/letsencrypt/letsencrypt.sh --env
# letsencrypt.sh configuration
#
# !! WARNING !! No main config file found, using default config!
#
declare -- CA="https://acme-v01.api.letsencrypt.org/directory"
declare -- LICENSE="https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf"
declare -- CERTDIR="/opt/letsencrypt/certs"
declare -- CHALLENGETYPE="http-01"
declare -- DOMAINS_TXT="/opt/letsencrypt/domains.txt"
declare -- HOOK=""
declare -- HOOK_CHAIN="no"
declare -- RENEW_DAYS="30"
declare -- ACCOUNT_KEY="/opt/letsencrypt/accounts/aHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2RpcmVjdG9yeQo/account_key.pem"
declare -- ACCOUNT_KEY_JSON="/opt/letsencrypt/accounts/aHR0cHM6Ly9hY21lLXYwMS5hcGkubGV0c2VuY3J5cHQub3JnL2RpcmVjdG9yeQo/registration_info. json"
declare -- KEYSIZE="4096"
declare -- WELLKNOWN="/opt/letsencrypt/.acme-challenges"
declare -- PRIVATE_KEY_RENEW="yes"
declare -- OPENSSL_CNF="/usr/lib/ssl/openssl.cnf"
declare -- CONTACT_EMAIL=""
declare -- LOCKFILE="/opt/letsencrypt/lock"

Описание некоторых параметровCA — какой удостоверяющий центр использовать. Их, как минимум два — боевой (по умолчанию) и тестовый. Дело в том, что у боевого есть разные ограничения по частоте запросов и количеству доменов. В эти ограничения легко упереться при тестировании. Поэтому я рекомендую для тестовых запусков указать тестовый центр. Он работает так же, как боевой, просто генерирует невалидные сертификаты.
Вот тестовый CA:
CA="https://acme-staging.api.letsencrypt.org/directory"

CERTDIR — папка для сертификатов. Внутри неё отельные папки по имени хоста. А в этих папках уже сертификаты для каждого хоста. Нужно будет настроить nginx читать сертификаты из этих папок (см. ниже).

DOMAINS_TXT — список доменов. Одна строчка — один сертификат. В одной строчке может быть несколько доменов, тогда создается один сертификат для них. Скрипт берет первый домен, как название сертификата, а остальные домены указывает, как дополнительные. Например, для такого файла, скрипт создаст два сертификата: some.domain.com и test.com.
some.domain.com another.domain.net example.domain.org

test.com www.test.org ftp.test.net

HOOK — скрипт, который запускается при различных действиях (при валидации доменов, при генерации сертификатов и т.д.).

Скрипту передаются разные параметры: название операции, пути к новым сертификатам и т.д.

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

Например, сертификат нужно разложить на несколько серверов, или нужно проводить валидацию домена через dns, а не через файл.

Скрипт, который ничего не делает, но содержит массу комментариев, лежит по адресу /opt/letsencrypt/docs/examples/hook. sh

RENEW_DAYS — через сколько дней обновлять сертификат. Максимум 90, по умолчанию 30.

CONTACT_EMAIL — рабочий email администратора.

Я рекомендую указать в конфиге свой email в CONTACT_EMAIL и на время тестов прописать тестовый CA.
Установка и первоначальная настройка скрипта на этом завершены. Теперь можно получать сертификаты.

Для начала получим сертифкат для одного домена: letest.lexore.net

В nginx для теста сделаем простой конфиг виртуального хоста, который будет выводить протокол, http или https.

server {
    listen 80;
    server_name letest.lexore.net;
    location /.well-known/acme-challenge/ { alias /opt/letsencrypt/.acme-challenges/; }

    location / {
         default_type text/plain;
         return 200 "scheme: $scheme";
    }
}

Ключевой параметр: location /.well-known/acme-challenge/
В папке /opt/letsencrypt/. acme-challenges/ создаются файлы для подтверждения, что вы управляете сайтом.
Они должны быть доступны по адресу имя_сайта/.well-known/acme-challenge/, иначе сертификат не подпишут.
Названия файлов генерируются случайным образом, поэтому проще открыть доступ ко всей папке.
В конце скрипт удаляет созданный файл, так что папка не будет захламляться.

Перезагрузим nginx и проверим сайт:

$ curl -i letest.lexore.net
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 Jun 2016 13:13:18 GMT
Content-Type: text/plain
Content-Length: 12
Connection: keep-alive

scheme: http

Теперь нужно прописать имя хоста в domains.txt и запустить сам скрипт

$ echo letest.lexore.net > /opt/letsencrypt/domains.txt
$ /opt/letsencrypt/letsencrypt.sh --cron
# INFO: Using main config file /opt/letsencrypt/config
Processing letest.lexore.net
 + Signing domains...
 + Creating new directory /opt/letsencrypt/certs/letest.lexore.net ...
 + Generating private key. ..
 + Generating signing request...
 + Requesting challenge for letest.lexore.net...
 + Responding to challenge for letest.lexore.net...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!

Сертификат готов, файлы сертификата и ключа лежат в папке «/opt/letsencrypt/certs/letest.lexore.net«.
Осталось добавить настройки в nginx. Нужно добавить следующие строки в конфиг виртуального хоста:

listen   443 ssl;
ssl_certificate /opt/letsencrypt/certs/letest.lexore.net/fullchain.pem;
ssl_certificate_key /opt/letsencrypt/certs/letest.lexore.net/privkey.pem;

После перезагрузки nginx, можно пробовать сайт в браузере.
Если в конфиге скрипта был указан тестовый CA, браузер заругается на сертификат.
Как выглядит такой сертификат в firefox
Но это все равно значит, что скрипт и nginx настроены правильно.
Теперь нужно просто поменять CA в конфиге на боевое значание и запустить скрипт ещё раз, добавив параметр --force.
Без этого параметра скрипт не станет заново генерировать сертификат, т.к. ещё не подошел срок устаревания, указанный в конфиге.

le@endor:~$ /opt/letsencrypt/letsencrypt.sh --cron --force
# INFO: Using main config file /opt/letsencrypt/config
Processing letest.lexore.net
 + Checking domain name(s) of existing cert... unchanged.
 + Checking expire date of existing cert...
 + Valid till Sep 24 12:13:00 2016 GMT (Longer than 80 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for letest.lexore.net...
 + Responding to challenge for letest.lexore.net...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!

После запуска скрипта и перезагрузки nginx у сайта появится правильный сертификат.
Сертификат готов, https работает.
Как выглядит правильный сертификат

Пару слов про несколько доменов.
Один сертификат может использоваться для нескольких доменов. Например, вот как это будет выглядеть, если добавить subdomain.letest.lexore.net.
Запуск скрипта:

$ /opt/letsencrypt/letsencrypt.sh --cron --force
# INFO: Using main config file /opt/letsencrypt/config
Processing letest.lexore.net with alternative names: subdomain.letest.lexore.net
 + Checking domain name(s) of existing cert... changed!
 + Domain name(s) are not matching!
 + Names in old certificate: letest.lexore.net
 + Configured names: letest.lexore.net subdomain.letest.lexore.net
 + Forcing renew.
 + Checking expire date of existing cert...
 + Valid till Sep 24 12:48:00 2016 GMT (Longer than 80 days). Ignoring because renew was forced!
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for letest.lexore.net...
 + Requesting challenge for subdomain.letest.lexore.net...
 + Responding to challenge for letest.lexore.net...
 + Challenge is valid!
 + Responding to challenge for subdomain. letest.lexore.net...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!

Правка конфига nginx, перезапуск, и вот новый сертификат работает уже на два домена.
Скриншот такого сертификата в firefox

Домены не обязаны быть как-то связаны, можно сделать один домен для domain.com и ftp.example.net.
Максимум можно указать 100 доменов в одном сертификате.
Кому-то этого может хватить, чтобы обойтись одним сертификатом для всех сайтов на сервере.
Правда, этот сертификат придется пересоздавать на каждый новый домен в списке, и можно упереться в лимиты.

А теперь самое приятное — автоматизация.

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

0 1 * * * /opt/letsencrypt/letsencrypt.sh --cron

Таким образом, алгоритм перевода последующих сайтов на https:

Это не единственный способ автоматизации, многие клиенты letsencrypt позволяют свести всю работу к запуску одного скрипта по крону.

Данный скрипт мне понравился за простоту- всю работу делает один скрипт на bash.

А так же, за свои дополнительные возможности — кроме простой автоматизации, он из коробки поддерживает «сложную» автоматизацию, запуск своих скриптов и переопределение параметров.

Например, я уже упомянул про параметр HOOK в конфиге, который позволяет запускать свой скрипт.

Так же из коробки есть параметр CONFIG_D — папка, в которой будут запускаться все .sh скрипты для переопределения параметров основного конфига.

Плюс, поддержка разных «аккаунтов» через указание разных ACCOUNTDIR — папок с приватными ключами для подписи запросов.

Мне кажется, это позволит использовать скрипт в больших и сложных инфраструктурах.

Краткая памятка по настройке HTTPS для Nginx через LetsEncrypt — блог cdnnow!

Краткая памятка по настройке HTTPS для Nginx через LetsEncrypt

Сначала несколько общеизвестных фактов:

• Сервис LetsEncrypt бесплатно предоставляет всем желающим заверенные SSL-сертификаты для доменных имён в публичных DNS-зонах.
• Общение с сервисом производится только через API с помощью клиентских утилит, веб-интерфейса у него нет.
• Выдавая сертификат на доменное имя, сервис требует от заявителя подтвердить, что он действительно является владельцем данного имени.
• Подтверждение возможно одним из двух способов: через HTTP (по умолчанию) или через DNS.

Что требуется для подтверждения через HTTP?

• Клиентская утилита обязана запускаться на том сервере, в IP-адрес которого распознаётся заверяемое доменное имя.
• IP-адрес обязан быть публичным.
• На порту 80 должен быть запущен Веб-сервер.
• Веб-серверу требуется небольшая дополнительная настройка, чтобы правильно отвечать на проверочные запросы LetsEncrypt.

Почему в качестве клиентской утилиты мы выбрали dehydrated?

• Потому что это один файл на bash с минимумом зависимостей (openssl и curl).
• Потому что его пакет есть в стандартных репозитариях большиства дистрибутивов.
• Потому что у него простая ручная установка в тех дистрибутивах, в которых готовый пакет отсутствует (например, в Ubuntu 16.04) или устарел.

Ручная установка (если нет готового пакета):

• Скачиваем сценарий и делаем исполняемым:

cd /usr/bin
wget https://raw.githubusercontent.com/lukas2511/dehydrated/master/dehydrated
chmod +x dehydrated

mkdir /etc/dehydrated /var/lib/dehydrated

BASEDIR=/var/lib/dehydrated
WELLKNOWN="${BASEDIR}/acme-challenges"
DOMAINS_TXT="/etc/dehydrated/domains.txt"

Создаём ключи и получаем сертификаты:

• Сначала создаём учётную запись в LetsEncrypt:

dehydrated --register --accept-terms

Добавляем имена в файл /etc/dehydrated/domains. ~ /.well-known/acme-challenge {
alias /var/lib/dehydrated/acme-challenges;
}
location / {
return 301 https://$host$request_uri;
}

nginx -t
nginx -s reload

dehydrated -c

Теперь включаем HTTPS:

• Добавляем в /etc/nginx/sites-enabled/xx.ru.conf:

server {
      listen 443 ssl;
      server_name xx.ru www.xx.ru;

      ssl_certificate     /var/lib/dehydrated/certs/xx.ru/fullchain.pem;
      ssl_certificate_key /var/lib/dehydrated/certs/xx.ru/privkey.pem;
}

nginx -s reload

Настраиваем автопродление:

• Сертификаты выдаются на 90 суток.
• «dehydrated -c» без ключа «—force» не пытается продлевать сертификат, если он выдан менее 80 суток назад.
• Поэтому оптимально вызывать продление раз в неделю — т.е. с минимумом неудачных попыток, но с гарантированным попаданием в заключительный 10-дневный интервал.
• Для этого создаём файл /etc/cron.weekly/Dehydrated (и делаем его исполняемым через «chmod +x»):

#!/bin/sh

dehydrated -c -g

#!/bin/sh

test "$1" = "deploy_cert" || exit 0

nginx -s reload

Проверяем, что /etc/dehydrated/config или /etc/dehydrated/conf. d/*.sh содержит директиву «HOOK=/etc/dehydrated/hook.sh» — в некоторых дистрибутивах она отсутствует!

Как и зачем использовать подтверждение через DNS вместо HTTP?

• Сайт или сервис может быть недоступен из внешнего мира (находиться в офисной локальной сети, приватном облаке и т.д),
  поэтому LetsEncrypt не сумеет обратиться к нему извне, чтобы проверить владельца.
• Либо по каким-то причинам мы вынуждены запускать клиентскую утилиту с другого компьютера.
• В этом случае LetsEncrypt позволяет подтверждать владение доменом через специальные DNS-записи.
• Для этого dehydrated должен запускаться с дополнительным ключом «-t dns-01».
• Сценарий hook.sh становится примерно таким:

#!/bin/sh

case "$1" in
  "deploy_challenge")  printf "Please add to DNS:\n_acme-challenge. ~ /.well-known/acme-challenge {
       alias  /usr/home/www/letsencrypt;
       allow all;
       default_type "text/plain";
}

В конфиги vhost-ов nginx'а добавляем:

include /usr/local/etc/nginx/letsencrypt.conf;

Настройка dehydrated и полчение сертификатов:

Копируем /usr/local/etc/dehydrated/config.example в config и редактируем его. Нам понадолилось изменить следующее:

Где:
— IP_VERSION — работаем по ipv4;
— KEYSIZE — размер ключа. По умолчанию тут значение 4096, но мы считаем, что без особой надобности увелчивать время загрузки страниц, дополнительно греть процессора как на строне сервера так и на строне клиента — смысла нет. Тем более, что сертификат A+ можно получить и на 2048;
— CONTACT_EMAIL — сюда нам буду приходит уведомления о скором истечении срока действия сертификатов и другая инйормация от Letsencrypt.

Создаем и редактируем файл /usr/local/etc/dehydrated/domains.txt:

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

Регистрируем наш акаунт:

Дальше, хорошо бы проверить, не ошиблись ли мы где в настройках? Для этого:
— добавляем в /usr/local/etc/dehydrated/config строку:

— и вперед:

Если есть ошибки, исправляем их, повторяем запрос. Поле успешного прохождения проверок, в /usr/local/etc/dehydrated/config ремим строку:

Удаляем тестовые сертификаты и все остальное в папке /usr/local/etc/dehydrated/certs
И точно так же выполняем запрос на получение «боевых» сертификатов:

dehydrated -c

Настройка nginx:

server {

    listen 80;

    server_name bla-bla. com www.bla-bla.com;

    location /.well-known/acme-challenge/ {

        alias /usr/local/www/dehydrated/;

    }

    location / {

    }

}

server {

    listen      443 ssl;

    server_name bla-bla.com;

    ssl_certificate     /usr/local/etc/dehydrated/certs/bla-bla.com/fullchain.pem;

    ssl_certificate_key /usr/local/etc/dehydrated/certs/bla-bla.com/privkey.pem;

    ssl_stapling on;

    ssl_stapling_verify on;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

    . ..

    ...

}

Проверка корректности настроек.

Для этого используем:
Проверка корректности цепочки сертификатов, SSL Checker
SSL Server Test от SSL Labs

Настройка обновления сертификатов.

Не мудрствуя лукаво, настраиваем выполнение запроса на обновления сертификатов, например, раз в неделю:
crontab

Вроде, все. Всем сертификатов не ниже A+.

Установка LetsEncrypt SSL-сертификатов прямо из панели виртуальной машины bitrix VM!


С версии 7. 2.2 битрикс-машины появилась возможность подключать бесплатные валидные SSl-сертификаты от Lets Encrypt прямо из меню виртуальной машины.


Let’s Encrypt — центр сертификации, начавший работу в бета-режиме с 3 декабря 2015 года, предоставляющий бесплатные криптографические сертификаты для HTTPS. Процесс выдачи сертификатов полностью автоматизирован. Сертификаты выдаются только на 3 месяца для предотвращения инцидентов безопасности.


Ограничения LetsEncrypt:

1/ https://community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394
2/ Firefox. Как мимимум с 4.0 (возможно с 1.0) работает. (StartSSL в древних лисах работать не будет). Все современные лисы работают всеми CA.
3/ Thunderbird. Точно все современные версии на всех ОС (включая wosign. StartSSL в древних версиях не поддерживается)
4/ IE и Edge. Минимум 8 версия для всех. IE6 точно не поддерживается, по IE7 в зависимости от условий.
5/ Chrome и Cromium. Поддержка ОС аналогично встроенной ОС криптоапи (древние макоси, линуксы и winXP не будут работать ни с каким CA).
6/ Safari на всех современных Apple-устройствах точно работает.
7/ Android точно работает с версии 4.2 со всеми . Версия 2.0.6 (Android browser 2.0.6 Webkit 530.17) точно НЕ работает.
8/ Java не работает с letsencrypt.
9/ wget и curl могут не работать на старых системах

Как установить бесплатный ssl сертификат от Lets Encrypt в битрикс-машине?


В меню машины пройти по пунктам 8. Manage web nodes in the pool -> 3. Certificates configuration -> 1. Configure Let's encrypt certificate. Указать сайт (или сайты), dns имена сайта(-ов), email для нотификаций сервиса Lets Encrypt, подтвердить ввод.


Пример:


Мастер самостоятельно запросит и установит сертификат из сети.

Поддерживается ввод нескольких сайтов, через запятую (test1.bx, test2.bx).


Перевыпуск сертификатов будет автоматический. Это отлично, с учетом того что сертификат дается только на 3 месяца.

Что делать, если сертификат не устанавливается и битрикс машина выдает ошибку?


Мое знакомство с данным новшеством прошло именно так: после настройки сертификата фоновая задача в машине завершалась с ошибкой:

---------------------------------------------------------
TaskID                      |    Status | Last Step
----------------------------------------------------------
site_certificate_1113161018 |    error |  play|complete


Смотрим логи и выясняем подробности. Директория /opt/webdir/temp содержит логи задач, смотрим по нашей задаче site_certificate_1113161018.


Первый лог /opt/webdir/temp/site_certificate_1113161018/status, в нем есть строчка с прерыванием, а также видим и второй лог:

TASK [web : create certificates] ***********************************************
fatal: [acrit]: FAILED! => {"changed": true, "cmd": "/home/bitrix/dehydrated/dehydrated 
-c > /home/bitrix/dehydrated_update. log 2>&1" ...


С этого места становиться понятно, что машина установила библиотеку dehydrated в папку /home/bitrix/dehydrated, а лог ее выполнения расположен в dehydrated_update.log


Смотрим второй лог /home/bitrix/dehydrated_update.log, в нем тоже есть ошибка:

+ Responding to challenge for www.goooodsite.ru..
ERROR: Challenge is invalid! (returned: invalid) (result: {
 "type": "http-01",
 "status": "invalid",
 "error": {
   "type": "urn:acme:error:unauthorized",
   "detail": "Invalid response from http://www.goooodsite.ru/.well-known/acme-challenge/dummy",
   "status": 403
 }, 
})


Выходит, что для проверки требуется доступность сайта по http и https с самоподписанным сертификатом, дабы проверить права владения на оба сайта.


Поэтому настроим редирект и еще раз запустим получение ключа:


1/ Отключаем редирект с http и https


2/ Создаем вручную папку на сайте /. well-known/acme-challenge/ с текстовым файлом внутри:

echo "thisisthecontentoffile" > /home/bitrix/www/site/.well-known/acme-challenge/dummychallengefile


и проверяем чтобы этот файл корректно открывался для http и https: http://www.goooodsite.ru/.well-known/acme-challenge/dummychallengefile https://www.goooodsite.ru/.well-known/acme-challenge/dummychallengefile


3/ Запускаем заново, и опять ошибка. Опять смотрим логи задачи. На этот раз сертификат получен, а ошибка в конфигурации сайта в nginx: /etc/nginx/bx/site_avaliable/bx_ext_ssl_www.goooodsite.ru.conf


4/ ошибку устраняем (лишняя директива из-за авто-вставки настроек в файл) и видим что сертификат добавился в конфиг, а сами сертификаты хранятся тут /home/bitrix/dehydrated/certs/:

# CERTIFICATE ANSIBLE MANAGED BLOCK
include bx/conf/ssl_options.conf;
ssl_certificate   /home/bitrix/dehydrated/certs/www.goooodsite.ru/fullchain.pem;
ssl_certificate_key  /home/bitrix/dehydrated/certs/www. goooodsite.ru/privkey.pem;
ssl_trusted_certificate /home/bitrix/dehydrated/certs/www.goooodsite.ru/chain.pem;
# CERTIFICATE ANSIBLE MANAGED BLOCK


5/ nginx перезапускаем, редирект из http в https возвращаем. Сертификат добавлен.


Вот собственно путь отладки и исправления ошибки авто-установки сертификата, если сертификат был установлен на сайте, как написано в статье "Установка ssl-сертификата для битрикс окружения bitrix vm".


Использованные материалы:

Назад в раздел

Найдена причина проблем dehydrated с ACME-серверами, отличными от LetsEncrypt

Sebastian Krause определил источник странной несовместимости с сервисом Bypass скрипта dehydrated, используемого для автоматизации получения TLS-сертификатов по протоколу ACME. С Bypass работают и эталонный клиент, и uacme, но не dehydrated (точнее, он тоже с некоторыми обходными манёврами заработал, но исключительно в режиме dns-1).

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

При обсуждении проблемы было предложено использовать внешний парсер JSON, такой как json_pp или jq (добавить в pipe 'jq -r ».authorizations | .[]»' для корректного разбора). Недостатком такого подхода является размытие идеи обойтись минимальными и легко верифицируемыми средствами, а также проблемы с обработкой ошибок.

Автор проекта dehydrated (проект недавно был продан компании Apilayer GmbH) согласился, что разбор JSON является большой проблемой, но добавлять внешние парсеры он не считает хорошей идеей, так как одним из ключевых достоинств скрипта является отсутствие привязки к внешним зависимостям. В настоящее время он занят, но надеется в ближайшие несколько дней уделить внимание решению проблемы. В планах отмечена является переработка парсера JSON или интеграция готового парсера на языке shell — JSON.sh.

Источник: http://www.opennet.ru/opennews/art.shtml? num=53279

© 
OpenNet

Установка SSL-сертификатов от LetsEncrypt в Bitrix VM

Let’s Encrypt – некоммерческий удостоверяющий центр, который предоставляет бесплатные X.509 сертификаты для TLS шифрования с помощью автоматизированного процесса, направленного на замену текущего сложного процесса ручного создания, проверки, подписи, установки и обновления сертификатов для защищённых веб-сайтов.

Выполнить установку Bitrix возможно с помощью наших OCA (one click application):

Установка будет выполнена с помощью официального инсталлятора окружения от 1С который называется «1С-Битрикс: Веб-окружение»

«1C-Битрикс: Виртуальная машина» специально сконфигурирована для быстрого исполнения программных продуктов «1С-Битрикс»: разворачивается за минуты и сразу же готова к работе!

Для установки сертификата, выполните вход на сервер под пользователем root и запустите скрипт:

 /root/menu. sh

После добавления сайта через меню машины, пройдите по пунктам:

• 8. Manage pool web servers

• 3. Configure certificates

• 1. Configure Let's encrypt certificate

Укажите сайт, dns имена сайта, email для нотификаций сервиса Lets Encrypt

Далее, подтвердите ввод.

При повторной проверке будет виден путь к сертификатам:

There are 1 sites:  
------------------------------------------------------------------------------------
SiteName        | dbName          |       Type | S | Certificate          | Key  
------------------------------------------------------------------------------------
mecmep.site     | dbmecmep        |     kernel | N | /home/bitrix/dehydrated/certs/mecmep.site/fullchain.pem | /home/bitrix/dehydrated/certs/mecmep.site/privkey.pem  
------------------------------------------------------------------------------------
Note:  
S - Only HTTPS access to the server (N = turned off, Y = turned on)

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

обезвоженный / конфигурация на главном сервере · обезвоженный-io / обезвоженный · GitHub

.


.


	########################################################################### #######
	# Это основной файл конфигурации для обезвоженного #
	# #
	# Этот файл ищется в следующих местах: #
	# $ SCRIPTDIR / config (рядом с этим скриптом) #
	# / usr / local / etc / dehydrated / config #
	# / etc / dehydrated / config #
	# $ {PWD} / config (в текущем рабочем каталоге) #
	# #
	# Значения по умолчанию этого конфига в комментариях #
	############################################## #######
	# Какой пользователь должен работать с обезвоживанием? Это будет неявно применяться при запуске с правами root
	# DEHYDRATED_USER =
	# Какая группа должна работать с обезвоживанием? Это будет неявно применяться при запуске с правами root
	# DEHYDRATED_GROUP =
	# Разрешить имена только адресам версии IP.(локон)
	# поддерживаемые значения: 4, 6
	# по умолчанию:
	# IP_VERSION =
	# URL-адрес центра сертификации или внутренней предварительной настройки
	# Пресеты: letsencrypt, letsencrypt-test, zerossl, buypass, buypass-test
	# по умолчанию: letsencrypt
	# CA = "letsencrypt"
	# Путь к старому центру сертификации
	# Установите это значение на свое старое значение CA при обновлении с ACMEv1 до ACMEv2 под другой конечной точкой.
	# Если dehydrated обнаруживает ключ учетной записи для старого CA, он автоматически повторно использует этот ключ
	# вместо регистрации нового.
	# по умолчанию: https://acme-v01.api.letsencrypt.org/directory
	# OLDCA = "https://acme-v01.api.letsencrypt.org/directory"
	# Какой вызов следует использовать? В настоящее время поддерживаются http-01, dns-01 и tls-alpn-01
	# CHALLENGETYPE = "http-01"
	# Путь к каталогу, содержащему дополнительные файлы конфигурации, позволяющий переопределить
	# значения по умолчанию, найденные в основном файле конфигурации. Дополнительные файлы конфигурации
Имя	# в этом каталоге должно иметь окончание .sh.
	# по умолчанию:
	# CONFIG_D =
	# Каталог для файлов конфигурации домена.
	# Если не установлен, конфигурации для каждого домена берутся из каждого каталога вывода сертификатов.
	# по умолчанию:
	# DOMAINS_D =
	# Базовый каталог для ключа учетной записи, сгенерированных сертификатов и списка доменов (по умолчанию: $ SCRIPTDIR - использует каталог конфигурации, если не определен)
	# BASEDIR = $ SCRIPTDIR
	# Файл со списком доменов, для которых запрашиваются сертификаты (по умолчанию: $ BASEDIR / domains. txt)
	#DOMAINS_TXT = "$ {BASEDIR} /domains.txt"
	# Каталог вывода для сгенерированных сертификатов
	#CERTDIR = "$ {BASEDIR} / certs"
	# Каталог вывода для сертификатов проверки alpn
	#ALPNCERTDIR = "$ {BASEDIR} / alpn-certs"
	# Справочник ключей учетной записи и регистрационной информации
	#ACCOUNTDIR = "$ {BASEDIR} / account"
	# Выходной каталог для токенов вызова, которые будут обслуживаться веб-сервером или развернуты в HOOK (по умолчанию: / var / www / dehydrated)
	#WELLKNOWN = "/ var / www / dehydrated"
	# Размер по умолчанию для закрытых ключей (по умолчанию: 4096)
	# KEYSIZE = "4096"
	# Путь к файлу конфигурации openssl (по умолчанию: - пытается выяснить системное значение по умолчанию)
	# OPENSSL_CNF =
	# Путь к бинарному файлу OpenSSL (по умолчанию: "openssl")
	# OPENSSL = "openssl"
	# Дополнительные параметры передаются в двоичный файл curl (по умолчанию: )
	# CURL_OPTS =
	# Программа или функция, вызываемая в определенных ситуациях
	#
	# После генерации запроса-ответа или после неудачного запроса (в этом случае altname пусто)
	# Указанные аргументы: clean_challenge | deploy_challenge altname token-filename token-content
	#
	# После успешной подписи сертификата
	# Указанные аргументы: deploy_cert путь домена / к / privkey. pem путь / к / cert.pem путь / к / fullchain.pem
	#
	# Переменные BASEDIR и WELLKNOWN экспортируются и могут использоваться во внешней программе
	# по умолчанию:
	# КРЮЧОК =
	# Цепочка аргументов clean_challenge | deploy_challenge вместе в один вызов ловушки для каждого сертификата (по умолчанию: нет)
	# HOOK_CHAIN ​​= "нет"
	# Минимум дней до истечения срока для автоматического обновления сертификата (по умолчанию: 30)
	# RENEW_DAYS = "30"
	# Регенерировать закрытые ключи вместо того, чтобы просто подписывать новые сертификаты при обновлении (по умолчанию: да)
	# PRIVATE_KEY_RENEW = "да"
	# Создать дополнительный закрытый ключ для пролонгации (по умолчанию: нет)
	# PRIVATE_KEY_ROLLOVER = "нет"
	# Какой алгоритм открытого ключа следует использовать? Поддерживаются: rsa, prime256v1 и secp384r1
	# KEY_ALGO = secp384r1
	# E-mail для использования при регистрации (по умолчанию: )
	# CONTACT_EMAIL =
	# Расположение файла блокировки для предотвращения одновременного доступа (по умолчанию: $ BASEDIR / lock)
	#LOCKFILE = "$ {BASEDIR} / lock"
	# Возможность добавления CSR-флага, указывающего, что сшивание OCSP является обязательным (по умолчанию: нет)
	# OCSP_MUST_STAPLE = "нет"
	# Получить ответы OCSP (по умолчанию: нет)
	# OCSP_FETCH = "нет"
	# Интервал обновления OCSP (по умолчанию: 5 дней)
	# OCSP_DAYS = 5
	# Каталог кэша цепочки эмитентов (по умолчанию: $ BASEDIR / цепочки)
	#CHAINCACHE = "$ {BASEDIR} / цепочки"
	# Автоматическая очистка (по умолчанию: нет)
	# AUTO_CLEANUP = "нет"
	# Версия ACME API (по умолчанию: авто)
	# API = авто
	# Предпочтительная цепочка эмитентов (по умолчанию: -> используется цепочка по умолчанию)
	# PREFERRED_CHAIN ​​=

Не могу продлить сертификат (обезвоженный) - Справка

Пожалуйста, заполните поля ниже, чтобы мы могли помочь вам лучше. Примечание: вы должны указать свое доменное имя, чтобы получить помощь. Все доменные имена для выпущенных сертификатов публикуются в журналах прозрачности сертификатов (например, https://crt.sh/?q=example.com), поэтому отказ от вашего доменного имени здесь не увеличивает секретность, а только усложняет нам задачу оказать помощь.

Мой домен: cloud.exig.fr
на том же сервере я могу продлить сертификат для ***. Exig.fr

Я выполнил эту команду:

. / Обезвоженный -c

Он произвел такой результат:

https: // pastebin.com / ZMLwyRnR

• Крючок: нечего делать…
• Крючок: Делать нечего…
Обработка cloud.exig.fr
• Крючок: Делать нечего…
• Проверка доменного имени (имен) существующего сертификата… без изменений.
• Проверка срока действия существующего сертификата…
• Действителен до 18 ноября 11:04:02 2018 по Гринвичу Срок действия сертификата истекает
(менее 30 дней). Обновление!
• Подписание доменов…
• Генерация закрытого ключа…
• Создание запроса на подпись…
• Запрос нового заказа сертификата от CA…
• Получено 1 URL-адрес авторизации от CA
• Обработка авторизации для облака. exig.fr
• 1 ожидающие рассмотрения задачи
• Развертывание жетонов испытаний…
• Крючок: Делать нечего…
• Ответ на запрос авторизации cloud.exig.fr…
• Крючок: Делать нечего…
• Жетоны испытаний на очистку…
• Крючок: Делать нечего…
• Проверка запроса не удалась.
ОШИБКА: запрос недействителен! (возвращено: недействительно) (результат: {
«тип»: «http-01»,
«статус»: «недопустимый»,
«ошибка»: {
«тип»: «urn: ietf: params: acme: error») : connection »,
« detail »:« Получение https: // cloud.exig.fr.well-known / acme-challenge / bbBzr6CFnctXDIgU7pwB55_9liKQ4D4DGZpWDbpUBT0: Ошибка при получении данных проверки »,
« статус »: 400
},
« url »:« https://acme-vmecryapi.let. / Challenge / Xxi2483guTD9NriqgzxmJl-4mo7U1ypFgiK01-8Jvpk / 9278317271 »,
« токен »:« bbBzr6CFnctXDIgU7pwB55_9liKQ4D4DGZpWDbp669. acme-challenge / bbBzr6CFnctXDIgU7pwB55_9liKQ4D4DGZpWDbpUBT0 »,
« имя хоста »:« cloud. exig.fr »,
« порт »:« 80 »,
« разрешенные адреса »: [
« 82.127.205.35 »
],
« addressUsed »:« 82.127.205.35 »
},
{
« url »:« https: //cloud.exig.fr.well-known/acme-challenge/bbBzr6CFnctXDIgU7pwB55_9liKQp0D. «Hostname»: «cloud.exig.fr.well-known»,
«port»: «443»,
«addressResolved»: [
«82.127.205.35»
]
}
]
})

Мой веб-сервер (включая версию):

Версия сервера: Apache / 2.4.25 (Debian)
Сервер построен: 2018-06-02T08: 01: 13

Операционная система, на которой работает мой веб-сервер, (включая версию):

PRETTY_NAME = «Debian GNU / Linux 9 (stretch)»
NAME = «Debian GNU / Linux»
VERSION_ID = «9»
VERSION = «9 (stretch)»
ID = debian
HOME_URL = «https: // www .debian.org/ »
SUPPORT_URL =« https://www.debian.org/support »
BUG_REPORT_URL =« https://bugs.debian.org/ »

Мой хостинг-провайдер, если применимо, это: мой собственный сервер

Я могу войти в корневую оболочку на моем компьютере (да или нет, или я не знаю): да

Я использую панель управления для управления своим сайтом (нет, или укажите название и версию панели управления): нет

description:
У меня есть 2 сертификата на моем сервере: cloud. exig.fr и anotherdomain.exig.fr.
недавно успешно получил сертификат для другого домена.exig.fr бит, я не могу продлить cloud.exig.fr

проверил:

DNS A и CNAME: OK
Vhost: OK
IP: OK
Проверить, открыт ли порт: OK

ты можешь мне помочь?

thx

обезвоженный быстрый старт - ratfactor

Давайте изменим URL-адрес CA с "промежуточного" на рабочий API ( acme-v01 ):

 $ sudo sed -i 's / acme-staging / acme-v01 /' / etc / dehydrated / config 

Все, что сделала команда sed выше, это изменила строку конфигурации:

 ОТ: CA = "https: // acme-staging.api.letsencrypt.org/directory "
Кому: CA = "https://acme-v01.api.letsencrypt.org/directory" 

(Не стесняйтесь вносить изменения в своем любимом текстовом редакторе.)

Мы почти готовы снова запустить обезвоживание.
Но если мы это сделаем, он увидит, что у нас уже есть сертификат (от staging), и не будет запрашивать новый.
(Попробуйте и убедитесь!)

Чтобы получить настоящий сертификат, нам нужно удалить тестовый:

 $ sudo rm -rf / etc / dehydrated / certs / * 

Теперь вы готовы к настоящему сертификату:

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

Теперь у вас есть новый каталог, содержащий сертификаты для вашего домена (ов):

 $ sudo tree / etc / обезвоженный /
/ и т. д. / обезвоженный /
| - счета
| - сертификаты
| | - example.com
| | | - cert-000000000.csr
| | | - cert-000000000.pem
| | | - cert.csr -> cert-000000000.csr
| | | - cert.pem -> cert-000000000.pem
| | | - цепь-000000000.pem
| | | - chain.pem -> цепочка-000000000.pem
| | | - fullchain-000000000.pem
| | | - fullchain.pem -> fullchain-000000000.pem
| | | - Privkey-000000000.pem
| | `- privkey.pem -> privkey-0000000000.pem
| `- тест
| - конфигурация
`- domains.txt 

Серьезная конфигурация Apache выходит за рамки этой статьи, но вот основная идея того, что вы хотите использовать для своего нового сертификата в /etc/httpd/httpd. conf (или там, где вы и ваш дистрибутив хотите хранить конфигурацию Apache):

 
ServerName example.com
SSLEngine включен
SSLCertificateFile / etc / dehydrated / certs / example.com / cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/example.com/privkey.pem
SSLCertificateChainFile /etc/dehydrated/certs/example.com/fullchain.pem
 

Перезапустите Apache, чтобы загрузить новые директивы:

 $ sudo /etc/rc.d/rc.httpd перезапуск 

Вышеупомянутое работает в Slackware; вам может потребоваться найти правильный способ перезапуска Apache в выбранном вами дистрибутиве.

Поздравляем, теперь у вас должен быть защищенный домен, доступный по адресу https: // <ваш домен> .

Let’s Encrypt - документация FusionPBX Docs

Затем выполните сценарий.

Настройка нескольких доменов на Let's Encrypt

Перед настройкой нескольких доменов убедитесь, что в вашем основном домене работает SSL, следуя приведенным выше инструкциям.

Создать общий файл хоста nginx для всех доменов

vim / etc / nginx / includes / fusionpbx-default-config

Вставьте приведенный ниже код в файл

 ssl_protocols TLSv1 TLSv1.. * / provision / ([0-9] {1,11}) _ Phonebook.xml $ "" /app/provision/?ext=$1&file={%24mac}_phonebook.xml "last;

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

client_max_body_size 80M;
client_body_buffer_size 128 КБ;

место расположения / {
  корень / вар / www / fusionpbx;
  индекс index.php;
}

расположение ~ \ .php $ {
  fastcgi_pass unix: /var/run/php/php7.1-fpm.sock;
  #fastcgi_pass 127.0.0.1:9000;
  fastcgi_index index.php;
  включить fastcgi_params;
  fastcgi_param SCRIPT_FILENAME / var / www / fusionpbx $ fastcgi_script_name;
}

# Отключить просмотр.. +. (db) $ {
  все отрицать;
}
 

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

сенсорный / etc / nginx / includes / fusionpbx-domains

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

vim / etc / nginx / сайты-доступные / fusionpbx

Добавьте строку ниже в самом конце файла после завершающего «}»

включают / etc / nginx / includes / fusionpbx-domains;

Теперь вы готовы начать использовать SSL в нескольких доменах для вашей установки FusionPBX.

Выполняйте следующие действия каждый раз при добавлении нового домена

Создайте файл conf для нового домена (замените example.com на свой собственный домен)

vim /etc/letsencrypt/configs/example.com.conf

Вставьте это в файл .conf (не забудьте изменить значения по умолчанию, особенно домен)

 # домен, для которого мы хотим получить сертификат;
# технически возможно иметь несколько таких строк, но это только работало
# с одним доменом для меня, другой получил только один сертификат, поэтому я бы рекомендовал
# отдельные файлы конфигурации для каждого домена.домены = мой-домен

# увеличить размер ключа
rsa-key-size = 2048 # или 4096

# текущая закрытая бета-версия (по состоянию на 7 ноября 2015 г.) использует этот сервер
server = https://acme-v01.api.letsencrypt.org/directory

# на этот адрес будут приходить напоминания о продлении
email = my-email

# выключаем пользовательский интерфейс ncurses, мы хотим, чтобы это выполнялось как cronjob
text = True

# аутентифицироваться, поместив файл в корневой каталог (под . well-known / acme-upatechallenge /)
# а затем позволить LE получить его
аутентификатор = webroot
webroot-path = / var / www / letsencrypt /
 

Получите сертификат от Let's Encrypt (опять же, пример ответа.com с вашим доменом)

 cd / opt / letsencrypt
./letsencrypt-auto --config /etc/letsencrypt/configs/example.com.conf Certonly
 

Установить сертификат для автоматического продления с другими доменами

 компакт-диск / etc / fusionpbx
vim refresh-letsencrypt.sh
 

Добавьте строку внизу справа, где написано «cd / opt / letsencrypt /» (снова замените example.com своим доменом)

./certbot-auto --config /etc/letsencrypt/configs/example.com.conf certonly --non-interactive --keep-until-expiring --agree-tos --quiet

Наконец, добавьте ваш новый домен для загрузки

vim / etc / nginx / includes / fusionpbx-domains

Вставьте приведенный ниже код в самый конец файла (снова замените example. com с вашим доменом)

 сервер {
        слушать 443;
        имя_сервера example.com;
        ssl включен;
        ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

        включить / etc / nginx / includes / fusionpbx-default-config;
}
 

Готово! Перезапустите nginx, чтобы изменения вступили в силу

перезапуск службы nginx

Let's Encrypt SSL Проверка DNS

На этой странице дано пошаговое руководство по выпуску SSL-сертификатов Let's Encrypt с DNS.
проверка (dns-01) с помощью нашего DNS API.

Если у вас есть учетная запись хостинга у нас, вам не нужно следовать этому руководству. Поддержка Let's Encrypt полностью автоматизирована для учетных записей хостинга, и вы можете включить сертификат для своего веб-сайта с помощью нашей панели управления.

Let's Encrypt - это сервис, предоставляющий бесплатные SSL-сертификаты с использованием домена .
проверка , чтобы гарантировать, что сертификаты выдаются только законным
владелец домена. Let's Encrypt предоставляет несколько вариантов выполнения
проверка домена.Если вам нужны сертификаты только для веб-сервера, это проще
использовать веб-проверку по умолчанию. Для других приложений, например, если вы
нужен сертификат для почтового сервера, проверка на основе DNS идеальна. Это
требует, чтобы определенные записи TXT были вставлены в зону DNS для домена.
Это можно полностью автоматизировать с помощью нашего DNS API,
как описано на этой странице.

1. Включите DNS API для своего домена

Войдите в Mythic Beasts
в панели управления клиента щелкните Мои домены , а затем домен
рассматриваемый, а затем ссылка DNS API в серверах имен и DNS
раздел.

На этой странице вам будет предложено установить пароль для DNS API для вашего домена.

2. Установить

обезвоженный

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

Обратите внимание, что если вы хотите получить сертификаты с подстановочными знаками, вам необходимо использовать обезвоженный 0.6.0 или новее. Для stretch вам нужно будет использовать пакет из stretch-backports.

Вам также понадобится утилита dig .

 apt-get install dehydrated dnsutils 

3. Загрузите скрипт крючка Mythic Beasts

Скрипт ловушки - это скрипт, который делает необходимые запросы к нашему DNS API. Загрузите его из репозитория git по адресу / etc / dehydrated :

 кд / и т. Д. / Обезвоженный
git clone https://github.com/mythic-beasts/dehydrated-mythic-dns01.мерзавец
 

4. Настройте требуемые сертификаты

Создайте /etc/dehydrated/domains. txt , содержащий один
строка для каждого необходимого сертификата. Каждая строка должна начинаться с
имя домена, за которым следуют любые псевдонимы (альтернативные имена), которые вы хотите
включен в сертификат этого домена. Например:

 example.com www.example.com
example.net www.example.net subdomain.example.net 

5. Создайте файл паролей

Создайте файл / etc / dehydrated / dnsapi.config.txt , содержащий DNS API
пароли для вашего домена (ов). В этом файле должен быть один домен на строку, с
имя домена и пароль, разделенные пробелом (убедитесь, что
в конце файла есть новая строка):

 example.com myS3cretPassword
example.net myOtherS3ret 

Рекомендуется ограничить доступ к этому файлу:

 chmod 0600 dnsapi.config.txt 

Если вы хотите поместить этот файл в другое место, укажите путь к файлу в
MYTHIC_DNS_CONFIG

6.Настройте

обезвоженный для использования сценария ловушки

 echo HOOK = / etc / dehydrated / dehydrated-Mythic-dns01 / dehydrated-mythic-dns01. sh> /etc/dehydrated/conf.d/hook.sh
echo CHALLENGETYPE = dns-01 >> /etc/dehydrated/conf.d/hook.sh
echo HOOK_CHAIN ​​= yes >> /etc/dehydrated/conf.d/hook.sh 

Вы также должны настроить свой адрес электронной почты. Let's Encrypt отправит электронное письмо
предупреждение, если срок действия сертификата приближается к истечению и не был продлен.

 echo CONTACT_EMAIL =  me @ example.com > /etc/dehydrated/conf.d/mail.sh 

7. (необязательно) Протестируйте с помощью промежуточной службы Let's Encrypt

API Let's Encrypt ограничивает количество сертификатов, которые вы можете выдавать каждый
неделю. Для тестирования вы можете использовать промежуточную службу. Сделать это:

 echo CA = https: //acme-staging-v02.api.letsencrypt.org/directory> /etc/dehydrated/conf.d/staging.sh
echo BASEDIR = / tmp / dehydrated >> /etc/dehydrated/conf.d/staging.sh
mkdir / tmp / обезвоженный 

После завершения тестирования удалите этот файл.

8.

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

Вызов обезвоженный :

 обезвоженный -c 

Это может занять некоторое время, особенно если у вас несколько
сертификаты. Наш DNS API обновляет новые записи только раз в минуту, и у нас есть
дожидаться запуска каждого сертификата отдельно.

В случае успеха запрошенные сертификаты SSL помещаются в
/ var / lib / dehydrated / certs

9. Настройте обновление сертификата

Вам нужно будет организовать регулярную работу dehydrated -c .Он обновит все сертификаты, срок действия которых истекает в ближайшие 30 дней.

 кошка> /etc/cron.daily/dehydrated << EOF
#! / bin / sh
exec / usr / bin / dehydrated -c >> / var / log / dehydrated-cron.log 2> & 1
EOF
chmod 0755 /etc/cron.daily/dehydrated

cat> /etc/logrotate.d/dehydrated << EOF
/var/log/dehydrated-cron.log
{
        повернуть 12
        ежемесячно
        пропавший без вести
        непустой
        задержка сжатия
        компресс
}
EOF 

Debian позволяет зашифровать команду / обезвоженный · GitLab

перейти к содержанию

• Проектов
• Группы
• Фрагменты
• Помощь

• • Загрузка. ..

• Помощь

  • Какие новости

    7

  • Помощь
  • Поддерживать
  • Форум сообщества

  • Горячие клавиши
?

  • Оставить отзыв
  • Внести свой вклад в GitLab

• Войти / Зарегистрироваться

Переключить навигацию

D

обезвоженный

• Обзор проекта

  • 
Обзор проекта

  • Детали
  • Действия
  • Релизы

• Репозиторий

  • 
Репозиторий

  • Файлы
  • коммитов
  • Филиалы
  • Теги
  • Авторы
  • График
  • Сравнить

• Этикетки

• Запросы на слияние

  0

  • 
    Запросы на слияние
    

    0

• CI / CD

  • 
CI / CD

  • Трубопроводы

  • Вакансии

  • Расписания

• Операции

  • 
Операции

  • Среды

• Пакеты и реестры

  • 
Пакеты и реестры

  • Реестр контейнеров

• Аналитика

  • 
Аналитика

  • CI / CD
  • Репозиторий
  • поток создания ценности

• Вики

  • 
Вики


• Фрагменты

  • 
Фрагменты


• Члены

  • 
Члены


• Мероприятия

• График
• Вакансии
• Совершает

Свернуть боковую панель

Закрыть боковую панель

Открыть боковую панель

• Debian Lets Encrypt Team
• обезвоженный

D

ID проекта: 6874

Звезда

2

• 805 Фиксирует
• 9 Филиалы
• 62 Теги
• 1. 8 МБ Файлы
• 1,8 МБ Хранилище

упаковка обезвоженная

Прочитайте больше

debian / master

Переключатель ответвления / бирки

Найти файл

Выберите формат архива

Скачать исходный код

застегивать
tar.gz
tar.bz2
деготь

Клонировать

• Клонировать с помощью SSH

• Клонировать с HTTPS

• Откройте в своей IDE

  Код Visual Studio

Скопируйте URL-адрес клона HTTPS

• Скопируйте URL-адрес клона SSH git @ salsa.debian.org:letsencrypt-team/dehydrated.git
• Скопируйте URL-адрес клона HTTPS https://salsa.debian.org/letsencrypt-team/dehydrated.git

• ПРОЧИТАЙТЕ
• Лицензия MIT
• ИЗМЕНЕНИЕ

wiki.ipfire.org - обезвоженный

Новое дополнение к Core Update 125.

Dehydrated - это клиент для подписи сертификатов с сервером Let’s Encrypt, реализованный в виде относительно простого bash-скрипта.

Он использует утилиту openssl для всего, что связано с фактической обработкой ключей и сертификатов, поэтому вам необходимо установить ее.

Текущие характеристики:

• Подписание списка доменов
• Подписание CSR
• Продление, если срок действия сертификата скоро истечет или SAN (поддомены) изменены
• Отзыв сертификата

Установка

Dehydrated можно установить через веб-интерфейс Pakfire или через консоль:

 pakfire install обезвоженный
 

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

Обезвоженный файл конфигурации находится по адресу / etc / dehydrated / config .

 [root @ ipfire] # cat / etc / dehydrated / config
############################################### ######
# Это основной файл конфигурации для обезвоженного #
# #
# Этот файл ищется в следующих местах: #
# $ SCRIPTDIR / config (рядом с этим скриптом) #
# / usr / local / etc / dehydrated / config #
# / и т. д. / обезвоженный / config #
# $ {PWD} / config (в текущем рабочем каталоге) #
# #
# Значения по умолчанию этой конфигурации в комментариях #
########################################################################## ######

# Какому пользователю следует работать с обезвоживанием? Это будет неявно применяться при запуске от имени пользователя root.
# DEHYDRATED_USER =.. .
 

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

Нет веб-интерфейса для этого дополнения. Чтобы запустить этот аддон, откройте клиентскую консоль или терминал и получите доступ к IPFire через SSH.

Чтобы получить список возможных команд и параметров:
обезвоженный

Результат выглядит примерно так:

 Использование: / usr / bin / dehydrated [-h] [команда [аргумент]] [параметр [аргумент]] [параметр [аргумент]] ...
 Команда по умолчанию: help
 Команды:
 --version (-v) Распечатать информацию о версии
 --register Зарегистрировать ключ учетной записи
 --account Обновить контактную информацию аккаунта
 --cron (-c) Подписывать / обновлять несуществующие / измененные / истекающие сертификаты.
No related posts.