🥇Teel SSL-i väljastamise automatiseerimise poole

Sageli tuleb meil töötada SSL-sertifikaatidega. Vaatame üle sertifikaadi loomise ja paigaldamise protsessi (üldiselt enamikule).

Leidke tarnija (veebisait, kust saame osta SSL-i).
Genereerige CSR.
Saada see tarnijale.
Kinnitage domeeni omamine.
Saage sertifikaat.
Muuda sertifikaat soovitud vormi (valikuline). Näiteks, pem-st PKCS #12-ks.
Paigaldage sertifikaat veebiserverisse.

Suhteliselt kiiresti, pole keeruline ja arusaadav. See variant sobib, kui meil on kuni tosin projekti. Aga kui neid on rohkem ja igal on vähemalt kolm keskkonda? Klassikaline dev — staging — production. Sellisel juhul tasub mõelda selle protsessi automatiseerimisele. Pakun, et uurime probleemi veidi sügavamalt ja leiame lahenduse, mis vähendab tulevikus sertifikaatide loomise ja haldamise aega. Artiklis on olemas probleemi analüüs ja väike juhend selle kordamiseks.

Eelnevalt ütlen, et meie ettevõtte peamine spetsialiseerumine on .net, seega IIS ja muud Windowsi järeltulemused. Seetõttu kirjeldatakse ACME kliendi ja kõiki sellele seotud tegevusi ka Windowsi vaatest.

Kellele see on asjakohane ja mõned algandmed

Ettevõte K autori kaudu. URL (näiteks): company.tld

Projekt X — üks meie projektidest, töötades millega olen jõudnud järeldusele, et peab liikuma suunas, kus saab maksimeerida ajakulu kokkuhoidu sertifikaatide haldamisel. Sellel projektile on neli keskkonda: dev, test, staging ja production. Dev ja test on meie poolel, staging ja production kliendi käes.

Projekti eripära on see, et sellel on suur hulk mooduleid, mis on kättesaadavad kui alamdomeenid.

See tähendab, et meil on järgmine pilt:

Dev
tuleb kasutada testimise eesmärkide eelnevaks seadistamiseks või nende kättesaadavuse kontrollimiseks. Koormuse allikate keskkonda seadistama ei pea, need on eelnevalt loodud Docker-piltidena ja väljastatud docker registrisse: piisab, kui määrata vajalik versioon etapis Test. Kuid neid saab ka uuesti ehitada ja luua oma modifitseeritud pildid.
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'is kasutatakse ostetud wildcard-sertifikaati, siin pole küsimusi. Kuid see katab ainult esimese taseme alamdomeeni. Seega, kui on sertifikaat *.projectX.tld — siis staging.projectX.tld jaoks see töötab, kuid module1.staging.projectX.tld jaoks enam mitte. Ja eraldi ostmine ei tundu kuidagi atraktiivne.

Ja see oli ainult ühe projekti näitel ühe ettevõtte kohta. Ja projekt ei ole loomulikult ainus.

Üldised põhjused, miks selle probleemi lahendamisega tegeleda, näevad välja umbes sellised:

Relatiivselt hiljuti Google pakkus välja maksimaalse SSL-sertifikaatide kehtivuse perioodi vähendamise. Kõikidest tulenevatest.
Lihtsustada sertifikaatide väljastamise ja haldamise protsessi SSL ettevõtte sisemiste vajaduste jaoks ja ettevõtte jaoks tervikuna.
Tsentrifitseeritud sertifikaatide salvestamine, mis osaliselt lahendab domeeni kinnitamise probleemi DNS-i kaudu ja jätkuva automaatse uuendamise küsimuse ning lahendab kliendi usaldus küsimuse. Lõppkokkuvõttes tekitab rohkem usaldust CNAME ettevõtte serverisse partneri/teenusepakkuja, kui kolmanda osapoole ressursid.
Noh, ja lõpuks sobib selles osas fraas "parem omada kui mitte omada" suurepäraselt.

SSL-i pakkuja valik ja ettevalmistavad sammud

Tasuta SSL-sertifikaatide seas kaaluti cloudflare ja letsencrypt. DNS-i jaoks (ja mõnedes teistes projektides) asub see cloudflare'is, kuid ma ei ole nende sertifikaatide kasutamise pooldaja. Seetõttu otsustati kasutada letsencrypti.
Remote Access VPN wildcard SSL sertifikaadi puhul tuleb kinnitada domeeni omamine. See protseduur eeldab teatud DNS-kirje (TXT või CNAME) loomist ning selle kontrollimist sertifikaadi väljastamise ajal. Linuxis on olemas utiliit — certbot, mis võimaldab osaliselt (või täielikult mõne DNS-i teenusepakkuja jaoks) automatiseerida seda protsessi. Windowsi jaoks, leidsin ja kontrollisin leitud ja testitud ACME klientide variantidest valitud WinACME Ja domeeni kirje on loodud, liikume sertifikaadi loomise juurde:.

Meid huvitab viimane väljund, nimelt — saadaval olevad domeeni omamise kinnitamise võimalused wildcard sertifikaadi väljastamiseks:

Teel SSL-i väljaandmise automatiseerimise suunas

DNS-kirjete loomine käsitsi (automaatsed uuendused ei ole toetatud)

DNS-kirjete loomine acme-dns serveri abil (lisainfot saab lugeda
DNS-kirjete loomine oma skripti abil (cloudflare'i plugina analoog certbot-ile). siit.
Esmapilgul tundub kolmas punkt täiesti sobiv, kuid mis juhtub, kui DNS-i teenusepakkuja ei toeta seda funktsionaalsust? Ja meil on vaja üldist juhtumit. Üldine juhtum on CNAME kirjed, neid toetavad kõik. Seetõttu peatume punktil 2 ja läheme oma ACME-DNS serverit seadistama.

ACME-DNS serveri seadistamine ja sertifikaadi väljastamise protsess

Sertifikaadi väljastamise protsess

Näiteks, ma loon domeeni 2nd.pp.ua ja kasutan seda edaspidi.

Kohustuslik nõue serveri õigeks toimimiseks on NS ja A kirje loomine tema domeenile. Ja esimene ebameeldiv hetk, millega ma silmitsi seisin, on see, et Cloudflare (vähemalt tasuta versiooni režiimis) ei luba samal ajal luua NS ja A kirjet ühe ja sama hosti jaoks. See ei ole probleem, kuid BIND-is on see võimalik. Toetuse vastus oli, et nende paneel seda teha ei luba. Pole hullu, loome kaks kirjet:

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

Selles etapis peaks meil olema võimalik lahendada host acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) baiti andmeid

Ja siin on acme.2nd.pp.ua ei lahenda, kuna DNS-server, mis selle teenindab, ei ole veel käivitatud.

Kirjed on loodud, liigume ACME-DNS serveri seadistamise ja käivitamise juurde. See asub mul Ubuntu serveris docker konteineris, kuid selle võib käivitada igal pool, kus on Go. Windows sobib samuti, kuid eelistaksin siiski Linuxi serverit.

Loome vajalikud kaustad ja failid:

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

Kasutame teie lemmiktekstiredaktorit vim ja lisame config.cfg-sse näidise konfiguratsioonist.

Eduka töö jaoks piisab, kui muuta sektsioone general ja 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"
…

Soovi korral loome ka docker-compose faili teenuse põhikaustas:

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

Valmis. Saame käivitada.

$ docker-compose up -d

Selles etapis peaks host hakkama lahenduma acme.2nd.pp.ua, ja kuvatakse 404 aadressil https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) baiti andmeid.

$ curl https://acme.2nd.pp.ua
404 lehte ei leitud

Kui seda ei juhtunud — docker logs -f aitab, õnneks on logid täiesti loetavad.

Saame alustada sertifikaadi loomisega. Avame PowerShelli administraatoriõigustes ja käivitame winacme. Meid huvitavad valikud:

M: Loo uus sertifikaat (täiesti valikud)
2: Käsitsi sisestamine
2: [dns-01] Loo kontrollkirjed acme-dns-iga (https://github.com/joohoi/acme-dns)
ACME-DNS serveri URL-i küsimusele vastates sisestame loodud serveri URL-i (https). URL acme-dns serveri: https://acme.2nd.pp.ua

Kliendis antakse salvestus, mille tuleb lisada olemasolevasse DNS-serverisse (protseduur on ühekordne):

[INFO] Loome uue acme-dns registreeringu domeenile 1nd.pp.ua

Domeen:              1nd.pp.ua
Salvestus:           _acme-challenge.1nd.pp.ua
Tüüp:                CNAME
Sisu:               c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Märkus:              Mõned DNS-i juhtpaneelid lisavad lõpliku punkti automaatselt.
                      Ainult üks on vajalik.

Teel SSL-i väljaandmise automatiseerimise suunas

Loome vajaliku salvestuse ja veendume, et see on õigesti loodud:

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

Kinnitage, et oleme loonud vajaliku salvestuse winacmes ja jätkame sertifikaadi loomise protsessi:

Teel SSL-i väljaandmise automatiseerimise suunas

Kuidas kasutada certbot'i kliendina on kirjeldatud siit.

Sertifikaadi loomise protsess on nüüd lõpetatud, saate selle installida veebi-serverisse ja kasutada. Kui sertifikaadi loomise ajal luua ka ülesanne ajastajas, siis edaspidi toimub sertifikaadi uuendamine automaatselt.

Allikas: habr.com