Drejt automatizimit të lëshimit të SSL

Shumë shpesh na duhet të punojmë me certifikata SSL. Le të kujtojmë procesin e krijimit dhe instalimit të një certifikate (në rastin e përgjithshëm për shumicën).

• Gjeni një ofrues (një faqe ku mund të blejmë SSL).
• Krijo CSR.
• Dërgojeni te ofruesi juaj.
• Verifikoni pronësinë e domenit.
• Merrni një certifikatë.
• Konvertoni certifikatën në formën e kërkuar (opsionale). Për shembull, nga pem në PKCS #12.
• Instaloni certifikatën në serverin e internetit.

Relativisht i shpejtë, jo i komplikuar dhe i kuptueshëm. Ky opsion është mjaft i përshtatshëm nëse kemi maksimum dhjetë projekte. Po sikur të ketë më shumë prej tyre dhe të kenë të paktën tre mjedise? Klasik dev - skenë - prodhim. Në këtë rast, ia vlen të mendoni për automatizimin e këtij procesi. Unë propozoj të thellohemi pak më thellë në problemin dhe të gjejmë një zgjidhje që do të minimizojë më tej kohën e shpenzuar për krijimin dhe mirëmbajtjen e certifikatave. Artikulli do të përmbajë një analizë të problemit dhe një udhëzues të vogël për përsëritjen.

Më lejoni të bëj një rezervim paraprakisht: specializimi kryesor i kompanisë sonë është .net, dhe, në përputhje me rrethanat, IIS dhe produkte të tjera të lidhura me Windows. Prandaj, klienti ACME dhe të gjitha veprimet për të do të përshkruhen gjithashtu nga pikëpamja e përdorimit të Windows.

Për kë është kjo e rëndësishme dhe disa të dhëna fillestare

Kompania K e përfaqësuar nga autori. URL (për shembull): company.tld

Projekti X është një nga projektet tona, ndërsa punova në të cilin arrita në përfundimin se duhet ende të shkojmë drejt kursimit maksimal të kohës kur punojmë me certifikata. Ky projekt ka katër mjedise: dev, test, skenë dhe prodhim. Dev dhe testi janë në anën tonë, inskenimi dhe prodhimi janë në anën e klientit.

Një veçori e veçantë e projektit është se ai ka një numër të madh modulesh që janë të disponueshme si nëndomanë.

Kjo është, ne kemi foton e mëposhtme:

Dev
Provë
vënie në skenë
Prodhim

projectX.dev.company.tld
projectX.test.company.tld
inskenimi.projektX.tld
projektX.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

Për prodhimin, përdoret një çertifikatë e blerë e karakterit të egër, këtu nuk lindin pyetje. Por mbulon vetëm nivelin e parë të nëndomainit. Prandaj, nëse ka një certifikatë për *.projectX.tld, atëherë ajo do të funksionojë për staging.projectX.tld, por jo për module1.staging.projectX.tld. Por disi nuk dua të blej një të veçantë.

Dhe kjo bazohet vetëm në shembullin e një projekti të një kompanie. Dhe, sigurisht, ka më shumë se një projekt.

Arsyet e zakonshme për të gjithë për të trajtuar këtë çështje duken diçka si kjo:

• Kohët e fundit Google propozoi reduktimin e periudhës maksimale të vlefshmërisë së certifikatave SSL. Me të gjitha pasojat.
• Lehtësimi i procesit të lëshimit dhe mbajtjes së SSL për nevojat e brendshme të projekteve dhe kompanisë në tërësi.
• Ruajtja e centralizuar e të dhënave të certifikatës, e cila zgjidh pjesërisht problemin e verifikimit të domenit duke përdorur DNS dhe rinovimin automatik pasues, dhe gjithashtu zgjidh çështjen e besimit të klientit. Megjithatë, një CNAME në serverin e një kompanie partnere/performuese është më e besueshme sesa në një burim të palës së tretë.
• Epo, më në fund, në këtë rast shprehja "është më mirë të kesh sesa të mos kesh" përshtatet në mënyrë të përkryer.

Zgjedhja e një ofruesi SSL dhe hapat përgatitorë

Ndër opsionet e disponueshme për certifikatat SSL falas, u konsideruan cloudflare dhe letsencrypt. DNS për këtë (dhe disa projekte të tjera) është pritur nga cloudflare, por unë nuk jam adhurues i përdorimit të certifikatave të tyre. Prandaj, u vendos që të përdoret letsencrypt.
Për të krijuar një certifikatë SSL me shkronja të ngurta, duhet të konfirmoni pronësinë e domenit. Kjo procedurë përfshin krijimin e një regjistrimi DNS (TXT ose CNAME), dhe më pas verifikimin e tij kur lëshoni një certifikatë. Linux ka një mjet - çertbot, i cili ju lejon të automatizoni pjesërisht (ose plotësisht për disa ofrues DNS) këtë proces. Për Windows nga gjetur dhe verifikuar Opsionet e klientit ACME Unë u vendosa WinACME.

Dhe rekordi për domenin është krijuar, le të kalojmë në krijimin e një certifikate:

Ne jemi të interesuar në përfundimin e fundit, përkatësisht, opsionet e disponueshme për konfirmimin e pronësisë së domenit për lëshimin e një certifikate wildcard:

1. Krijo manualisht regjistrime DNS (përditësimi automatik nuk mbështetet)
2. Krijimi i regjistrimeve DNS duke përdorur serverin acme-dns (mund të lexoni më shumë rreth këtu.
3. Krijimi i regjistrimeve DNS duke përdorur skriptin tuaj (i ngjashëm me shtojcën cloudflare për certbot).

Në pamje të parë, pika e tretë është mjaft e përshtatshme, por çka nëse ofruesi DNS nuk e mbështet këtë funksionalitet? Por ne kemi nevojë për një rast të përgjithshëm. Dhe rasti i përgjithshëm janë regjistrimet CNAME, pasi të gjithë i mbështesin ato. Prandaj, ne ndalemi në pikën 2 dhe shkojmë të konfigurojmë serverin tonë ACME-DNS.

Konfigurimi i serverit ACME-DNS dhe procesi i lëshimit të certifikatës

Për shembull, kam krijuar domenin 2nd.pp.ua dhe do ta përdor në të ardhmen.

Kërkesa e detyrueshme Që serveri të funksionojë siç duhet, është e nevojshme të krijohen regjistrime NS dhe A për domenin e tij. Dhe momenti i parë i pakëndshëm që hasa është se cloudflare (të paktën në modalitetin e përdorimit falas) nuk ju lejon të krijoni njëkohësisht një rekord NS dhe A për të njëjtin host. Jo se ky është një problem, por në lidhje me këtë është e mundur. Mbështetja u përgjigj se paneli i tyre nuk e lejon këtë. Nuk ka problem, le të krijojmë dy regjistrime:

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

Në këtë fazë, pritësi ynë duhet të zgjidhë acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

Por acme.2nd.pp.ua nuk do të zgjidhet, pasi serveri DNS që e shërben nuk është ende në punë.

Regjistrimet janë krijuar, ne vazhdojmë me konfigurimin dhe lëshimin e serverit ACME-DNS. Ai do të jetojë në serverin tim në ubuntu cungues kontejner, por mund ta përdorni kudo ku golang është i disponueshëm. Windows është gjithashtu mjaft i përshtatshëm, por unë ende preferoj një server Linux.

Krijoni drejtoritë dhe skedarët e nevojshëm:

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

Le të përdorim vim me redaktuesin tuaj të preferuar të tekstit dhe ta ngjisni mostrën në config.cfg konfigurimi.

Për funksionim të suksesshëm, mjafton të korrigjoni seksionet e përgjithshme dhe 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"
…

Gjithashtu, nëse dëshironi, ne do të krijojmë një skedar docker-compose në drejtorinë kryesore të shërbimit:

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

Gati. Mund ta ekzekutoni.

$ docker-compose up -d

Në këtë fazë pritësi duhet të fillojë të zgjidhë acme.2nd.pp.ua, dhe një 404 shfaqet në 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

Nëse kjo nuk shfaqet - docker logs -f <container_name> për të ndihmuar, për fat të mirë, regjistrat janë mjaft të lexueshëm.

Mund të fillojmë krijimin e certifikatës. Hapni powershell si administrator dhe ekzekutoni winacme. Ne jemi të interesuar për zgjedhjet:

• M: Krijo certifikatë të re (opsione të plota)
• 2: Hyrja manuale
• 2: [dns-01] Krijoni regjistrime verifikimi me acme-dns (https://github.com/joohoi/acme-dns)
• Kur pyeteni për një lidhje me serverin ACME-DNS, shkruani URL-në e serverit të krijuar (https) në përgjigje. URL-ja e serverit acme-dns: https://acme.2nd.pp.ua

Në hapje, klienti lëshon një rekord që duhet të shtohet në serverin ekzistues DNS (procedurë një herë):

[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.

Ne krijojmë rekordin e nevojshëm dhe sigurohemi që është krijuar saktë:

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

Ne konfirmojmë që kemi krijuar hyrjen e kërkuar në winacme dhe vazhdojmë procesin e krijimit të një certifikate:

Si të përdorni certbot si klient është përshkruar këtu.

Kjo përfundon procesin e krijimit të një certifikate; mund ta instaloni në serverin e internetit dhe ta përdorni. Nëse, kur krijoni një certifikatë, krijoni edhe një detyrë në planifikuesin, atëherë në të ardhmen procesi i rinovimit të certifikatës do të ndodhë automatikisht.

Burimi: www.habr.com