ProHoster > Օրագիր > Վարչակազմը > SSL-ի թողարկման ավտոմատացման ուղղությամբ

SSL-ի թողարկման ավտոմատացման ուղղությամբ

Հաճախ մենք պետք է աշխատենք SSL վկայագրերի հետ: Հիշենք վկայագրի ստեղծման և տեղադրման գործընթացը (ընդհանուր դեպքում մեծամասնության համար):

  • Գտեք մատակարար (կայք, որտեղ մենք կարող ենք գնել SSL):
  • Ստեղծեք ԿՍՊ:
  • Ուղարկեք այն մատակարարին:
  • Հաստատեք տիրույթի սեփականությունը:
  • Ստացեք վկայական:
  • Վկայագիրը փոխարկեք ցանկալի ձևին (ըստ ցանկության): Օրինակ, pem-ից մինչև PKCS #12:
  • Տեղադրեք վկայագիրը վեբ սերվերի վրա:

Համեմատաբար արագ, ոչ բարդ և հասկանալի: Այս տարբերակը բավականին հարմար է, եթե մենք ունենք առավելագույնը տասը նախագիծ։ Իսկ եթե դրանք ավելի շատ լինեն, և նրանք ունենան առնվազն երեք միջավայր: Դասական զարգացում - բեմադրություն - արտադրություն: Այս դեպքում արժե մտածել այս գործընթացի ավտոմատացման մասին։ Առաջարկում եմ մի փոքր խորանալ խնդրի մեջ և գտնել լուծում, որն էլ ավելի կնվազեցնի սերտիֆիկատների ստեղծման և պահպանման վրա ծախսվող ժամանակը: Հոդվածը կպարունակի խնդրի վերլուծություն և կրկնության փոքր ուղեցույց:

Նախօրոք վերապահում կանեմ՝ մեր ընկերության հիմնական մասնագիտացումը .net-ն է, համապատասխանաբար՝ IIS-ը և այլ պտուտակայինները։ Հետևաբար, ACME հաճախորդը և դրա համար նախատեսված բոլոր գործողությունները նույնպես նկարագրվելու են պատուհանների օգտագործման առումով:

Ում համար է դա տեղին և որոշ ֆոնային տվյալներ

Կ ընկերություն՝ ի դեմս հեղինակի։ URL (օրինակ՝ company.tld):

Project X-ը մեր նախագծերից մեկն է, որտեղ ես եկել եմ այն ​​եզրակացության, որ մենք դեռ պետք է գնանք դեպի առավելագույն ժամանակի խնայողություն սերտիֆիկատների հետ աշխատելիս: Այս նախագիծն ունի չորս միջավայր՝ մշակող, թեստ, բեմականացում և արտադրություն: Dev-ը և փորձարկումը մեր կողմից են, բեմադրությունն ու արտադրությունը՝ հաճախորդի կողմից:

Ծրագրի առանձնահատկությունն այն է, որ այն ունի մեծ թվով մոդուլներ, որոնք հասանելի են որպես ենթադոմեյններ:

Այսինքն՝ ունենք հետևյալ պատկերը.

Դեւ
փորձարկում
երթեւեկելը
արտադրություն

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

Արտադրության համար օգտագործվում է ձեռք բերված wildcard վկայագիր, այստեղ հարցեր չկան: Բայց այն ընդգրկում է միայն ենթադոմեյնի առաջին մակարդակը: Համապատասխանաբար, եթե կա սերտիֆիկատ *.projectX.tld-ի համար, ապա այն կաշխատի staging.projectX.tld-ի համար, բայց ոչ module1.staging.projectX.tld-ի համար: Ես չեմ ուզում առանձին գնել:

Եվ սա միայն մեկ ընկերության մեկ նախագծի օրինակով։ Եվ նախագիծը, իհարկե, միայնակ չէ.

Այս խնդրի լուծման ընդհանուր պատճառները մոտավորապես այսպիսին են.

  • Վերջերս Google-ն առաջարկել է նվազեցնել SSL վկայագրերի առավելագույն վավերականության ժամկետը. Բոլոր հետեւանքներով։
  • Դյուրացնել SSL-ի թողարկման և պահպանման գործընթացը նախագծերի և ընդհանուր առմամբ ընկերության ներքին կարիքների համար:
  • Հավաստագրի գրառումների կենտրոնացված պահպանում, որը մասամբ լուծում է DNS-ի միջոցով տիրույթի վավերացման և հետագա ավտոմատ նորացման խնդիրը, ինչպես նաև լուծում է հաճախորդի վստահության հարցը: Այնուամենայնիվ, CNAME-ն ավելի վստահելի է գործընկեր/կատարող ընկերության սերվերում, քան երրորդ կողմի ռեսուրսը:
  • Դե, վերջապես, այս դեպքում «ավելի լավ է ունենալ, քան չունենալ» արտահայտությունը լիովին տեղավորվում է։

SSL մատակարարի ընտրություն և նախապատրաստական ​​քայլեր

Անվճար SSL վկայագրերի առկա տարբերակներից դիտարկվել են cloudflare-ը և letsencrypt-ը։ Այս (և որոշ այլ նախագծերի) DNS-ը տեղակայված է cloudflare-ի կողմից, բայց ես նրանց վկայականներն օգտագործելու երկրպագու չեմ: Ուստի որոշվեց օգտագործել letsencrypt:
SSL վկայագիր ստեղծելու համար դուք պետք է հաստատեք տիրույթի սեփականությունը: Այս ընթացակարգը ներառում է որոշ DNS գրառումների (TXT կամ CNAME) ստեղծում՝ վկայական տրամադրելիս դրա հետագա ստուգմամբ: Linux-ն ունի օգտակար − վկայագիր, որը թույլ է տալիս մասամբ (կամ ամբողջությամբ որոշ DNS մատակարարների համար) ավտոմատացնել այս գործընթացը։ Windows-ի համար նույնը հայտնաբերվել և փորձարկվել է տարբերակներ ACME հաճախորդների համար, որոնց վրա ես հաստատվել եմ WinACME.

Իսկ տիրույթի գրառումը ստեղծվել է, եկեք անցնենք վկայագրի ստեղծմանը.

SSL-ի թողարկման ավտոմատացման ուղղությամբ

Մեզ հետաքրքրում է վերջին եզրակացությունը, այն է՝ տիրույթի սեփականության հաստատման առկա տարբերակները wildcard վկայագիր տրամադրելու համար.

  1. DNS գրառումների ձեռքով ստեղծում (ավտոմատ թարմացումը չի ապահովվում)
  2. DNS գրառումների ստեղծում՝ օգտագործելով acme-dns սերվերը (մանրամասների համար տե՛ս այստեղ.
  3. DNS գրառումների ստեղծում՝ օգտագործելով ձեր սեփական սկրիպտը (նման է certbot-ի համար cloudflare հավելվածին):

Առաջին հայացքից երրորդ կետը բավականին հարմար է, բայց եթե DNS մատակարարը չի աջակցում այս գործառույթը: Իսկ մեզ ընդհանուր գործ է պետք։ Իսկ ընդհանուր դեպքը CNAME գրառումներն են, բոլորն էլ աջակցում են: Հետևաբար, մենք կանգ ենք առնում 2-րդ կետում և գնում ենք կարգավորելու մեր ACME-DNS սերվերը:

ACME-DNS սերվերի տեղադրման և վկայականի տրամադրման գործընթաց

Օրինակ, ես ստեղծել եմ 2nd.pp.ua տիրույթը, և այն կօգտագործեմ ապագայում։

Պարտադիր պահանջ սերվերի ճիշտ աշխատանքի համար նրա տիրույթի համար NS և A գրառումների ստեղծումն է: Եվ առաջին տհաճ պահը, որին ես հանդիպեցի, այն է, որ cloudflare-ը (գոնե ազատ ռեժիմում) թույլ չի տալիս միաժամանակ ստեղծել NS և A ձայնագրություն նույն հոսթի համար։ Ոչ թե դա խնդիր է, այլ հնարավոր է: Աջակցությունը պատասխանեց, որ իրենց վահանակը թույլ չի տալիս դա անել: Կարևոր չէ, եկեք ստեղծենք երկու գրառում.

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

Այս փուլում մենք պետք է լուծենք հյուրընկալողը acmens.2nd.pp.ua.

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

Սակայն acme.2nd.pp.ua չի լուծվի, քանի որ այն սպասարկող DNS սերվերը դեռ չի աշխատում:

Գրառումները ստեղծվել են, եկեք անցնենք ACME-DNS սերվերի տեղադրմանը և գործարկմանը: Ես այն կապրեմ ubuntu սերվերի վրա դոկտոր կոնտեյներ, բայց դուք կարող եք այն գործարկել ամենուր, որտեղ կա Գոլանգ: Windows-ը նույնպես լավ է, բայց ես դեռ նախընտրում եմ Linux սերվեր:

Ստեղծեք անհրաժեշտ դիրեկտորիաներ և ֆայլեր.

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

Եկեք օգտագործենք vim-ը ձեր սիրելի տեքստային խմբագրիչի հետ և տեղադրենք նմուշը config.cfg-ում կոնֆիգուրացիա.

Հաջող շահագործման համար բավական է շտկել ընդհանուր և 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"
…

Նաև, ըստ ցանկության, ստեղծեք docker-compose ֆայլ ծառայության հիմնական գրացուցակում.

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

Պատրաստ. Դուք կարող եք վազել:

$ docker-compose up -d

Այս փուլում հյուրընկալողը պետք է սկսի լուծել acme.2nd.pp.ua, և հայտնվել 404-ի վրա 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

Եթե ​​սա չի հայտնվում - docker logs -f <container_name> օգնելու համար, լավ է, տեղեկամատյանները բավականին ընթեռնելի են:

Մենք կարող ենք սկսել վկայականի ստեղծումը: Բացեք powershell-ը որպես ադմինիստրատոր և գործարկեք winacme-ը: Մեզ հետաքրքրում են ընտրությունները.

  • M: Ստեղծել նոր վկայագիր (ամբողջական ընտրանքներ)
  • 2. Ձեռքով մուտքագրում
  • 2: [dns-01] Ստեղծեք հաստատման գրառումներ acme-dns-ով (https://github.com/joohoi/acme-dns)
  • Երբ հարցնում են ACME-DNS սերվերի հղման մասին, պատասխանում մուտքագրեք ստեղծված սերվերի URL-ը (https): Acme-dns սերվերի URL. https://acme.2nd.pp.ua

Ի պատասխան՝ հաճախորդը թողարկում է գրառում, որը պետք է ավելացվի առկա DNS սերվերին (մեկանգամյա ընթացակարգ).

[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-ի թողարկման ավտոմատացման ուղղությամբ

Մենք ստեղծում ենք անհրաժեշտ գրառումը և համոզվում, որ այն ճիշտ է ստեղծվել.

SSL-ի թողարկման ավտոմատացման ուղղությամբ

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

Մենք հաստատում ենք, որ ստեղծել ենք անհրաժեշտ գրառումը winacme-ում և շարունակում ենք վկայագրի ստեղծման գործընթացը.

SSL-ի թողարկման ավտոմատացման ուղղությամբ

Ինչպես օգտագործել certbot-ը որպես հաճախորդ, նկարագրված է այստեղ.

Սա ավարտում է վկայագրի ստեղծման գործընթացը, այն կարող եք տեղադրել վեբ սերվերում և օգտագործել այն: Եթե ​​սերտիֆիկատ ստեղծելիս դուք նաև առաջադրանք եք ստեղծում ժամանակացույցում, ապա ապագայում վկայագրի նորացման գործընթացը տեղի կունենա ավտոմատ կերպով:

Source: www.habr.com

Добавить комментарий