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

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

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

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

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

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

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

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

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

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

Dev
Тест
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.

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

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

1. Създаване на DNS записи ръчно (автоматичното обновление не се поддържа)
2. Създаване на DNS записи с помощта на acme-dns сървър (по-подробно можете да прочетете тук.
3. Създаване на 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 server в 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 управление добавят финалната точка автоматично. Само една е необходима.

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

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

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

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

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

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