Досыць часта нам даводзіцца працаваць з 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
тэст
Пастаноўка
вытворчасць
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 ужо няма. А купляць асобны неяк не хочацца.
І гэта толькі на прыкладзе аднаго праекту адной кампаніі. А праект, зразумела, не адзін.
Агульныя для ўсіх прычыны заняцца вырашэннем гэтага пытання выглядаюць прыкладна так:
- Адносна нядаўна . З усімі вынікаючымі.
- Аблегчыць працэс выпуску і абслугоўвання SSL для ўнутраных патрэб праектаў і кампаніі ў цэлым.
- Цэнтралізаванае захоўванне запісаў аб сертыфікатах, якое часткова вырашае праблему пацверджання дамена з дапамогай DNS і наступнага аўтаматычнага абнаўлення, а таксама вырашае пытанне даверу кліента. Тым не менш, больш даверу выклікае CNAME на сервер кампаніі партнёра/выканаўцы, чым на іншы рэсурс.
- Ну, і нарэшце, у гэтым выпадку фраза "лепш мець чым не мець" падыходзіць выдатна.
Выбар правайдэра SSL і падрыхтоўчыя крокі
З даступных варыянтаў бясплатных SSL сертыфікатаў разглядаліся cloudflare і letsencrypt. DNS для гэтага (і некаторых іншых праектаў) як размяшчаецца на cloudflare, але я не прыхільнік выкарыстання іх сертыфікатаў. Таму было вырашана выкарыстоўваць letsencrypt.
Для стварэння wildcard SSL сертыфіката трэба пацвердзіць валоданне даменам. Гэтая працэдура мяркуе стварэнне некаторага DNS запісу (TXT або CNAME), з наступнай яе праверкай пры выпуску сертыфіката. У Linux ёсць утыліта , Якая дазваляе часткова (ці цалкам для некаторых DNS правайдэраў) аўтаматызаваць гэты працэс. Для Windows жа з варыянтаў ACME кліентаў я спыніўся на .
А запіс для дамена створаны, пераходзім да стварэння сертыфіката:
Нас цікавіць апошняя выснова, а менавіта – даступныя варыянты пацверджання валодання даменам для выпуску wildcard сертыфіката:
- Стварэнне DNS запісаў уручную (аўтаматычнае абнаўленне не падтрымліваецца)
- Стварэнне DNS запісаў з дапамогай acme-dns сервера (падрабязней можна пачытаць .
- Стварэнне DNS запісаў з дапамогай уласнага скрыпту (аналаг плагіна cloudflare для certbot).
На першы погляд, трэці пункт суцэль падыходзіць, але калі DNS правайдэр не падтрымлівае гэты функцыянал? А нам неабходны агульны выпадак. А агульны выпадак - гэта CNAME запісы, ужо іх тое ўсё падтрымліваюць. Такім чынам, спыняемся на пункце 2, і ідзем наладжваць свой ACME-DNS сервер.
Настройка ACME-DNS сервера і працэс выпуску сертыфіката
Для прыкладу, я стварыў дамен 2nd.pp.ua, і ў далейшым буду выкарыстоўваць яго.
для карэктнай працы сервера з'яўляецца стварэнне NS і А запісы для яго дамена. І першы непрыемны момант з якім я сутыкнуўся — 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 у кантэйнеры, але запусціць яго можна ўсюды дзе есць 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 <container_name> у дапамогу, балазе, логі суцэль чытэльныя.
Можам прыступаць да стварэння сертыфіката. Адкрываем powershell ад імя адміністратара і запускаем winacme. Нас цікавяць выбары:
- M: Create new certificate (full options)
- 2: Manual input
- 2: [dns-01] Create verification records with acme-dns ()
- На пытанне аб спасылцы на ACME-DNS сервер уводны ў адказ URL створанага сервера (https). URL of acme-dns server:
У адтуліну кліент выдае запіс, які трэба дадаць у існуючы DNS сервер (працэдура аднаразовая):
[INFO] Creating new acme-dns registration for domain 1nd.pp.ua
Domain: 1nd.pp.ua
Record: _acme-challenge.1nd.pp.ua
Type: CNAME
Content: c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note: Some DNS control panels add the final dot automatically.
Only one is required.
Ствараем неабходную запіс, і пераконваемся што яна стварылася карэктна:
$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.Пацвярджаем што мы стварылі патрэбны запіс у winacme, і працягваем працэс стварэння сертыфіката:
Як выкарыстоўваць certbot у якасці кліента апісана .
На гэтым працэс стварэння сертыфіката скончаны, можна ўсталёўваць яго на вэб-сервер і выкарыстоўваць. Калі пры стварэнні сертыфіката стварыць таксама і заданне ў планавальніку, то ў далейшым працэс абнаўлення сертыфіката будзе адбывацца аўтаматычна.
Крыніца: habr.com