SSL-ის გაცემის ავტომატიზაციისკენ

ხშირად გვიწევს მუშაობა SSL სერთიფიკატებთან. გავიხსენოთ სერტიფიკატის შექმნისა და ინსტალაციის პროცესი (ზოგად შემთხვევაში უმეტესობისთვის).

• იპოვნეთ პროვაიდერი (საიტი, სადაც შეგვიძლია ვიყიდოთ SSL).
• CSR-ის გენერირება.
• გაუგზავნეთ თქვენს პროვაიდერს.
• დაადასტურეთ დომენის საკუთრება.
• მიიღეთ სერთიფიკატი.
• გადაიყვანეთ სერთიფიკატი საჭირო ფორმაში (სურვილისამებრ). მაგალითად, პემიდან PKCS #12-მდე.
• დააინსტალირეთ სერთიფიკატი ვებ სერვერზე.

შედარებით სწრაფი, არ არის რთული და გასაგები. ეს ვარიანტი საკმაოდ შესაფერისია, თუ მაქსიმუმ ათი პროექტი გვაქვს. რა მოხდება, თუ ისინი უფრო მეტია და მათ აქვთ მინიმუმ სამი გარემო? კლასიკური დევ - დადგმა - წარმოება. ამ შემთხვევაში, ღირს ამ პროცესის ავტომატიზაციაზე ფიქრი. მე ვთავაზობ ცოტა ღრმად ჩავუღრმავდეთ პრობლემას და იპოვოთ გამოსავალი, რომელიც კიდევ უფრო შეამცირებს სერთიფიკატების შექმნასა და შენარჩუნებაზე დახარჯულ დროს. სტატია შეიცავს პრობლემის ანალიზს და მცირე სახელმძღვანელოს განმეორების შესახებ.

ნება მომეცით წინასწარ გავაკეთო დაჯავშნა: ჩვენი კომპანიის მთავარი სპეციალობაა .net და, შესაბამისად, IIS და Windows-თან დაკავშირებული სხვა პროდუქტები. მაშასადამე, ACME კლიენტი და მისთვის ყველა მოქმედება ასევე აღწერილი იქნება Windows-ის გამოყენების თვალსაზრისით.

ვისთვის არის ეს რელევანტური და გარკვეული საწყისი მონაცემები

ავტორის მიერ წარმოდგენილი კომპანია K. URL (მაგალითად): company.tld

პროექტი X არის ჩვენი ერთ-ერთი პროექტი, რომელზეც მუშაობისას მივედი დასკვნამდე, რომ ჯერ კიდევ გვჭირდება დროის მაქსიმალური დაზოგვისკენ სვლა სერტიფიკატებთან მუშაობისას. ამ პროექტს აქვს ოთხი გარემო: დეველოპმენტი, ტესტი, დადგმა და წარმოება. Dev და ტესტი ჩვენს მხარესაა, დადგმა და წარმოება კლიენტის მხარესაა.

პროექტის განსაკუთრებული მახასიათებელია ის, რომ მას აქვს მოდულების დიდი რაოდენობა, რომლებიც ხელმისაწვდომია ქვედომენების სახით.

ანუ გვაქვს შემდეგი სურათი:

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

წარმოებისთვის გამოიყენება შეძენილი ბუნების სერთიფიკატი, აქ კითხვები არ ჩნდება. მაგრამ ის მოიცავს მხოლოდ ქვედომენის პირველ დონეს. შესაბამისად, თუ არსებობს სერთიფიკატი *.projectX.tld-ისთვის, მაშინ ის იმუშავებს staging.projectX.tld-ზე, მაგრამ არა module1.staging.projectX.tld-ზე. მაგრამ რატომღაც არ მინდა ცალკე ვიყიდო.

და ეს მხოლოდ ერთი კომპანიის ერთი პროექტის მაგალითზეა დაფუძნებული. და, რა თქმა უნდა, არის ერთზე მეტი პროექტი.

საერთო მიზეზები, რისთვისაც ყველას მიმართავს ამ საკითხს, ასე გამოიყურება:

• ცოტა ხნის წინ Google-მა შესთავაზა SSL სერთიფიკატების მაქსიმალური მოქმედების პერიოდის შემცირება. ყველა შედეგით.
• SSL-ის გაცემის და შენარჩუნების პროცესის ხელშეწყობა პროექტებისა და მთლიანად კომპანიის შიდა საჭიროებებისთვის.
• სერტიფიკატის ჩანაწერების ცენტრალიზებული შენახვა, რომელიც ნაწილობრივ წყვეტს დომენის გადამოწმების პრობლემას DNS-ის გამოყენებით და შემდგომი ავტომატური განახლებით, ასევე წყვეტს კლიენტის ნდობის საკითხს. მიუხედავად ამისა, CNAME პარტნიორი/შემსრულებელი კომპანიის სერვერზე უფრო სანდოა, ვიდრე მესამე მხარის რესურსზე.
• ბოლოს და ბოლოს, ამ შემთხვევაში ფრაზა „ჯობია გქონდეს, ვიდრე არ გქონდეს“ იდეალურად ჯდება.

SSL პროვაიდერის არჩევა და მოსამზადებელი ნაბიჯები

უფასო SSL სერთიფიკატების ხელმისაწვდომ ვარიანტებს შორის განიხილებოდა cloudflare და letsencrypt. ამ (და ზოგიერთი სხვა პროექტის) DNS მასპინძლობს cloudflare-ს, მაგრამ მე არ ვარ მათი სერთიფიკატების გამოყენების ფანი. ამიტომ, გადაწყდა letsencrypt-ის გამოყენება.
wildcard SSL სერთიფიკატის შესაქმნელად, თქვენ უნდა დაადასტუროთ დომენის საკუთრება. ეს პროცედურა მოიცავს გარკვეული DNS ჩანაწერის შექმნას (TXT ან CNAME) და შემდეგ გადამოწმებას სერტიფიკატის გაცემისას. Linux-ს აქვს კომუნალური პროგრამა - სერტბოტი, რომელიც საშუალებას გაძლევთ ნაწილობრივ (ან მთლიანად ზოგიერთი DNS პროვაიდერისთვის) ამ პროცესის ავტომატიზირება. ვინდოუსისთვის დან ნაპოვნია და დამოწმებული ACME კლიენტის ვარიანტები, რომლებზეც დავფიქრდი WinACME.

და დომენის ჩანაწერი შეიქმნა, მოდით გადავიდეთ სერტიფიკატის შექმნაზე:

ჩვენ გვაინტერესებს ბოლო დასკვნა, კერძოდ, დომენის საკუთრების დადასტურების ხელმისაწვდომი ვარიანტები wildcard სერტიფიკატის გაცემისთვის:

1. შექმენით DNS ჩანაწერები ხელით (ავტომატური განახლება არ არის მხარდაჭერილი)
2. DNS ჩანაწერების შექმნა acme-dns სერვერის გამოყენებით (შეგიძლიათ მეტი წაიკითხოთ აქ.
3. DNS ჩანაწერების შექმნა საკუთარი სკრიპტის გამოყენებით (მსგავსი cloudflare მოდული certbot-ისთვის).

ერთი შეხედვით, მესამე პუნქტი საკმაოდ შესაფერისია, მაგრამ რა მოხდება, თუ 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 სერვერზე docker კონტეინერი, მაგრამ შეგიძლიათ მისი გაშვება ყველგან, სადაც გოლანგი ხელმისაწვდომია. 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.

ჩვენ ვქმნით საჭირო ჩანაწერს და ვრწმუნდებით, რომ ის სწორად შეიქმნა:

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

ვადასტურებთ, რომ შევქმენით საჭირო ჩანაწერი winacme-ში და ვაგრძელებთ სერტიფიკატის შექმნის პროცესს:

როგორ გამოვიყენოთ certbot როგორც კლიენტი აღწერილია აქ.

ეს ასრულებს სერთიფიკატის შექმნის პროცესს, შეგიძლიათ დააინსტალიროთ იგი ვებ სერვერზე და გამოიყენოთ იგი. თუ სერთიფიკატის შექმნისას თქვენ ასევე შექმნით დავალებას განრიგში, მაშინ მომავალში სერტიფიკატის განახლების პროცესი ავტომატურად მოხდება.

წყარო: www.habr.com