Adesea suntem nevoiți să lucrăm cu certificate SSL. Să ne amintim procesul de creare și instalare a unui certificat (în general, pentru majoritatea cazurilor).
- Găsește un furnizor (un site de pe care putem cumpăra SSL).
- Generați CSR.
- Trimiteți-l furnizorului.
- Confirmați deținerea domeniului.
- Obțineți certificatul.
- Converteți certificatul în forma necesară (opțional). De exemplu, din pem în PKCS #12.
- Instalați certificatul pe serverul web.
Relativ rapid, nu este complicat și este clar. Această opțiune este suficientă dacă avem maxim o duzină de proiecte. Dar dacă avem mai multe, cu minimum trei medii? Clasic dev - staging - production. În acest caz, merită să ne gândim la automatizarea acestui proces. Propun să ne adâncim puțin în problemă și să găsim o soluție care, pe termen lung, să minimizeze timpul necesar creării și întreținerii certificatelor. Articolul va include o analiză a problemei și un mic ghid pentru replicare.
Aș dori să precizez dinainte: specializarea principală a companiei noastre este .net, și prin urmare IIS și alte aspecte legate de Windows. De aceea, clientul ACME și toate acțiunile pentru el vor fi descrise din perspectiva utilizării Windows.
Pentru cine este aceasta relevantă și câteva date inițiale
Compania K, prin intermediul autorului. URL (pentru exemplu): company.tld
Proiectul X — unul dintre proiectele noastre, la care lucrând am ajuns la concluzia că este necesar să ne îndreptăm spre economisirea maximă a timpului în gestionarea certificatelor. Acest proiect are patru medii: dev, test, staging și production. Dev și test sunt de partea noastră, staging și production sunt de partea clientului.
Particularitatea proiectului este că are un număr mare de module, care sunt disponibile ca subdomenii.
Adică, avem următoarea situație:
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
Pentru producție, se folosește un certificat wildcard achiziționat, aici nu sunt întrebări. Dar acesta acoperă doar primul nivel de subdomeniu. Prin urmare, dacă există un certificat pentru *.projectX.tld — atunci pentru staging.projectX.tld va funcționa, dar pentru module1.staging.projectX.tld nu va mai funcționa. Și nu prea îmi doresc să cumpăr unul separat.
Și acesta este doar un exemplu dintr-un singur proiect al unei singure companii. Și, desigur, proiectul nu este singur.
Motivele comune pentru toată lumea de a se ocupa de soluționarea acestei probleme arată cam așa:
- Relativ recent Google a propus reducerea duratei maxime de valabilitate a certificatelor SSL. Cu toate consecințele necesare.
- Facilitarea procesului de emitere și întreținere SSL pentru nevoile interne ale proiectelor și ale companiei în ansamblu.
- Stocarea centralizată a datelor despre certificate, care parțial rezolvă problema confirmării domeniului prin DNS și actualizării automate ulterioare, precum și întărește încrederea clientului. Totuși, un CNAME pe serverul companiei partenerului/contractorului, este mai de încredere decât pe o resursă externă.
- Și, în final, în acest caz, expresia "mai bine să ai decât să nu ai" se potrivește perfect.
Alegerea furnizorului SSL și pașii pregătitori
Printre opțiunile disponibile pentru certificatele SSL gratuite, au fost luate în considerare cloudflare și letsencrypt. DNS-ul pentru aceasta (și unele alte proiecte) se află pe cloudflare, dar eu nu sunt un susținător al utilizării certificatelor lor. Așadar, am decis să folosesc letsencrypt.
Pentru a crea certificatul SSL wildcard, trebuie confirmată deținerea domeniului. Această procedură presupune crearea unei înregistrări DNS (TXT sau CNAME), care va fi verificată ulterior la emiterea certificatului. În Linux, există o unealtă — certbot, care permite automatizarea parțială (sau completă pentru anumite furnizori de DNS) a acestui proces. Pentru Windows, din opțiunile găsite și verificate am ales WinACME.
Și înregistrarea pentru domeniu a fost creată, trecem la crearea certificatului:
Ne interesează ultima ieșire, și anume — opțiunile disponibile pentru confirmarea deținerii domeniului pentru emiterea certificatului wildcard:
- Crearea înregistrărilor DNS manual (actualizarea automată nu este suportată)
- Crearea înregistrărilor DNS folosind serverul acme-dns (detalii pot fi citite aici.
- Crearea înregistrărilor DNS folosind propriul script (similar plugin-ului cloudflare pentru certbot).
La prima vedere, al treilea punct pare să fie potrivit, dar ce facem dacă furnizorul DNS nu suportă această funcționalitate? Avem nevoie de un caz general. Iar cazul general este înregistrările CNAME, acestea fiind suportate de toți. Prin urmare, ne oprim la punctul 2 și ne apucăm să configurăm serverul ACME-DNS.
Configurarea serverului ACME-DNS și procesul de emitere a certificatului
De exemplu, am creat domeniul 2nd.pp.ua și îl voi folosi în continuare.
O cerință obligatorie pentru funcționarea corectă a serverului este crearea înregistrărilor NS și A pentru domeniul său. Și prima problemă neplăcută cu care m-am confruntat a fost că cloudflare (cel puțin în modul de utilizare gratuită) nu permite crearea simultană a înregistrărilor NS și A pentru același gazdă. Nu că ar fi fost o problemă, dar în bind acest lucru este posibil. Suportul a răspuns că panoul lor nu permite asta. Nu e nimic, vom crea două înregistrări:
acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.
În această etapă, gazda trebuie să fie rezolvată acmens.2nd.pp.ua.
$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes de date
Dar acme.2nd.pp.ua nu va fi rezolvat, deoarece serverul DNS care îl deservește nu este încă pornit.
Înregistrările sunt create, trecem la configurarea și pornirea serverului ACME-DNS. Acesta va rula pe un server ubuntu în docker container, dar îl pot lansa oriunde există golang. Windows este, de asemenea, o opțiune bună, dar eu prefer totuși serverele Linux.
Creăm directoarele și fișierele necesare:
$ mkdir config
$ mkdir data
$ touch config/config.cfg
Vom folosi vim, editorul dumneavoastră preferat, și vom insera în config.cfg un exemplu al configurației.
Pentru a funcționa corect, este suficient să actualizați secțiunile general și 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"
…
De asemenea, dacă doriți, vom crea un fișier docker-compose în directorul principal al serviciului:
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
Gata. Poate fi lansat.
$ docker-compose up -d
În această etapă, gazda trebuie să înceapă să fie rezolvată acme.2nd.pp.ua, și ar trebui să apară 404 pe https://acme.2nd.pp.ua
$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes de date.
$ curl https://acme.2nd.pp.ua
404 pagina nu a fost găsită
Dacă acest lucru nu a apărut — docker logs -f pentru asistență, bine, jurnalele sunt destul de lizibile.
Putem începe crearea certificatului. Deschidem PowerShell cu drepturi de administrator și lansăm winacme. Ne interesează opțiunile:
- M: Creează certificat nou (opțiuni complete)
- 2: Introducere manuală
- 2: [dns-01] Creează înregistrări de verificare cu acme-dns (https://github.com/joohoi/acme-dns)
- La întrebarea despre linkul către serverul ACME-DNS, introducem ca răspuns URL-ul serverului creat (https). URL-ul serverului acme-dns: https://acme.2nd.pp.ua
Clientul nostru dă o înregistrare pe care trebuie să o adăugăm la serverul DNS existent (procedura este unică):
[INFO] Crearea unei noi înregistrări acme-dns pentru domeniul 1nd.pp.ua
Domeniu: 1nd.pp.ua
Înregistrare: _acme-challenge.1nd.pp.ua
Tip: CNAME
Conținut: c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Nota: Unele panouri de control DNS adaugă automat punctul final.
Numai unul este necesar.
Creăm înregistrarea necesară și ne asigurăm că aceasta a fost creată corect:
$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Confirmăm că am creat înregistrarea necesară în winacme și continuăm procesul de creare a certificatului:
Cum să folosești certbot ca și client este descris aici.
Acest proces de creare a certificatului este finalizat, acum putem să-l instalăm pe serverul web și să-l folosim. Dacă în timpul creării certificatului am creat și o sarcină în planificator, atunci ulterior procesul de actualizare a certificatului se va desfășura automat.
Sursa: habr.com
