Sagedi käime sageli tööl SSL sertifikaatidega. Tuletame meelde sertifikaadi loomise ja installimise protsessi (üldiselt enamikule).
- Leida teenusepakkuja (leht, kust me saame osta SSL).
- Genereerida CSR.
- Saata see teenusepakkujale.
- Kinnitada domeeni omamine.
- Saada sertifikaat.
- Töötada sertifikaat soovitud vormi (valikuline). Näiteks, pem-st PKCS #12-ks.
- Paigaldada sertifikaat veebiserverisse.
Suhteliselt kiiresti, mitte keeruline ja arusaadav. See variant sobib hästi, kui meil on maksimaalselt kümmekond projekti. Aga kui neid on rohkem, ja igal on vähemalt kolm keskkonda? Klassikaline dev — staging — production. Sel juhul tasub mõelda selle protsessi automatiseerimisele. Pakun, et süveneme veidi probleemi ja leiame lahenduse, mis tulevikus vähendab sertifikaatide loomise ja haldamise aega. Artiklis sisaldub probleemianalüüs ja väike juhend kordamiseks.
Ettevalmistuseks ütlen, et meie ettevõtte peamine eriala on .net, mis tähendab, et IIS ja kõik muud Windowsi seotud teenused. Seetõttu on ACME klient ja kõik tegevused tema jaoks samuti kirjeldatud Windowsi kasutamise vaatenurgast.
Kellele see on oluline ja mõned algandmed
Ettevõte K autori näol. URL (näite jaoks): company.tld
Projekt X – üks meie projektidest, millega tegeledes jõudsin järeldusele, et on vajalik liikuda ajasäästlikkuse suunas sertifikaatidega töötamisel. Sellel projektis on neli keskkonda: dev, test, staging ja production. Dev ja test asuvad meie pool, staging ja production kliendi pool.
Projekti eripära on see, et sellel on suur hulk mooduleid, mis on saadaval alamdomeenidena.
Teisisõnu, meil on järgmine pilt:
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
Produktiivsetes keskkondades kasutatakse ostetud wildcard sertifikaate, kusjuures küsimusi ei teki. Kuid see katab ainult esimese taseme alamdomeeni. Seega, kui sertifikaat on *.projectX.tld — siis staging.projectX.tld jaoks see toimib, kuid module1.staging.projectX.tld jaoks enam mitte. Eraldi ostmine ei tundu kuidagi meeldiv.
Ja see on ainult ühe projekti näidis ühes ettevõttes. Projekte on loomulikult rohkem.
Üldised põhjused, miks hakata selle küsimusega tegelema, näevad välja enam-vähem sellised:
- Relatiivselt hiljuti Google pakkus välja SSL sertifikaatide maksimaalse kehtivusaja vähendamise. Kõik järgnevad tagajärjed.
- Protsessi lihtsustamine sertifikaatide väljaandmisel ja haldamisel SSL ettevõtte sisemiste projektide ja ettevõtte tervikuna jaoks.
- Keskne sertifikaatide salvestamine, mis osaliselt lahendab domeeni kinnitamise probleemi DNS-i kaudu ja järgnevat automaatset uuendamist, kuid tõstatab samas klientide usaldusprobleemi. CNAME ettevõtte partneri / täitja serveris tõenäoliselt kutsub rohkem usaldust kui kolmandate osapoolte ressurss.
- Ja lõpuks, antud juhul sobib fraas “parem omada, kui mitte omada” suurepäraselt.
SSL-i pakkuja valik ja ettevalmistavad sammud
Tasuta SSL-sertifikaatide valikute seas kaaluti cloudflare'i ja letsencrypti. DNS nende (ja mõnede teiste projektide) jaoks asub cloudflare'is, kuid ma ei poolda nende sertifikaatide kasutamist. Seetõttu otsustasin kasutada letsencrypti.
Kaugjuurdepääsu VPN-i loomine wildcard SSL sertifikaadi saamiseks tuleb tõestada domeeni omandit. See protseduur eeldab DNS-i kirje (TXT või CNAME) loomist, mis kontrollitakse sertifikaadi väljastamisel. Linuxis on tööriist — certbot, mis võimaldab seda protsessi osaliselt (või täielikult mõnede DNS-i teenusepakkujate jaoks) automatiseerida. Windowsi jaoks on leitud ja kontrollitud ACME klientide variantide seas peatunud WinACME.
Domeeni jaoks on kirje loodud, liigume sertifikaadi loomise juurde:
Meid huvitab viimane väljund, nimelt — domeeni omandi tõestamise saadaval valikud wildcard sertifikaadi väljastamiseks:
- DNS-i kirje loomine käsitsi (automaatset uuendamist ei toetata)
- DNS-i kirje loomine acme-dns serveri abil (rohkem saad lugeda siin.
- DNS-i kirje loomine oma skripti abil (cloudflare'i pistiku sarnane certboti puhul).
Esimesel pilgul sobib kolmas punkt hästi, kuid mida teha, kui DNS-i pakkuja ei toeta seda funktsionaalsust? Me vajame üldist juhtumit. Üldine juhtum on CNAME kirjed, neid toetavad kõik. Seega peatume punktis 2 ja läheme seadistama oma ACME-DNS serverit.
ACME-DNS serveri seadistamine ja sertifikaadi väljastamise protsess
Näiteks olen loonud domeeni 2nd.pp.ua ja kasutan seda edaspidi.
Kohustuslik nõue serveri korrektselt toimimiseks on selle domeeni NS ja A kirje loomine. Esimene ebamugav hetk, millega ma silmitsi seisin, oli see, et cloudflare (vähemalt tasuta versioonis) ei võimalda sama hosti jaoks korraga luua NS ja A kirjet. See ei olnud probleem, kuid bindis on see võimalik. Tugi vastas, et nende paneel seda 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 resolvitud 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 resolvuda, kuna DNS-server, mis seda teenindab, pole veel käivitatud.
Kirjed on loodud, liikume ACME-DNS serveri seadistamise ja käivitamise juurde. See töötab mul ubuntu serveris docker konteineris, kuid seda saab käivitada igal pool, kus on golang. Windows sobib samuti, aga ma eelistan siiski Linux serverit.
Loome vajalikud kataloogid ja failid:
$ mkdir config
$ mkdir data
$ touch config/config.cfg
Kasutame vim'i, teie lemmiktekstiredaktorit, ja lisame config.cfg näidise konfigureerimisest.
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"
…
Samuti, soovi korral, loome docker-compose faili teenuse põhikatalooge:
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 ilmuma peaks 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 leht ei leitud
Kui seda ei juhtunud — docker logs -f kõigest abiks, logid on päris loetavad.
Saame alustada sertifikaadi loomisega. Avame powershell administraatori õigustes ja käivitame winacme. Meid huvitavad valikud:
- M: Loo uus sertifikaat (täiendavad valikud)
- 2: Käsitsi sisend
- 2: [dns-01] Loo verifikatsioonirekordid acme-dns-iga (https://github.com/joohoi/acme-dns)
- Küsimusele ACME-DNS serveri lingi kohta sisestame vastuseks loodud serveri URL-i (https). ACME-DNS serveri URL: https://acme.2nd.pp.ua
Kliendi katsetus annab kirje, mille peame lisama olemasolevasse DNS serverisse (protseduur on üks kord tehtav):
[INFO] Loome uue acme-dns registreerimise domeeni 1nd.pp.ua
Domeen: 1nd.pp.ua
Kanne: _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õpp-punkti automaatselt.
Ainult üks on vajalik.
Loome vajaliku kirje ja veendume, et see on korrektselt loodud:
$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Kinnitame, et oleme loonud vajaliku kirje winacme-s ja jätkame sertifikaadi loomise protsessi:
Kuidas kasutada certbot'i kliendina on kirjeldatud siin.
Sellel on sertifikaadi loomise protsess lõpetatud, nüüd saab selle paigaldada veebiserverisse ja kasutada. Kui sertifikaadi loomisel luuakse ka ülesanne ajastajasse, siis toimub sertifikaadi uuendamine edaspidi automaatselt.
Allikas: habr.com
