🥇На пътя към автоматизацията на издаването на SSL

Доста често трябва да работим с SSL сертификати. Нека си припомним процеса на създаване и инсталиране на сертификат (в общ случай за повечето).

Намери доставчик (сайт, на който можем да купим SSL).
Сгенерирай CSR.
Изпрати го на доставчика.
Потвърди собствеността на домейна.
Получавай сертификата.
Преобразувай сертификата в необходимия формат (по желание). Например, от pem в PKCS #12.
Инсталирай сертификата на уеб сървър.

Относително бързо, не сложно и ясно. Този вариант е напълно подходящ, ако имаме максимум десет проекта. А ако са повече и имат минимум по три среди? Класическото dev — staging — production. В този случай трябва да се обмисли автоматизация на този процес. Предлагам да се задълбочим в проблема и да намерим решение, което в бъдеще минимизира времевите разходи за създаване и поддръжка на сертификатите. В статията ще има анализ на проблема и малко ръководство за повторение.

Предварително ще кажа: основната специализация на нашата компания е .net, а съответно IIS и другите виндови излияния. Затова ACME клиентът и всички действия за него също ще бъдат описани от гледна точка на използването на Windows.

За кого е актуално това и някои входни данни

Компания К от името на автора. URL (за пример): company.tld

Проект X — един от нашите проекти, работейки по който достигнах до извода, че все пак трябва да се стремим към максимална икономия на време при работа с сертификатите. Този проект разполага с четири среди: dev, test, staging и production. Dev и test са от наша страна, staging и production на клиента.

Особеност на проекта е, че той има голямо количество модули, достъпни като поддомейни.

Тоест, имаме следната картина:

Dev
Test
Staging
Production

projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
projectX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld

…
…
…
…

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

За production се използва закупен wildcard сертификат, тук нямаме въпроси. Но той покрива само първото ниво на поддомейна. Следователно, ако имаме сертификат за *.projectX.tld — то за staging.projectX.tld той ще работи, а за module1.staging.projectX.tld вече не. А да купуваме отделен не ми се иска.

И това е само на примера на един проект на една компания. А проектът, разбира се, не е един.

Общите причини за всички, за да се заемат с решаването на този въпрос, изглеждат приблизително така:

Относително скоро Google предложи да се намали максималният срок на действие на SSL сертификатите. С всички произтичащи от това последствия.
Да се улесни процесът на издаване и поддръжка SSL за вътрешни нужди на проектите и на компанията като цяло.
Централизирано съхранение на записи за сертификати, което частично решава проблема с верификацията на домейна чрез DNS и последващото автоматично обновление, както и решава въпроса с доверието на клиента. Въпреки това, повече доверие предизвиква CNAME на сървъра на компанията партньора/изпълнителя, отколкото на външен ресурс.
И накрая, в този случай фразата “по-добре да имаш, отколкото да нямаш” подхожда отлично.

Избор на доставчик на SSL и подготвителни стъпки

От наличните опции за безплатни SSL сертификати бяха разгледани cloudflare и letsencrypt. DNS за това (и някои други проекти) е разположен на cloudflare, но не съм привърженик на използването на техните сертификати. Затова решихме да използваме letsencrypt.
За създаване на wildcard SSL сертификатът трябва да потвърди собствеността върху домейна. Тази процедура предполага създаване на определена DNS запис (TXT или CNAME), с последваща проверка при издаването на сертификата. В Linux има утилита — certbot, която позволява частично (или напълно за някои DNS доставчици) автоматизиране на този процес. За Windows от намерените и проверени варианти на ACME клиентите, спирам на WinACME.

А записът за домейна е създаден, преминаваме към създаването на сертификата:

По пътя към автоматизацията на издаването на SSL

Интересува ни последният изход, а именно — наличните варианти за потвърждаване на собствеността на домейна за издаване на wildcard сертификата:

Създаване на DNS записи ръчно (автоматично обновление не се поддържа)
Създаване на DNS записи с помощта на acme-dns сървър (повече можете да прочетете тук.
Създаване на DNS записи с помощта на собствен скрипт (аналог на приставката на cloudflare за certbot).

На пръв поглед третата точка изглежда напълно подходяща, но ако DNS доставчикът не поддържа тази функционалност? А ние се нуждаем от общ случай. А общият случай — това са CNAME записи, а те всички поддържат. Следователно, спираме на точка 2 и отиваме да настроим своя ACME-DNS сървър.

Настройка на ACME-DNS сървъра и процеса на издаване на сертификата

Например, създадох домейн 2nd.pp.ua и впоследствие ще го използвам.

Задължително изискване за правилната работа на сървъра е създаването на NS и A записи за неговия домейн. Първият неприятен момент, с който се сблъсках, е, че Cloudflare (поне в безплатния режим) не позволява едновременното създаване на NS и A запис за един и същи хост. Не че беше проблем, но в bind това е възможно. Поддръжката отговори, че тяхната панелна система не позволява това. Няма проблем, ще създадем две записи:

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

На този етап хостът ни трябва да резолвира acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

А ето acme.2nd.pp.ua няма да резолвира, тъй като DNS сървърът, който го обслужва, все още не е стартиран.

Записите са създадени, преминаваме към настройката и стартирането на ACME-DNS сървъра. Той ще бъде на ubuntu сървър в docker контейнер, но може да бъде стартиран навсякъде, където има golang. Windows също е подходящ, но все пак предпочитам Linux сървър.

Създаваме необходимите директории и файлове:

$ mkdir config
$ mkdir data
$ touch config/config.cfg

Ще използваме vim, вашия любим текстов редактор, и ще поставим в config.cfg образец конфигурация.

За успешна работа е достатъчно да поправим секциите general и api:

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

Също така, по желание, ще създадем docker-compose файл в основната директория на услугата:

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

Готово. Може да стартираме.

$ docker-compose up -d

На този етап хостът трябва да започне да резолвира acme.2nd.pp.ua, и да се появи 404 на https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

Ако това не се появи — docker logs -f в помощ, за щастие логовете са напълно четливи.

Можем да пристъпим към създаването на сертификат. Отваряме PowerShell с администраторски права и стартираме winacme. Интересуват ни опциите:

M: Създайте нов сертификат (пълни опции)
2: Ръчно въвеждане
2: [dns-01] Създайте проверочни записи с acme-dns (https://github.com/joohoi/acme-dns)
На въпроса за линк към ACME-DNS сървъра, въвеждаме в отговор URL на създадения сървър (https). URL на ACME-DNS сървъра: https://acme.2nd.pp.ua

Клиентът предоставя запис, който трябва да бъде добавен към съществуващия DNS сървър (процедурата е еднократна):

[INFO] Създаване на нова регистрация acme-dns за домейн 1nd.pp.ua

Домейн:              1nd.pp.ua
Запис:               _acme-challenge.1nd.pp.ua
Тип:                   CNAME
Съдържание:          c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Забележка:           Някои контролни панели за DNS автоматично добавят финалната точка.
                           Необходима е само една.

По пътя към автоматизацията на издаването на SSL

Създаваме необходимия запис и се уверяваме, че той е създаден коректно:

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

Потвърдяваме, че сме създали необходимия запис в winacme и продължаваме с процеса на създаване на сертификата:

По пътя към автоматизацията на издаването на SSL

Как да използваме certbot като клиент е описано тук.

Процесът на създаване на сертификата приключва тук, може да бъде инсталиран на уеб сървъра и използван. Ако при създаването на сертификата се създаде и задача в планировщика, то в бъдеще процесът на обновяване на сертификата ще се извършва автоматично.

Източник: habr.com