Kuelekea otomatiki ya utoaji wa SSL

Mara nyingi tunapaswa kufanya kazi na vyeti vya SSL. Hebu tukumbuke mchakato wa kuunda na kufunga cheti (katika hali ya jumla kwa wengi).

  • Tafuta mtoaji (tovuti ambayo tunaweza kununua SSL).
  • Tengeneza CSR.
  • Itume kwa mtoa huduma wako.
  • Thibitisha umiliki wa kikoa.
  • Pata cheti.
  • Badilisha cheti kwa fomu inayohitajika (hiari). Kwa mfano, kutoka pem hadi PKCS #12.
  • Sakinisha cheti kwenye seva ya wavuti.

Kwa haraka, sio ngumu na inaeleweka. Chaguo hili linafaa kabisa ikiwa tuna kiwango cha juu cha miradi kumi. Je, ikiwa kuna zaidi yao, na wana angalau mazingira matatu? Classic dev - hatua - uzalishaji. Katika kesi hii, inafaa kufikiria juu ya otomatiki mchakato huu. Ninapendekeza kutafakari kwa undani zaidi shida na kupata suluhisho ambalo litapunguza zaidi wakati unaotumika kuunda na kudumisha vyeti. Nakala hiyo itakuwa na uchambuzi wa shida na mwongozo mdogo wa kurudia.

Acha nihifadhi mapema: utaalamu kuu wa kampuni yetu ni .net, na, ipasavyo, IIS na bidhaa zingine zinazohusiana na Windows. Kwa hiyo, mteja wa ACME na vitendo vyote kwa ajili yake pia vitaelezewa kutoka kwa mtazamo wa kutumia Windows.

Je, hii ni muhimu kwa nani na baadhi ya data ya awali

Kampuni K inayowakilishwa na mwandishi. URL (kwa mfano): company.tld

Mradi X ni moja wapo ya miradi yetu, wakati nikifanya kazi ambayo nilifikia hitimisho kwamba bado tunahitaji kuelekea uokoaji wa wakati wa juu tunapofanya kazi na vyeti. Mradi huu una mazingira manne: dev, test, staging na uzalishaji. Dev na test ziko upande wetu, uandaaji na uzalishaji uko upande wa mteja.

Kipengele maalum cha mradi ni kwamba ina idadi kubwa ya moduli ambazo zinapatikana kama vikoa vidogo.

Hiyo ni, tunayo picha ifuatayo:

Dev
Mtihani
Kusonga
Uzalishaji

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

Kwa ajili ya uzalishaji, cheti cha kadi ya mwitu kilichonunuliwa kinatumiwa, hakuna maswali yanayotokea hapa. Lakini inashughulikia tu kiwango cha kwanza cha subdomain. Ipasavyo, ikiwa kuna cheti cha *.projectX.tld, basi kitafanya kazi kwa staging.projectX.tld, lakini si kwa module1.staging.projectX.tld. Lakini kwa namna fulani sitaki kununua tofauti.

Na hii inategemea tu mfano wa mradi mmoja wa kampuni moja. Na, bila shaka, kuna zaidi ya mradi mmoja.

Sababu za kawaida kwa kila mtu kushughulikia suala hili zinaonekana kama hii:

  • Hivi majuzi Google ilipendekeza kupunguza muda wa juu zaidi wa uhalali wa vyeti vya SSL. Pamoja na matokeo yote.
  • Kuwezesha mchakato wa kutoa na kudumisha SSL kwa mahitaji ya ndani ya miradi na kampuni kwa ujumla.
  • Hifadhi ya kati ya rekodi za cheti, ambayo hutatua kwa sehemu tatizo la uthibitishaji wa kikoa kwa kutumia DNS na upyaji wa moja kwa moja unaofuata, na pia kutatua suala la uaminifu wa mteja. Bado, CNAME kwenye seva ya mshirika/kampuni ya utendaji inaaminika zaidi kuliko kwenye rasilimali ya wahusika wengine.
  • Naam, hatimaye, katika kesi hii maneno "ni bora kuwa na kuliko kutokuwa na" yanafaa kikamilifu.

Kuchagua Mtoa Huduma wa SSL na Hatua za Maandalizi

Miongoni mwa chaguzi zinazopatikana kwa cheti cha bure cha SSL, cloudflare na letsencrypt zilizingatiwa. DNS ya hii (na miradi mingine) inashikiliwa na cloudflare, lakini mimi si shabiki wa kutumia vyeti vyao. Kwa hivyo, iliamuliwa kutumia letsencrypt.
Ili kuunda cheti cha SSL cha kadi-mwitu, unahitaji kuthibitisha umiliki wa kikoa. Utaratibu huu unahusisha kuunda baadhi ya rekodi za DNS (TXT au CNAME), na kisha kuithibitisha wakati wa kutoa cheti. Linux ina matumizi - certbot, ambayo hukuruhusu kuhariri mchakato huu kwa sehemu (au kabisa kwa watoa huduma wengine wa DNS). Kwa Windows kutoka kupatikana na kuthibitishwa Chaguzi za mteja wa ACME nilizozitumia WinACME.

Na rekodi ya kikoa imeundwa, wacha tuendelee kuunda cheti:

Kuelekea otomatiki ya utoaji wa SSL

Tunavutiwa na hitimisho la mwisho, yaani, chaguo zinazopatikana za kuthibitisha umiliki wa kikoa kwa kutoa cheti cha kadi-mwitu:

  1. Unda rekodi za DNS mwenyewe (sasisho otomatiki halitumiki)
  2. Kuunda rekodi za DNS kwa kutumia seva ya acme-dns (unaweza kusoma zaidi kuhusu hapa.
  3. Kuunda rekodi za DNS kwa kutumia hati yako mwenyewe (sawa na programu-jalizi ya cloudflare ya certbot).

Kwa mtazamo wa kwanza, hatua ya tatu inafaa kabisa, lakini vipi ikiwa mtoa huduma wa DNS haungi mkono utendaji huu? Lakini tunahitaji kesi ya jumla. Na kesi ya jumla ni rekodi za CNAME, kwa kuwa kila mtu anaziunga mkono. Kwa hiyo, tunasimama kwenye hatua ya 2 na kwenda kusanidi seva yetu ya ACME-DNS.

Kuanzisha seva ya ACME-DNS na mchakato wa utoaji wa cheti

Kwa mfano, niliunda kikoa 2nd.pp.ua, na nitaitumia katika siku zijazo.

Mahitaji ya lazima Ili seva ifanye kazi kwa usahihi, inahitajika kuunda rekodi za NS na A kwa kikoa chake. Na wakati wa kwanza usio na furaha ambao nilikutana nao ni kwamba cloudflare (angalau katika hali ya matumizi ya bure) haikuruhusu kuunda wakati huo huo NS na rekodi ya mwenyeji sawa. Sio kwamba hii ni shida, lakini kwa kufungwa inawezekana. Msaada ulijibu kuwa jopo lao haliruhusu kufanya hivi. Hakuna shida, wacha tuunda rekodi mbili:

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

Katika hatua hii, mwenyeji wetu anapaswa kusuluhisha acmens.2nd.pp.ua.

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

Lakini acme.2nd.pp.ua haitasuluhisha, kwani seva ya DNS inayoitumikia bado haifanyi kazi.

Rekodi zimeundwa, tunaendelea kusanidi na kuzindua seva ya ACME-DNS. Itaishi kwenye seva yangu ya ubuntu ndani docker chombo, lakini unaweza kuiendesha popote ambapo golang inapatikana. Windows pia inafaa kabisa, lakini bado ninapendelea seva ya Linux.

Unda saraka na faili zinazohitajika:

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

Wacha tutumie vim na kihariri chako cha maandishi unachopenda na ubandike sampuli kwenye config.cfg usanidi.

Kwa operesheni iliyofanikiwa, inatosha kurekebisha sehemu za jumla na 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"
…

Pia, ikiwa inataka, tutaunda faili ya kutunga docker kwenye saraka kuu ya huduma:

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

Tayari. Unaweza kuiendesha.

$ docker-compose up -d

Katika hatua hii mwenyeji anapaswa kuanza kutatua acme.2nd.pp.ua, na 404 inaonekana 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

Ikiwa hii haionekani - docker logs -f <container_name> kusaidia, kwa bahati nzuri, magogo yanasomeka kabisa.

Tunaweza kuanza kuunda cheti. Fungua ganda la nguvu kama msimamizi na uendeshe winacme. Tunavutiwa na uchaguzi:

  • M: Unda cheti kipya (chaguo kamili)
  • 2:Ingizo la mwongozo
  • 2: [dns-01] Unda rekodi za uthibitishaji na acme-dns (https://github.com/joohoi/acme-dns)
  • Unapoulizwa kuhusu kiungo kwa seva ya ACME-DNS, ingiza URL ya seva iliyoundwa (https) kwenye jibu. URL ya seva ya acme-dns: https://acme.2nd.pp.ua

Katika ufunguzi, mteja hutoa rekodi ambayo inahitaji kuongezwa kwa seva iliyopo ya DNS (utaratibu wa wakati mmoja):

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

Kuelekea otomatiki ya utoaji wa SSL

Tunaunda rekodi muhimu na kuhakikisha kuwa iliundwa kwa usahihi:

Kuelekea otomatiki ya utoaji wa SSL

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

Tunathibitisha kuwa tumeunda ingizo linalohitajika katika winacme, na kuendelea na mchakato wa kuunda cheti:

Kuelekea otomatiki ya utoaji wa SSL

Jinsi ya kutumia certbot kama mteja imeelezewa hapa.

Hii inakamilisha mchakato wa kuunda cheti; unaweza kukisakinisha kwenye seva ya wavuti na kukitumia. Ikiwa, wakati wa kuunda cheti, unaunda pia kazi katika mpangilio, basi katika siku zijazo mchakato wa upyaji wa cheti utatokea moja kwa moja.

Chanzo: mapenzi.com

Kuongeza maoni