Поставив и настроив комьюнити версию этого пакета я столкнулся с тем что нет официальных рекомендаций как сгенерировать и запустить работу этого комплекса по защищенному протоколу используя сертификат от Letsencrypt. Этот короткий туториал поможет вам получить сертификат в течении 5-10 минут без сложных телодвижений.

Итак, поехали по шагам.

Я все делал на системе Ubuntu 18.04 запущенной в режиме ВМ на хост машине Proxmox. Данная ВМ была не единой в пуле этого хоста потому, если кому то понадобится, могу дать свой конфиг работающего решения для реверс прокси HAPROXY

Остановим все контейнеры одной командой docker stop $(docker ps -a -q)

Удалим из системы certbot (если он у вас есть, хотя если вы ставите Onlyoffice на чистую систему его там быть не должно в принципе)

Зайдем на официальный сайт https://certbot.eff.org/ и в выпадающем меню выставим нужные параметры как на скриншоте:

3.1 Кому лень или он не разобрался переходим сразу на готовый линк https://certbot.eff.org/lets-encrypt/ubuntubionic-other Выполняем инструкции с шага 1 по шаг 7 на этой странице. Напомню, в процессе по ссылке - вы должны будете установить пакет snapd, без него не заработает. Просто сделайте и все будет работать без лишних слов.

Запустим в консоли от рута certbot certonly standalone sitename.ru (вместо sitename.ru укажите тот домен на котором будет виден из интернета ваш офисный сервер)

4.1 Если все пройдет Ок - вы получите сообщение что сертификаты сгенерированы и лежат на вашем сервере по адресу: /etc/letsencrypt/live/sitename.ru/fullchain.pem /etc/letsencrypt/live/sitename.ru/privkey.pem

4.2 Далее, переименуем и перенесем в нужный каталог полученные сертификаты

cp /etc/letsencrypt/live/sitename.ru/fullchain.pem app/onlyoffice/CommunityServer/data/certs/onlyoffice.crt

cp /etc/letsencrypt/live/sitename.ru/privkey.pem /app/onlyoffice/CommunityServer/data/certs/onlyoffice.key

Перезагрузим сервер с офисом командой shutdown -r now Так будет надежней и наверняка все сервисы запустятся сами, т.к. сам пакет весьма большой и завязан на связанные между собой сервисы лучше его перезапустить целиком а не стартовать докер контейнеры по одному, так меньше шансов что какой то не запустился.

В принципе всё. Теперь зайдя по адресу sitename.ru вы должны попасть на корректно работающий портал документооборота.

На последок крайне желательно зайти в админку офиса и проверить:

Система подцепила ваш домен:

В настройках вы прописали доменное имя sitename.ru - в противном случае в письмах этого пакета будет некорректный адрес типа https://iuyhgi8798ygiknqwq - такой адрес или вымышленный или присваивается по имени докер контейнера - таким образом ни зайти на сайт, ни скачать документов - ничего. Вот такой вот капризный пакет.

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

На этом всё, позвольте откланяться.

Acme.sh - скрипт, позволяющий без особых проблем получать let's encrypt сертификаты очень разными способами. В данной статье я разберу как получать сертификаты через DNS api, но этим уже никого не удивишь, поэтому расскажу про метод DNS alias, он свежий (всего 3 года) и интересный. А так же про автоматизацию на Ansible и немного про мониторинг сертификатов.

Видеоверсия

Режимы acme.sh получения сертификатов прямо на целевом сервере

• Webroot

• Nginx\Apache

• Stanalone

Режимы хорошие и удобные, когда у вас один - два сервера и можно просто на каждый установить acme.sh. Когда количество серверов, которым нужно TLS, переваливает за десяток, удобнее начать использовать wilcard сертификаты и выделить отдельный сервер для получения и распространения сертификата\ов. Получить wildcard сертификат можно только через подтверждение владения DNS зоной. DNS режимов несколько:

• DNS manual

• DNS API

• DNS alias

Все примеры буду показывать на моём личном домене и установленном локально acme.sh.

DNS manual mode

Manual режим работает супер просто. Запускаем acme.sh с флагом --dns

acme.sh --issue --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please

koala@x220:~$ acme.sh --issue --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please[Ср мая  5 14:52:29 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Ср мая  5 14:52:29 MSK 2021] Creating domain key[Ср мая  5 14:52:29 MSK 2021] The domain key is here: /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key[Ср мая  5 14:52:29 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 14:52:29 MSK 2021] Getting domain auth token for each domain[Ср мая  5 14:52:32 MSK 2021] Getting webroot for domain='*.itdog.info'[Ср мая  5 14:52:32 MSK 2021] Add the following TXT record:[Ср мая  5 14:52:32 MSK 2021] Domain: '_acme-challenge.itdog.info'[Ср мая  5 14:52:32 MSK 2021] TXT value: 'QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8'[Ср мая  5 14:52:32 MSK 2021] Please be aware that you prepend _acme-challenge. before your domain[Ср мая  5 14:52:32 MSK 2021] so the resulting subdomain will be: _acme-challenge.itdog.info[Ср мая  5 14:52:32 MSK 2021] Please add the TXT records to the domains, and re-run with --renew.[Ср мая  5 14:52:32 MSK 2021] Please add '--debug' or '--log' to check more details.[Ср мая  5 14:52:32 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

--issue - запрос на получение

--dns без аргумента - режим ручного DNS

--yes-I-know-dns-manual-mode-enough-go-ahead-please - интересное решение проблемы, когда люди не понимают что такое ручной режим

Он выдаёт TXT запись, которую нам необходимо добавить в наш dns хостинг, в данном случае это _acme-challenge.itdog.info TXT QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8

Ручной он потому что, мы вручную добавляем эту запись.

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

После добавления записи проверяем начала ли она резолвится на гугловом dns

koala@x220:~$ dig -t txt _acme-challenge.itdog.info @8.8.8.8; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> -t txt _acme-challenge.itdog.info @8.8.8.8;; ANSWER SECTION:_acme-challenge.itdog.info. 1798 IN    TXT    "QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8"

Она резолвится, а значит можно получать сертификат

koala@x220:~$ acme.sh --renew --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please[Ср мая  5 14:58:08 MSK 2021] Renew: '*.itdog.info'[Ср мая  5 14:58:09 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Ср мая  5 14:58:09 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 14:58:09 MSK 2021] Getting domain auth token for each domain[Ср мая  5 14:58:09 MSK 2021] Verifying: *.itdog.info[Ср мая  5 14:58:13 MSK 2021] Success[Ср мая  5 14:58:13 MSK 2021] Verify finished, start to sign.[Ср мая  5 14:58:13 MSK 2021] Lets finalize the order.[Ср мая  5 14:58:13 MSK 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/121...'[Ср мая  5 14:58:15 MSK 2021] Downloading cert.[Ср мая  5 14:58:15 MSK 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/042...'[Ср мая  5 14:58:16 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Ср мая  5 14:58:16 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Ср мая  5 14:58:16 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Ср мая  5 14:58:16 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Ср мая  5 14:58:16 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer 

После этого TXT запись можно удалить.

Теперь есть ключ и сертификат, который будет действителен 3 месяца. Обновить сертификат можно будет через 2 месяца, let's enctypt даёт запас времени и если у вас вдруг что-то сломается, будет целый месяц чтобы починить и обновить сертификат.

И да, обновляется только сертификат, ключ остаётся таким, какой был выдан в первый раз. Обратите внимание на даты создания файлов, особенно *.example.com.key

# ls -l --time-style=+%Y-%m-%d \*.example.com/total 28-rw-r--r-- 1 root root 1587 2021-04-15 ca.cer-rw-r--r-- 1 root root 3433 2021-04-15 fullchain.cer-rw-r--r-- 1 root root 1846 2021-04-15 *.example.com.cer-rw-r--r-- 1 root root  719 2021-04-15 *.example.com.conf-rw-r--r-- 1 root root  980 2021-04-15 *.example.com.csr-rw-r--r-- 1 root root  211 2021-04-15 *.example.com.csr.conf-rw-r--r-- 1 root root 1675 2019-04-10 *.example.com.key

Хороший режим для одного раза или для понимания как работает подтверждение, но на постоянке каждые 2 месяца вручную обновлять TXT записи не серьёзно, поэтому рассматриваем следующий режим.

DNS API mode

Как это работает? Принцип действия тот же самый что у manual, только acme.sh сам вносит и удаляет TXT запись с помощью API вашего dns провайдера.

Под DNS хостингом и DNS провайдером я буду иметь в виду сервис, в который вносятся DNS записи. Это может быть и DNS хостинг, который есть почти у каждой компании, торгующей доменами (namecheap, beget итд) или как отдельный сервис за деньги (Amazon Route 53, ClouDNS итд), или же ваш собственный сервис развернутый с помощью BIND, PowerDNS итд.

У каждого DNS провайдера свой не стандартизированный API и их поддержка в acme.sh реализована отдельными скриптами. Список всех поддерживаемых провайдеров находится тут https://github.com/acmesh-official/acme.sh/wiki/dnsapi

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

Работу этого режима покажу на примере хостинга DNS у namecheap.

Для каждого DNS провайдера свои настройки, где-то нужно просто включить API и сгенерировать токен, где-то бывает посложнее, например для namecheap нужно ещё внести IP в allow list. Включаем API и сразу генерируется token, добавляем IP в список.

Теперь на локальной машине нужно настроить доступ к API

export NAMECHEAP_USERNAME="USERNAME"export NAMECHEAP_API_KEY="TOKEN"export NAMECHEAP_SOURCEIP="MY-IP"

Отступление про дополнительные флаги force и test. Будем использовать флаг -f (--force), что бы наши сертификаты генерировались заново, т.к. acme.sh видит уже сгенерированные сертификаты при их наличии не будет заново получать. Можно конечно просто сделать rm -rf ~/.acme.sh/domain/ вместо этого. Так же будем использовать флаг --test, что бы лишний раз не нагружать продакшн сервера let's encrypt. Вот такое сообщение мы получим, если после подтверждения в manual режиме попробуем другой режим.

[Ср мая 5 16:39:31 MSK 2021] *.itdog.info is already verified, skip dns-01.

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

acme.sh --issue --dns dns_namecheap -d *.itdog.info --test

Здесь после --dns мы добавляем имя провайдера.

Запускаем acme.sh

koala@x220:~$ acme.sh --issue --dns dns_namecheap -d *.itdog.info --test[Ср мая  5 16:48:05 MSK 2021] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory[Ср мая  5 16:48:06 MSK 2021] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory[Ср мая  5 16:48:06 MSK 2021] Creating domain key[Ср мая  5 16:48:07 MSK 2021] The domain key is here: /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key[Ср мая  5 16:48:07 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 16:48:07 MSK 2021] Getting domain auth token for each domain[Ср мая  5 16:48:09 MSK 2021] Getting webroot for domain='*.itdog.info'[Ср мая  5 16:48:10 MSK 2021] Adding txt value: nCH4tBWCkSVn76301f2SdJqCAzmtXvzQAB_Ag8hURLo for domain:  _acme-challenge.itdog.info[Ср мая  5 16:48:15 MSK 2021] The txt record is added: Success.[Ср мая  5 16:48:15 MSK 2021] Let's check each DNS record now. Sleep 20 seconds first.[Ср мая  5 16:48:36 MSK 2021] You can use '--dnssleep' to disable public dns checks.[Ср мая  5 16:48:36 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck[Ср мая  5 16:48:36 MSK 2021] Checking itdog.info for _acme-challenge.itdog.info[Ср мая  5 16:48:37 MSK 2021] Domain itdog.info '_acme-challenge.itdog.info' success.[Ср мая  5 16:48:37 MSK 2021] All success, let's return[Ср мая  5 16:48:37 MSK 2021] Verifying: *.itdog.info[Ср мая  5 16:48:41 MSK 2021] Success[Ср мая  5 16:48:41 MSK 2021] Removing DNS records.[Ср мая  5 16:48:41 MSK 2021] Removing txt: nCH4tBWCkSVn76301f2SdJqCAzmtXvzQAB_Ag8hURLo for domain: _acme-challenge.itdog.info[Ср мая  5 16:48:46 MSK 2021] Removed: Success[Ср мая  5 16:48:46 MSK 2021] Verify finished, start to sign.[Ср мая  5 16:48:46 MSK 2021] Lets finalize the order.[Ср мая  5 16:48:46 MSK 2021] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/193...'[Ср мая  5 16:48:48 MSK 2021] Downloading cert.[Ср мая  5 16:48:48 MSK 2021] Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/fa62...'[Ср мая  5 16:48:49 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Ср мая  5 16:48:49 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Ср мая  5 16:48:49 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Ср мая  5 16:48:49 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Ср мая  5 16:48:49 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer

В логе прям видно, что acme.sh добавляет TXT запись, ждёт немного, проверяет запись через доверенные DNS сервера, удаляет запись и скачивает сертификаты с ключом.

После первого запуска через API, acme.sh заносит env переменные c доступами к API себе в файл ~/.acme.sh/account.conf и вам не нужно каждый раз их экспортировать.

Отлично, получение автоматизировали, всё вроде классно. Но у этого метода есть свои недостатки:

• Если никто не написал скрипта для вашего провайдера\сервиса, то нужно либо писать, либо переезжать на другой провайдер

• А есть ли у вашего провайдера API?

• Поразмышляем немного об безопасности. Вот у меня в "открытую" лежит полный доступ к редактированию моего домена, если он каким-то образом попадёт в чужие руки, эти руки могут сделать что угодно. Эту проблему можно решить ограничим доступа в API, например по токену можно только добавлять\удалять txt записи _acme-challenge. Есть ли такая возможность у вашего провайдера? Я не встречал такого, наверное есть у какого-нибудь AWS конечно. Обычно уже хорошо если есть API, а токен один и даёт полный доступ

• У вас несколько доменов на разных провайдерах (сочувствую). Тут конечно можно настроить каждое API и сделать для каждого провайдера отдельный запуск acme.sh со своими переменными, но мне кажется это не очень удобным. Тем более если у одного из них отсутствует API или скрипт

• Кто-то просто не любит, что бы в DNS постоянно лазил какой-то скрипт и что-то добавлял\удалял

DNS aliase mode

Это модернизированный режим DNS API.

Идея такая: Есть технический домен, через добавления TXT записей на котором мы подтверждаем владение основным доменом. т.е. acme.sh смотрит CNAME запись у основного домена, видит "перенаправление" на технический домен и идёт к нему проверять TXT запись. А дальше всё как в режиме DNS API.

Разберём последовательно. Для демонстрации я купил домен tech-domain.club, он выступает в качестве технического домена. В моём примере основной домен itdog.info располагается на namecheap, а техничский tech-domain.club я делегирую на Hetzner DNS, таким образом операции с записями будут производиться через API Hetzner'a.

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

_acme-challenge CNAME _acme-challenge.tech-domain.club

Для провайдера с техническим доменом мы настраиваем доступ к API.

Экспортируем токен Hetzner export HETZNER_Token="TOKEN"

Команда выглядит так (-f и --test опять же для примера)

acme.sh --issue -d *.itdog.info --challenge-alias tech-domain.club --dns dns_hetzner -f --test

koala@x220:~$ acme.sh --issue -d *.itdog.info -d itdog.info --challenge-alias tech-domain.club --dns dns_hetzner -f --test[Пт мая  7 13:40:11 MSK 2021] Domains have changed.[Пт мая  7 13:40:11 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Пт мая  7 13:40:11 MSK 2021] Multi domain='DNS:*.itdog.info,DNS:itdog.info'[Пт мая  7 13:40:11 MSK 2021] Getting domain auth token for each domain[Пт мая  7 13:40:15 MSK 2021] Getting webroot for domain='*.itdog.info'[Пт мая  7 13:40:15 MSK 2021] Getting webroot for domain='itdog.info'[Пт мая  7 13:40:15 MSK 2021] Adding txt value: Zlrij9n4y5QXfH6yx_PBn45bgmIcT70-JuW2rIUa6lc for domain:  _acme-challenge.tech-domain.club[Пт мая  7 13:40:16 MSK 2021] Adding record[Пт мая  7 13:40:17 MSK 2021] Record added, OK[Пт мая  7 13:40:20 MSK 2021] The txt record is added: Success.[Пт мая  7 13:40:20 MSK 2021] Let's check each DNS record now. Sleep 20 seconds first.[Пт мая  7 13:40:41 MSK 2021] You can use '--dnssleep' to disable public dns checks.[Пт мая  7 13:40:41 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck[Пт мая  7 13:40:41 MSK 2021] Checking itdog.info for _acme-challenge.tech-domain.club[Пт мая  7 13:40:42 MSK 2021] Domain itdog.info '_acme-challenge.tech-domain.club' success.[Пт мая  7 13:40:42 MSK 2021] All success, let's return[Пт мая  7 13:40:42 MSK 2021] *.itdog.info is already verified, skip dns-01.[Пт мая  7 13:40:42 MSK 2021] Verifying: itdog.info[Пт мая  7 13:40:46 MSK 2021] Success[Пт мая  7 13:40:46 MSK 2021] Removing DNS records.[Пт мая  7 13:40:46 MSK 2021] Removing txt: Zlrij9n4y5QXfH6yx_PBn45bgmIcT70-JuW2rIUa6lc for domain: _acme-challenge.tech-domain.club[Пт мая  7 13:40:50 MSK 2021] Record deleted[Пт мая  7 13:40:50 MSK 2021] Removed: Success[Пт мая  7 13:40:50 MSK 2021] Verify finished, start to sign.[Пт мая  7 13:40:50 MSK 2021] Lets finalize the order.[Пт мая  7 13:40:50 MSK 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/121...'[Пт мая  7 13:40:52 MSK 2021] Downloading cert.[Пт мая  7 13:40:52 MSK 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/04e...'[Пт мая  7 13:40:53 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Пт мая  7 13:40:53 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Пт мая  7 13:40:53 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Пт мая  7 13:40:53 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Пт мая  7 13:40:53 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer 

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

Кстати, если вам нужно в одном файле иметь несколько сертификатов, например и itdog.info и wildcard *.itdog.info, то просто перечислите их с -d, например

acme.sh --issue --challenge-alias tech-domain.club --dns hetzner -d *.itdog.info -d itdog.info

Это правило действует и для других методов.

И так, что даёт нам этот режим:

• Если у вашего провайдера нет API или лень писать скрипт, возьмите технический домен, делегируйте его на сервис, который поддерживает acme.sh

• Если у вашего провайдера нет настройки прав для доступа через API, то технический домен тоже выручает. В случае, если наш token утечёт, у злоумышленника будет доступ только к вашему техническому домену, и если вы его используете только для acme.sh, то максимум что сможет сделать злоумышленник - получить ключ и сертификат для вашего домена. Это тоже неприятно и можно использовать, но это совершенно другой уровень угрозы, по сравнению с полным доступом к доменной зоне

• В ситуации с кучей доменов на одном или нескольких провайдерах, жизнь так же становится проще, когда все они просто имеют CNAME запись

Есть так же режим domain-alias, он даёт возможность использовать не _acme-challenge запись, а кастомную, подробности можно прочитать в документации

Автоматизация получения и распространения сертификатов

Мы получили сертификаты, лежат они у нас красиво в ~/.acme.sh и никак не используются. Надо каким-то образом их распространять на сервера. Далее расскажу, как я это делаю с помощью ansible. Ansible используется и для получения\обновления и для распространения. Сразу предупреждаю, мои плейбуки простые как три копейки и заточены под определенную инфраструктуру. Playbooks, hosts на github.

Мой сервер с ansible, уже имеет доступ ко всем необходимым серверам, на нём установлен acme.sh и реализовано два плейбука, на получение и распространение. Кстати, не забудьте закомментировать acme.sh в crontab, что бы не было лишних запросов и путаницы.

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

В vars указывается только технический домен, эта переменная используется несколько раз. Токен от API вынесен в отдельный vars файл, что бы хранить его в зашифрованном виде в git. Task "Date and time" нужен для логирования, что бы понимать когда именно что-то пошло не так. Следующие два плейбука это простой shell, отличаются друг от друга количеством доменов в одном файле сертификата. Всем доменам, которым не нужно сочетать в себе обычный и wildcard домен, идут списком в loop.

Домены, которые должны подходить как для обычного, так и для wildcard идут по втором taks, тоже с помощью loop. Если вам нужно например wilcard вида *.*.itdog.info, то просто добавьте ещё один -d и ещё один subkey в item. Опция ignore_errors необходима, потому что exit code 0 будет только 6 раз за год при обновлении сертификата, в остальное время будут сообщения о том, что сертификат не нужно обновлять, для ansible это ошибка на которой он будет останавливаться.

Для чего плейбук на получение? Ведь в acme.sh и так уже всё настроено!

В одном плейбуке мы собираем всю нашу конфигурацию, доступы и все домены, которым необходим TLS, как минимум, это удобно - не надо копаться конфигах acme.sh. В случае изменения, например, токена, мы просто редактируем его в vars_files, а если нужно добавить ещё один домен\подомен, мы просто добавляем его в loop. Ну и в случае переноса сервера, не нужно переносить ~/.acme.sh, только плейбуки с vars_files взять из git.

Playbook для распространения сертификатов

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

Три типа серверов из моей инфраструктуры:

• tls-hosts - Обычный nginx установленный как пакет из стандартного репозитория

• tls-hosts-docker - Веб проект с тем же nginx, но уже в docker

• tls-hosts-docker-rename - Сторонний продукт, в который надо подкладывать сертификат и ключ с определённым именем в определённую директорию (например Harbor, Zabbix)

Первый кейс самый простой, мы сами пишем конфигурацию nginx и можем куда угодно положить сертификаты и как угодно назвать их. При обновлении сертификата, требуется сделать nginx -s reload

Во втором случае всё плюс-минус так же, но уже нужно сделать docker exec project-nginx -s reolad, т.е. уже другой handler.

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

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

nginx.itdog.info tls_path=/etc/letsencrypt/*.itdog.info/ DOMAIN=*.itdog.info

Для случаев, когда доменов на сервере несколько, делается два хоста с разными именами и одинаковым ansible_host (Совет, как сделать лучше, приветствуется).

nginx.example.com-1 ansible_host=nginx.example.com tls_path=/etc/letsencrypt/*.example.com/ DOMAIN=example.comnginx.example.com-2 ansible_host=nginx.example.com tls_path=/etc/letsencrypt/*.example.org/ DOMAIN=example.org

Для каждого типа серверов создана своя группа в hosts. Для каждой группы свои немного отличающиеся друг от друга tasks. Для tls-hosts-docker так же добавлена переменная с именем контейнера nginx. А для tls-hosts-docker-rename добавлена переменная, в которой задаётся конечное имя сертификата и ключа.

docker-zabbix.itdog.info tls_path=/root/docker-zabbix/zbx_env/etc/ssl/nginx/ DOMAIN=*.itdog.info CONTAINER=docker-zabbix_zabbix-web-nginx-pgsql_1 cert_name=ssl.crt key_name=ssl.key

Для nginx нужен fullchain и domain.key - копируются только они. Если файлы различаются, происходит копирование и срабатывает handler nginx -s reload. Так же есть проверка, перед тем как зарелоудить nginx, что это файл. У меня один раз был случай, в самом начале пользования acme.sh, скрипт вместо файла с сертификатом создал директорию. Прямо как traefik 1.7 создаёт acme.json директорию, вместо файла. Поэтому я сделал простую проверку. В идеале нужно делать проверку, что сертификат валидный и не просроченный, но для этого требуется иметь на каждом хосте python-pyOpenSSL.

Crontab

23 3 * * * /usr/bin/ansible-playbook /etc/ansible/playbook-get-tls.yml -v >> /var/log/get-tls.log23 4 * * * /usr/bin/ansible-playbook /etc/ansible/playbook-copy-tls.yml -v >> /var/log/copy-tls.log

Можно без проблем вызывать их каждый день, let's encrypt будет вежливо говорить, что пока не нужно обновляться. А когда придёт срок, сертификаты будут обновлены.

Мониторинг сертификатов

Надо следить за тем, что бы сертификаты на доменах обновлялись. Можно мониторить логи получения и распространения, и когда что-то идёт не так - кидать warning в системе мониторинга. Но мы пойдём с одной стороны на минималках, с другой более основательно и ещё помимо этого захватим другие исталяции, например с traefik, который живёт там сам по себе.

Я использую zabbix и скрипт от @selivanov_pavel

Проверим с его помощью мой домен локально

koala@x220 ~/t/acme.sh-test> ./ssl_cert_check.sh expire itdog.info 44341

41 день сертификат на itdog.info будет актуален. Сертификат в let's encrypt обновляется за 30 дней до протухания. А значит, например, если ему осталось жить 10 дней, значит что-то пошло не так и надо идти смотреть.

Темплейт состоит из одного item и одного trigger. Теплейт есть так же на github

ssl_cert_check.sh["expire","{HOST.NAME}","{$TLS_PORT}"]

В item две переменных, первая HOST.NAME берёт имя хоста, предполагается что у нас хост назван по доменному имени. Переменная $TLS_PORT по дефолту 443, но если нужно проверять на нестандартном порту, то записываем значение порта в macros.

Триггер тоже супер простой

{Check tls expire:ssl_cert_check.sh["expire","{HOST.NAME}","{$TLS_PORT}"].last()}<=10

Если полученное значение меньше 10ти - аллерт. Таким образом, мы узнаем если у нас начнут протухать сертификаты и будет 10 дней на починку.

Нормально работает?

Да, acme.sh + DNS API + ansible у меня крутится два года. acme.sh + DNS Alias + ansible крутится пол года. Проблемы возникали только, когда при тестировании доменов забыл отключить crontab и он принёс staging сертификат на прод. Такая проблема решается проверкой на валидность.

Да, в идеале, ansible должен проверять перед копированием, что сертификат валидный и не просроченный. А система мониторинга проверять, помимо expire, валидность сертификатов.

Предисловие

Для написания этой статьи ушло очень много сил и времени. Я натыкался на множество инструкций, как на английском, так и на русском языках, но как я понял, - они все были клонами оригинальной статьи на Digital Ocean. Спросите вы, почему я так считаю, а все потому, что все ошибки и неточности передаются с одного ресурса на другой без всяких изменений.

Подготовка

У нас есть обычный VPS c ОС Ubuntu, и мы уже написали в PyCharm или в блокноте свой сайт на Django и его осталось всего лишь опубликовать, привязать домен, установить сертификат и в путь.

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

apt get updateapt get-install nginx

Я решил хранить файлы сайта в каталоге: /var/www/. В данном случае перемещаемся в каталогcd /var/www/и создаем новый каталогmkdir geekheroи получаем такой путь: /var/www/geekhero/

Переходим в новый каталог geekhero:cd geekheroи создаем виртуальное окружение:python3 -m venv geekhero_env

Активируем виртуальное окружение:source geekhero_env/bin/activateи устанавливаем в него Django: pip install Django и сразу же ставим pip install gunicorn

Создаем проект:django-admin startproject ghproj

Далее нужно произвести все первичные миграции; для этого прописываем:python manage.py makemigrations , затемpython manage.py migrate .

После этого создаем административную учетную запись: python manage.py createsuperuser и следуем инструкции.

Далее уже создаем applications, но так как вы читаете данную статью, то вы уже умеете все это делать.

Заходим в Settings.py и прописываем, если отсутствует:
import os в заголовке, остальное в самом низу текстового файла:

STATIC_URL = '/static/'STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

НастройкаGunicorn

Идем в каталог /etc/systemd/system/ и создаем два файла: gunicorn.service и gunicon.socket:

Содержимое файла gunicorn.service:

[Unit]Description=gunicorn daemonRequires=gunicorn.socketAfter=network.target[Service]User=rootWorkingDirectory=/var/www/geekhero #путь до каталога с файлом manage.pyExecStart=/var/www/geekhero/geekhero_env/bin/gunicorn --workers 5 --bind unix:/run/gunicorn.sock ghproj.wsgi:application#путь до файла gunicorn в виртуальном окружении[Install]WantedBy=multi-user.target

Содержимое файла gunicorn.socket:

[Unit]Description=gunicorn socket[Socket]ListenStream=/run/gunicorn.sock[Install]WantedBy=sockets.target

Для проверки файла gunicorn.service на наличие ошибок:

systemd-analyze verify gunicorn.service

Настройка NGINX

Далее идем в каталог: /etc/nginx/sites-available/ и создаем файл geekhero (название вашего сайта) без расширения:

server {    listen 80;    server_name example.com;        location = /favicon.ico { access_log off; log_not_found off; }    location /static/ {        root /var/www/geekhero;           #путь до static каталога    }        location /media/ {        root /var/www/geekhero;           #путь до media каталога    }        location / {        include proxy_params;        proxy_pass http://unix:/run/gunicorn.sock;    }}

Для того, чтобы создать символическую ссылку на файл в каталоге/etc/nginx/site-enabled/необходимо ввести следующую команду:

sudo ln -s /etc/nginx/sites-available/geekhero /etc/nginx/sites-enabled/

При любых изменениях оригинального файла, ярлык из sites-enabled нужно удалять и пересоздавать заново командой выше или выполнять команду:sudo systemctl restart nginx

Финальный этап

Для проверки конфигурации nginx нужно ввести команду:

sudo nginx -t

sudo nginx -tДалее запускаем службу gunicorn и создаем socket:

sudo systemctl enable gunicornsudo systemctl start gunicorn

Для отключения выполняем команды:

sudo systemctl disable gunicorn
sudo systemctl stop gunicorn

Также, эти обе команды пригодятся, если вы будете вносить какие-либо изменения в HTML или python файлы, чтобы обновить свой сайт, но помните, что, если вносите изменения в модели, то обязательно нужно сделать python manage.pymakemigrations <app> и migrate <app> из каталога с проектом.

Для первичного запуска / полной остановки сервиса Gunicorn:
service gunicorn start / service gunicorn stop

Чтобы посмотреть статус запущенного сервиса нужно ввести:

sudo systemctl status gunicornилиsudo journalctl -u gunicorn.socket(с последней командой правильный вывод такой: мар 05 16:40:19 byfe systemd[1]: Listening on gunicorn socket. )

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

file /run/gunicorn.sock

Такой вывод считается правильным:/run/gunicorn.sock: socket

Если внес какие-либо изменения в файл gunicorn.service или .socket, необходимо выполнить команду:

systemctl daemon-reload

Если все нормально сработало, то можем запустить nginx:

sudo service nginx start

Получаем сертификат SSL для домена

Установим certbot от Let's Encrypt:sudo apt-get install certbot python-certbot-nginx

Произведем первичную настройку certbot:sudo certbot certonly --nginx

И наконец-то автоматически поправим конфигурацию nginx:sudo certbot install --nginx

Осталось только перезапустить сервис nginx:sudo systemctl restart nginx

Итог

В рамках этой статьи мы разобрали как вывести наш сайт в production, установив Django, Gunicorn, nginx и даже certbot от Let's Encrypt.

Так получилось, что я оказался в некой группе лиц с некими общими идеями и желаниями. Так получилось, что живем мы в 21-ом веке и учитывая наше географическое положение мы обзавелись какими-то серверами, на них какие-то сайтики, ну скажем так, все для личного пользования. Время не стоит на месте и современные браузеры (там всякие хромы, эджи и с логотипом в виде жопы в стрингах) как-то очень критично относятся к сертификатам SSL выпущенными центром сертификации AD. И тут, как назло, при продлении DNS мне впарили SSL сертификат от известного бренда, и в какой-то день я решил его прикрутить

Как я докатился до тех.поддержки.

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

Ну дальше по инструкции:

Консоль IIS -> Сертификаты-> Импорт-> Тыкаем в файлик-> Сертификат в списке-> Привязки сайтика-> Выбор сертификата

Твою мышь а где сертификат??? Ну был же возвращаемся в раздел сертификатов web-сервера А нету Хорошо Повторяем процесс:

Консоль IIS -> Сертификаты-> Импорт-> Тыкаем в файлик-> Сертификат в списке-> Привязки сайтика-> Выбор сертификата

...

<% Длинная, нецензурная, не переводимая на другие языки, брань, включая угрозы сексуального насилия в извращенной форме в сторону прабабушки Била %>

Да где ОН??? Хорошо, пойдем другим путем :

mmc-> Добавляем оснастку Сертификаты -> Локальный компьютер -> Раздел Личные

Ох ты-ж!!!! вот и наш сертификатик Опять консоль IIS ну нету в списке этого сертификата НЕТУ!!!!

Ладно пропустим период принятия что я все-таки дебил, и руки не совсем ровные и не из того места

ОК, пойдем в гугл, он же вумный, подскажет че ни будь спустя минут 15-20 приходит осознание что писать запросы гуглу я тоже не научился

Шо делать???? О!!! я же за это деньгу платил, там целый сайт, там вумные, там же поддержка есть, прям кнопочка с вопросиком на каждой странице

Экшен

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

Тук тук, это мы... тупые парни... есть кто живой?

Видно, бота тренировали, и он сразу ретировался, вроде как девочка появилась (ну имя женское плюс аватарка с огромной и дикой кошкой, пума кажется, ну в общем то пофигу, я уже старый), ну объясняю ситуацию, мол импортируем, а сертификат пропадает из IIS, хотя в личных он есть даже скриншотики закинул

Ну в общем, через пару минут, девица заряжает

это не в моей компетенции, обратитесь к старшим товарищам, через заявку помощи

Ну ОК, ага, значит вопрос не тупой, значит я не совсем дебил радует

Кнопочка с вопросиком -> кнопочка Написать заявку -> Излагаем проблему, прилепляем скриншотики -> ждем 

Через пару литров кофе приходит ответ:

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

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

Подтягиваем тяжелую артиллерию

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

Тук тук это мы тупые парни, есть минутка?

Получаем отклик установки соединения че надо?, дальше копипастю описание ситуации, добрасываю скриншотики Спустя 30 секунд надписи *** печатает получаю сообщение:

Ты @лан!!! Ты прикручиваешь *.crt в котором нет приватного ключа, как ты надеешься работать??? Учи мат.часть, ключевое слово OpenSSL.exe тебе в помощь.

В общем послал так послал, но путь указан. Открываем яндекс (ну на гугл я еще обижен), вбиваем вопрос OpenSSL.exe как пользоваться, и понимаем что расхожая фраза чем больше в армии дубов тем крепче наша оборона возникла не на пустом месте(судя по яндексу нас тайга) в общем дополняем инструкцию полученную в начале этого пути инфой об OpenSSL радостно получаем файлик *.PFX который прикручиваем до IIS, и О ЧУДО!!!!!!!!!! все заработало.

Заключение

Картинка в начале смешная, а ситуация страшная Да и аффтор картинок молодец, я хрен знает кто это, но жгет от души

Да и я понимаю, что за такие тексты, и выпады в сторону известных конторок банят навсегда, вину осознал и готов понести наказание.

Привет, Хабр. В рамках курса Network engineer подготовили авторскую статью.

Также приглашаем всех желающих смотреть открытый вебинар на тему NAT не Firewall. На нем участники вместе с экспертом рассмотрят NAT и его использование, разберут, почему NAT != firewall. Дополнительно рассмотрят различные виды конфигураций для разных ситуаций.

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

Проблематика и история

Разберемся немного с проблематикой и терминологией. На сегодняшний день наиболее популярными технологиями, которые применяются для шифрования данных, передаваемых по сети, являются SSL и TLS. Последняя сейчас является стандартом дефакто для взаимодействия по протоколу HTTPS. Кстати, именно в расшифровке этого протокола и будет заключаться практическая часть данной статьи. Для понимания процесса расшифровки данных мы должны знать такие понятия как:

• Симметричная криптография

• Ассиметричная криптография

• Сертификат

• Хранилище сертификатов

• HSTS или Strict Transport Security технология, которая включена в современных браузерах для контроля над обязательным использованием HTTPS для взаимодействия с сервером.

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

Практика

Практику будем проводить с использованием виртуальной лаборатории. Состав лаборатории:

• Virtual Box;

• Windows 8.1;

• Ubuntu Server 20.04

Также для тестирования способов расшифровки трафика будем использовать устройство iPhonе SE.

Все машины должны быть подключены к сети "NAT Network". Именно этот тип подключения позволяет моделировать близкую к реальной топологию сети. В схеме есть хосты, которые могут взаимодействовать друг с другом, и есть хост, который используется как точка доступа в сеть Интернет. Приступим к практике.

Расшифровка трафика с использованием SQUID

Squid программное обеспечение, которая эмулирует функцию кэширующего сервера. Может быть использована для распределения нагрузки и логирования действий пользователей по протоколу HTTP в сети, кстати, и с HTTPS это ПО работать тоже умеет. Воспользуемся этой его функцией. К сожалению, использовать squid из репозитория не получится, необходимо собрать его самостоятельно:

```sh wget http://www.squid-cache.org/Versions/v4/squid-4.5.tar.gztar -xvzf squid-4.5.tar.gzcd squid-4.5./configure --with-openssl --enable-ssl-crtd --prefix=/usr/local/squidmakemake allmake install```

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

```sh cd /etc/squidmkdir ssl_certchown squid:squid -R ssl_certchmod 700 ssl_certcd ssl_certopenssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -extensions v3_ca -keyout myCA.pem  -out myCA.pemopenssl x509 -in myCA.pem -outform DER -out myCA.der```

Файл сертификата myCA.der можно использовать для браузера. Устанавливаем его в локальное хранилище и прописываем в качестве прокси сервер squid.

Настроим ссылку на вновь скомпилированный файл squid:

```shln -s /usr/local/squid/sbin/squid /usr/local/bin/squid```

Проинициализируем директорию для кэша:

```/usr/local/squid/libexec/security_file_certgen -c -s /var/lib/ssl_db -M 4MBchown squid:squid -R /var/lib/ssl_db```

Модифицируем конфиг:

```shnano /usr/local/squid/etc/squid.conf```

Должен получить следующий листинг:

```shacl SSL_ports port 443acl CONNECT method CONNECTacl manager proto cache_objecthttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow localhost managerhttp_access deny managerhttp_access allow localnethttp_access allow localhosthttp_access deny allhttp_port 3128cache_dir ufs /usr/local/squid/var/cache/squid 100 16 256coredump_dir /usr/local/squid/var/cache/squidrefresh_pattern ^ftp:144020%10080refresh_pattern ^gopher:14400%1440refresh_pattern -i (/cgi-bin/|\?) 00%0refresh_pattern -i \.(gif|png|jpg|jpeg|ico)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.(iso|avi|wav|mp3|mp4|mpeg|swf|flv|x-flv)$ 43200 90% 432000 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.(deb|rpm|exe|zip|tar|tgz|ram|rar|bin|ppt|doc|tiff)$ 10080 90% 43200 override-expire ignore-no-cache ignore-no-store ignore-privaterefresh_pattern -i \.index.(html|htm)$ 0 40% 10080refresh_pattern -i \.(html|htm|css|js)$ 1440 40% 40320refresh_pattern -i youtube.com/.* 10080 90% 43200refresh_pattern (/cgi-bin/|\?) 0 0% 0refresh_pattern .020%4320http_port 3128 ssl-bump \  cert=/etc/squid/ssl_cert/myCA.pem \  generate-host-certificates=on dynamic_cert_mem_cache_size=4MBsslcrtd_program /usr/local/squid/libexec/security_file_certgen -s /var/lib/ssl_db -M 4MBacl step1 at_step SslBump1ssl_bump peek allssl_bump stare allssl_bump bump allcache allow allaccess_log stdio:/usr/local/squid/var/logs/access.log combinedcache_store_log stdio:/usr/local/squid/var/logs/store.logcache_log stdio:/usr/local/squid/var/logs/cache.log```

Запускаем squid:

```shsquid -d 10 && tail -f /usr/local/squid/var/logs/access.log```

Результат проксирования:

Расшифровка взаимодействия с использованием CharlesProxy

В этом эксперименте будем использовать настоящую WiFi сеть с подключенным к нему устройством iPhone SE. Для расшифровки сетевого взаимодействия будем использовать специализированные программные продукты. Например charlesProxy. Продукт платный, но предоставляет бесплатный период использования. После запуска нужно выбрать опцию "Proxy > Start SSL Proxying":

После этого станет доступна ссылка на корневой сертификат для браузера или другого сетевого устройства. Установим сертификат на устройство:

После установки в в качестве доверенного в браузере или на устройстве, можно увидеть следующий результат:

Вывод

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

Узнать подробнее о курсе Network engineer.

Смотреть открытый вебинар на тему NAT не Firewall.