ProHoster > Blog > Administrazioa > SSL jaulkipenaren automatizaziorantz

SSL jaulkipenaren automatizaziorantz

Askotan SSL ziurtagiriekin lan egin behar izaten dugu. Gogora dezagun ziurtagiri bat sortzeko eta instalatzeko prozesua (kasu orokorrean gehienentzat).

  • Bilatu hornitzaile bat (SSL erosi dezakegun gunea).
  • ESK sortu.
  • Bidali zure hornitzaileari.
  • Egiaztatu domeinuaren jabetza.
  • Lortu ziurtagiria.
  • Bihurtu ziurtagiria behar den formulariora (aukerakoa). Adibidez, pem-etik PKCS #12ra.
  • Instalatu ziurtagiria web zerbitzarian.

Nahiko azkarra, ez konplikatua eta ulergarria. Aukera hau nahiko egokia da gehienez hamar proiektu baditugu. Zer gertatzen da gehiago badira, eta gutxienez hiru ingurune badituzte? Garapen klasikoa - eszenaratzea - ​​ekoizpena. Kasu honetan, prozesu hau automatizatzeaz pentsatzea komeni da. Arazoan apur bat sakontzea eta ziurtagiriak sortzeko eta mantentzeko denbora gehiago gutxituko duen irtenbide bat aurkitzea proposatzen dut. Artikuluak arazoaren analisia eta errepikapenerako gida txiki bat izango ditu.

Erreserba egin dezadan aldez aurretik: gure enpresaren espezializazio nagusia .net da, eta, horren arabera, IIS eta Windows-ekin lotutako beste produktu batzuk. Hori dela eta, ACME bezeroa eta horretarako ekintza guztiak Windows erabiltzearen ikuspuntutik ere deskribatuko dira.

Norentzat da garrantzitsua eta hasierako datu batzuk

Egileak ordezkatuta K enpresa. URLa (adibidez): company.tld

X proiektua gure proiektuetako bat da, lanean ari nintzen bitartean ziurtagiriekin lan egitean denbora gehien aurrezteko bidean aurrera egin behar dugula ondorioztatu nuen. Proiektu honek lau ingurune ditu: garapena, proba, eszenaratzea eta ekoizpena. Garapena eta proba gure alde daude, eszenaratzea eta ekoizpena bezeroaren aldetik.

Proiektuaren ezaugarri berezi bat azpidomeinu gisa eskuragarri dauden modulu ugari dituela da.

Hau da, argazki hau dugu:

dev
Test
eszenaratzea
produkzio

projectX.dev.company.tld
projectX.test.company.tld
eszenaratze.proiektuaX.tld
proiektuaX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
modulu1.proiektuaX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
modulu2.proiektuaX.tld

...
...
...
...

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

Ekoizpenerako, erositako komodinaren ziurtagiria erabiltzen da, hemen ez da galderarik sortzen. Baina azpidomeinuaren lehen maila bakarrik hartzen du. Horren arabera, *.projectX.tld-rako ziurtagiria badago, staging.projectX.tld-rako funtzionatuko du, baina ez module1.staging.projectX.tld-rako. Baina, nolabait, ez dut aparteko bat erosi nahi.

Eta hau enpresa baten proiektu baten adibidean soilik oinarritzen da. Eta, noski, proiektu bat baino gehiago dago.

Guztiek arazo honi aurre egiteko ohiko arrazoiak honelakoak dira:

  • Duela gutxi Google-k SSL ziurtagirien gehienezko balio-epea murriztea proposatu zuen. Ondorio guztiekin.
  • SSL jaulkitzeko eta mantentzeko prozesua erraztu proiektuen eta enpresa osoaren barne beharretarako.
  • Ziurtagiri-erregistroen biltegiratze zentralizatua, domeinuaren egiaztapenaren arazoa partzialki konpontzen duena DNS eta ondorengo berritze automatikoa erabiliz, eta bezeroen konfiantzaren arazoa ere konpontzen du. Hala ere, CNAME enpresa bazkide/performer baten zerbitzarian fidagarriagoa da hirugarrenen baliabide batean baino.
  • Tira, azkenik, kasu honetan β€œhobe da ez edukitzea baino” esaldia primeran egokitzen da.

SSL hornitzaile bat hautatzea eta prestatzeko urratsak

Doako SSL ziurtagirien aukeren artean, cloudflare eta letsencrypt kontuan hartu ziren. Honen (eta beste zenbait proiekturen) DNSa cloudflare-k ostatatuta dago, baina ez naiz haien ziurtagiriak erabiltzearen zalea. Horregatik, letsencrypt erabiltzea erabaki zen.
SSL ziurtagiri komodin bat sortzeko, domeinuaren jabetza berretsi behar duzu. Prozedura honek DNS erregistro batzuk (TXT edo CNAME) sortzea dakar, eta gero egiaztatzea ziurtagiria igortzean. Linuxek erabilgarritasun bat du - certbot, DNS hornitzaile batzuentzat partzialki (edo guztiz) prozesu hau automatizatzeko aukera ematen duena. Windows-erako aurkitu eta egiaztatu Nik finkatu nituen ACME bezeroen aukerak WinACME.

Eta domeinuaren erregistroa sortu da, joan gaitezen ziurtagiri bat sortzera:

SSL jaulkipenaren automatizaziorantz

Azken ondorioa interesatzen zaigu, hots, komodin ziurtagiria igortzeko domeinuaren jabetza berresteko dauden aukerak:

  1. Sortu DNS erregistroak eskuz (eguneratze automatikoa ez da onartzen)
  2. DNS erregistroak sortzea acme-dns zerbitzaria erabiliz (gehiago irakurri dezakezu Hemen.
  3. DNS erregistroak sortzea zure script-a erabiliz (certbot-erako cloudflare pluginaren antzekoa).

Lehen begiratuan, hirugarren puntua nahiko egokia da, baina zer gertatzen da DNS hornitzaileak funtzionalitate hau onartzen ez badu? Baina kasu orokor bat behar dugu. Baina kasu orokorra CNAME erregistroak dira, guztiek onartzen baitituzte. Hori dela eta, 2. puntuan gelditu eta gure ACME-DNS zerbitzaria konfiguratzera joango gara.

ACME-DNS zerbitzaria eta ziurtagiriak jaulkitzeko prozesua konfiguratzea

Adibidez, 2nd.pp.ua domeinua sortu dut, eta etorkizunean erabiliko dut.

Nahitaezko betekizuna Zerbitzariak behar bezala funtziona dezan, beharrezkoa da bere domeinurako NS eta A erregistroak sortzea. Eta topatu dudan lehen une desatsegina da cloudflare (erabilera libreko moduan behintzat) ez dizula uzten ostalari bererako NS eta A erregistro bat aldi berean sortzeko. Ez hori arazo bat denik, baina lotuan posible da. Laguntzak erantzun zuen bere panelak ez duela onartzen hau egiten. Ez dago arazorik, sor ditzagun bi erregistro:

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

Fase honetan, gure ostalariak konpondu beharko luke acmens.2nd.pp.ua.

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

Baina acme.2nd.pp.ua ez da konponduko, zerbitzatzen duen DNS zerbitzaria oraindik ez baitago martxan.

Erregistroak sortu dira, ACME-DNS zerbitzaria konfiguratzen eta abiarazten jarraitzen dugu. Nire ubuntu zerbitzarian biziko da Docker edukiontzia, baina golang eskuragarri dagoen toki guztietan exekutatu dezakezu. Windows ere nahiko egokia da, baina oraindik nahiago dut Linux zerbitzari bat.

Sortu beharrezko direktorio eta fitxategiak:

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

Erabili vim zure gogoko testu-editorearekin eta itsatsi lagina config.cfg-en konfigurazioa.

Funtzionamendu arrakastatsua izateko, nahikoa da atal orokorrak eta api atalak zuzentzea:

[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"
…

Gainera, nahi izanez gero, docker-compose fitxategi bat sortuko dugu zerbitzu-direktorio nagusian:

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

Prest. Exekutatu dezakezu.

$ docker-compose up -d

Fase honetan ostalaria konpontzen hasi beharko litzateke acme.2nd.pp.ua, eta 404 bat agertzen da 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

Hau agertzen ez bada - docker logs -f <container_name> laguntzeko, zorionez, erregistroak nahiko irakurgarriak dira.

Ziurtagiria sortzen has gaitezke. Ireki powershell administratzaile gisa eta exekutatu winacme. Hauteskundeak interesatzen zaizkigu:

  • M: Sortu ziurtagiri berria (aukera osoak)
  • 2: Eskuzko sarrera
  • 2: [dns-01] Sortu egiaztapen-erregistroak acme-dns-ekin (https://github.com/joohoi/acme-dns)
  • ACME-DNS zerbitzarirako esteka bati buruz galdetuta, idatzi sortutako zerbitzariaren URLa (https) erantzunean. acme-dns zerbitzariaren URLa: https://acme.2nd.pp.ua

Irekieran, bezeroak lehendik dagoen DNS zerbitzarian gehitu behar den erregistro bat igortzen du (prozedura behin-behinekoa):

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

SSL jaulkipenaren automatizaziorantz

Beharrezko erregistroa sortzen dugu eta behar bezala sortu dela ziurtatzen dugu:

SSL jaulkipenaren automatizaziorantz

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

Winacme-n beharrezko sarrera sortu dugula berresten dugu eta ziurtagiri bat sortzeko prozesua jarraitzen dugu:

SSL jaulkipenaren automatizaziorantz

Certbot bezero gisa nola erabili deskribatzen da Hemen.

Horrek ziurtagiri bat sortzeko prozesua amaitzen du; web zerbitzarian instalatu eta erabil dezakezu. Ziurtagiri bat sortzean, programatzailean zeregin bat ere sortzen baduzu, etorkizunean automatikoki gertatuko da ziurtagiria berritzeko prozesua.

Iturria: www.habr.com

Gehitu iruzkin berria