Patungo sa automation ng pagpapalabas ng SSL

Kadalasan kailangan nating magtrabaho kasama ang mga SSL certificate. Tandaan natin ang proseso ng paglikha at pag-install ng isang sertipiko (sa pangkalahatang kaso para sa karamihan).

• Maghanap ng provider (isang site kung saan tayo makakabili ng SSL).
• Bumuo ng CSR.
• Ipadala ito sa iyong provider.
• I-verify ang pagmamay-ari ng domain.
• Kumuha ng sertipiko.
• I-convert ang certificate sa kinakailangang form (opsyonal). Halimbawa, mula pem hanggang PKCS #12.
• I-install ang certificate sa web server.

Medyo mabilis, hindi kumplikado at naiintindihan. Ang pagpipiliang ito ay lubos na angkop kung mayroon tayong maximum na sampung proyekto. Paano kung mas marami sila, at mayroon silang kahit tatlong kapaligiran? Klasikong dev - pagtatanghal ng dula - produksyon. Sa kasong ito, ito ay nagkakahalaga ng pag-iisip tungkol sa pag-automate ng prosesong ito. Iminumungkahi kong pag-aralan nang mas malalim ang problema at maghanap ng solusyon na lalong magpapaliit sa oras na ginugol sa paggawa at pagpapanatili ng mga sertipiko. Ang artikulo ay maglalaman ng pagsusuri ng problema at isang maliit na gabay sa pag-uulit.

Hayaan akong magpareserba nang maaga: ang pangunahing espesyalisasyon ng aming kumpanya ay .net, at, nang naaayon, IIS at iba pang mga produktong nauugnay sa Windows. Samakatuwid, ang kliyente ng ACME at lahat ng mga aksyon para dito ay ilalarawan din mula sa punto ng view ng paggamit ng Windows.

Para kanino ito nauugnay at ilang paunang data

Kumpanya K na kinakatawan ng may-akda. URL (halimbawa): company.tld

Ang Project X ay isa sa aming mga proyekto, habang nagtatrabaho kung saan ako ay dumating sa konklusyon na kailangan pa rin naming lumipat patungo sa maximum na pagtitipid sa oras kapag nagtatrabaho sa mga sertipiko. Ang proyektong ito ay may apat na kapaligiran: dev, pagsubok, pagtatanghal ng dula at produksyon. Ang dev at pagsubok ay nasa panig namin, ang pagtatanghal ng dula at produksyon ay nasa panig ng kliyente.

Ang isang espesyal na tampok ng proyekto ay mayroon itong malaking bilang ng mga module na magagamit bilang mga subdomain.

Ibig sabihin, mayroon tayong sumusunod na larawan:

Dev
Pagsubok
Paghahanda
produksyon

projectX.dev.company.tld
projectX.test.company.tld
pagtatanghal ng dula.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

Para sa produksyon, ginagamit ang isang biniling wildcard na sertipiko, walang mga tanong na lumabas dito. Ngunit sinasaklaw lamang nito ang unang antas ng subdomain. Alinsunod dito, kung mayroong sertipiko para sa *.projectX.tld, gagana ito para sa staging.projectX.tld, ngunit hindi para sa module1.staging.projectX.tld. Ngunit kahit papaano ay ayaw kong bumili ng hiwalay.

At ito ay batay lamang sa halimbawa ng isang proyekto ng isang kumpanya. At, siyempre, mayroong higit sa isang proyekto.

Ang mga karaniwang dahilan para matugunan ng lahat ang isyung ito ay mukhang ganito:

• Kamakailan lang Iminungkahi ng Google na bawasan ang maximum na panahon ng bisa ng mga SSL certificate. Sa lahat ng kahihinatnan.
• Pangasiwaan ang proseso ng pag-isyu at pagpapanatili ng SSL para sa mga panloob na pangangailangan ng mga proyekto at ng kumpanya sa kabuuan.
• Sentralisadong imbakan ng mga talaan ng sertipiko, na bahagyang nalulutas ang problema ng pag-verify ng domain gamit ang DNS at kasunod na awtomatikong pag-renew, at nilulutas din ang isyu ng tiwala ng kliyente. Gayunpaman, ang isang CNAME sa server ng isang partner/performer na kumpanya ay mas mapagkakatiwalaan kaysa sa isang third-party na mapagkukunan.
• Buweno, sa wakas, sa kasong ito ang pariralang "mas mabuti na magkaroon kaysa wala" ay akma nang perpekto.

Pagpili ng SSL Provider at Mga Hakbang sa Paghahanda

Kabilang sa mga magagamit na opsyon para sa libreng SSL certificate, cloudflare at letsencrypt ay isinasaalang-alang. Ang DNS para dito (at ilang iba pang proyekto) ay hino-host ng cloudflare, ngunit hindi ako fan ng paggamit ng kanilang mga sertipiko. Samakatuwid, napagpasyahan na gamitin ang letsencrypt.
Para gumawa ng wildcard SSL certificate, kailangan mong kumpirmahin ang pagmamay-ari ng domain. Kasama sa pamamaraang ito ang paggawa ng ilang tala ng DNS (TXT o CNAME), at pagkatapos ay i-verify ito kapag nag-isyu ng certificate. Ang Linux ay may utility - certbot, na nagbibigay-daan sa iyong bahagyang (o ganap para sa ilang DNS provider) na i-automate ang prosesong ito. Para sa Windows mula sa natagpuan at napatunayan Mga opsyon sa kliyente ng ACME na aking naayos WinACME.

At ang rekord para sa domain ay nagawa na, magpatuloy tayo sa paglikha ng isang sertipiko:

Interesado kami sa huling konklusyon, ibig sabihin, ang mga available na opsyon para sa pagkumpirma ng pagmamay-ari ng domain para sa pag-isyu ng wildcard na certificate:

1. Gumawa ng mga tala ng DNS nang manu-mano (hindi suportado ang awtomatikong pag-update)
2. Paglikha ng mga tala ng DNS gamit ang acme-dns server (maaari kang magbasa nang higit pa tungkol sa dito.
3. Paglikha ng mga tala ng DNS gamit ang iyong sariling script (katulad ng cloudflare plugin para sa certbot).

Sa unang sulyap, ang ikatlong punto ay medyo angkop, ngunit paano kung ang DNS provider ay hindi sumusuporta sa pagpapaandar na ito? Ngunit kailangan namin ng isang pangkalahatang kaso. Ngunit ang pangkalahatang kaso ay mga tala ng CNAME, dahil sinusuportahan ng lahat ang mga ito. Samakatuwid, huminto kami sa punto 2 at pumunta upang i-configure ang aming ACME-DNS server.

Pagse-set up ng ACME-DNS server at proseso ng pagbibigay ng certificate

Halimbawa, ginawa ko ang domain na 2nd.pp.ua, at gagamitin ko ito sa hinaharap.

Mandatory na kinakailangan Para gumana nang tama ang server, kinakailangan na gumawa ng mga NS at A record para sa domain nito. At ang unang hindi kasiya-siyang sandali na naranasan ko ay ang cloudflare (kahit sa libreng mode ng paggamit) ay hindi nagpapahintulot sa iyo na sabay na lumikha ng isang NS at A record para sa parehong host. Hindi na ito ay isang problema, ngunit ito ay posible. Sumagot ang suporta na hindi pinapayagan ng kanilang panel ang paggawa nito. Walang problema, gumawa tayo ng dalawang tala:

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

Sa yugtong ito, dapat malutas ng aming host acmens.2nd.pp.ua.

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

Pero acme.2nd.pp.ua hindi ito malulutas, dahil hindi pa tumatakbo ang DNS server na nagsisilbi dito.

Nagawa na ang mga talaan, nagpapatuloy kami sa pag-set up at paglulunsad ng ACME-DNS server. Mabubuhay ito sa aking ubuntu server sa docker lalagyan, ngunit maaari mo itong patakbuhin kahit saan kung saan available ang golang. Ang Windows ay angkop din, ngunit mas gusto ko pa rin ang isang server ng Linux.

Lumikha ng mga kinakailangang direktoryo at file:

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

Gamitin natin ang vim sa iyong paboritong text editor at i-paste ang sample sa config.cfg pagsasaayos.

Para sa matagumpay na operasyon, sapat na upang itama ang pangkalahatang at api na mga seksyon:

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

Gayundin, kung ninanais, gagawa kami ng docker-compose file sa pangunahing direktoryo ng serbisyo:

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

handa na. Maaari mo itong patakbuhin.

$ docker-compose up -d

Sa yugtong ito ang host ay dapat magsimulang malutas acme.2nd.pp.ua, at lalabas ang isang 404 sa 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

Kung hindi ito lilitaw - docker logs -f <container_name> upang makatulong, sa kabutihang palad, ang mga log ay medyo nababasa.

Maaari naming simulan ang paggawa ng sertipiko. Buksan ang powershell bilang administrator at patakbuhin ang winacme. Kami ay interesado sa halalan:

• M: Gumawa ng bagong certificate (buong mga opsyon)
• 2: Manu-manong pag-input
• 2: [dns-01] Lumikha ng mga tala sa pag-verify gamit ang acme-dns (https://github.com/joohoi/acme-dns)
• Kapag tinanong tungkol sa isang link sa ACME-DNS server, ilagay ang URL ng nilikhang server (https) sa sagot. URL ng acme-dns server: https://acme.2nd.pp.ua

Sa pambungad, nag-isyu ang kliyente ng talaan na kailangang idagdag sa umiiral nang DNS server (isang beses na pamamaraan):

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

Lumilikha kami ng kinakailangang tala at tinitiyak na ginawa ito nang tama:

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

Kinukumpirma namin na nilikha namin ang kinakailangang entry sa winacme, at ipagpatuloy ang proseso ng paglikha ng isang sertipiko:

Inilarawan kung paano gamitin ang certbot bilang isang kliyente dito.

Kinukumpleto nito ang proseso ng paglikha ng isang sertipiko; maaari mo itong i-install sa web server at gamitin ito. Kung, kapag lumilikha ng isang sertipiko, lumikha ka rin ng isang gawain sa scheduler, pagkatapos ay sa hinaharap ang proseso ng pag-renew ng sertipiko ay awtomatikong magaganap.

Pinagmulan: www.habr.com